The person who was supposed to be maintaining my CiviCRM on Drupal instance flaked on my a while ago and my site has been sitting vulnerable. Due to hosting changes, I decided to just set up a clean new instance on the new host but I need help as to how best to move the Civi records (and also config if possible!) over considering my old MySQL database may have been compromised.

Help! Thanks a lot!

  • Can you clarify in the question if the issue here is that the system has been left with security flaws, and the concern is that there may have been injections of undesirables in to the db (which is how i read it) rather than a corrupt db in the sense that the schema is now in bad shape?
    – petednz - fuzion
    Commented Jul 27, 2015 at 4:30

5 Answers 5


Before pronouncing the old database deceased, I would make sure the structure is correct and if not what is broken. You can try this: https://github.com/progressivetech/civi-schema-harmonizer or http://wiki.civicrm.org/confluence/plugins/servlet/mobile#content/view/86213632. The current dB may be ok.

  • 1
    As someone who does CiviCRM migrations professionally, this sounds like a LOT less work than migrating the data. Commented Jul 26, 2015 at 18:50

If you wish to transfer the content of the database a) export the existing data. You can do this as an action from the search/find screens. Export contacts, activities, memberships, contributions as separate files. b) on the new system, import each file. Use the old contact_id field as the external_identifier to help all the records match up.

This is easy in concept, not so easy in practice! If you have custom fields, you'll need to recreate them. If there are custom option lists, those will also need to be recreated ... as well as member types, financial types (if custom), etc.

So .. if you can, stick with moving the database. If necessary, you can roll up the sleeves and expect to spend quite a bit of time exporting and importing.


Sounds like you may be in over your head. I recommend hiring a professional to help you with this.

In general, questions on this site should be in the realm of "I understand X and Y but have a question about Z" rather than "I need you to walk me through X Y and Z and I haven't really read A B or C either." Your question sounds more like the latter category but it might just be the way it's worded. If you disagree, please feel free to edit your question to show more of your research and understanding of the migration process, and the specific step you need assistance with.

  • Believe me, if we had money I'd just pay the money. We are a small community-run food cooperative and can't really afford to pay anyone. I read this book.civicrm.org/user/current/common-workflows/importing-data and am wondering whether I could just download the various records (contacts, members, payments) as CSV and upload them to the new CiviCRM instance. I am skeptical that it would work well but I want to know what my options are before I throw my hands up. Commented Jul 23, 2015 at 18:49

Agree with Coleman. It should be possible to get an audit done of your old civi db to look for any suspicious data and based on that determine if your db can be copied over or whether the data needs a full export/import. We are just about to rip in to a site that was compromised as a result of DrupalGeddon to see if we can assure ourselves and the client if the civi data is 'clean'. We will probably document how that went in case it is of help to others in the future.

  • I'd appreciate such documentation. Commented Jul 23, 2015 at 18:53
  • 1
    Noted. Hopefully we get to do this audit next week. Maybe we can then offer to run same through yours to help test our process.
    – petednz - fuzion
    Commented Jul 23, 2015 at 22:34

Here's some tips that helped me when I had issues with a db that wouldn't upgrade due to errors.

My original database was stuck at 4.3.3 and had gone through many upgrades and a couple times had some errors on the upgrade. Even after switching to civihosting my 4.3.3 database gave a trigger error that triggers weren't enabled. We (Hershel and I) determined that it had to be with the db. So I got the bright idea to compare the structures of the corrupt db with a clean 4.3.3 structure. Here are the steps I took:

  1. I did a structure dump of the Corrupt DB minus the custom tables. I imported the civicrm.mysql file from the 4.3.3 build into a clean db
  2. I did a structure dump of the clean import and then compared the files using a Diff tool.
  3. There were alot of issues that confirmed for me it was the db. I ensured that all column names matched between the two db's.
  4. I then did a structure dump of the custom tables in the corrupt db, then a data dump of the custom tables in the corrupt db, then a data dump of all the other tables in the corrupt db.
  5. Then I imported into the clean db in the following order: the structure of the custom tables, the data of the custom tables, the data of the other tables.
  6. Then I ran the upgrade to 4.3.5 and it upgraded without any errors

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.