Answers.Body: <p>Before pronouncing the old database deceased, I would make sure the structure is correct and if not what is broken.  You can try this: <a href="https://github.com/progressivetech/civi-schema-harmonizer" rel="nofollow">https://github.com/progressivetech/civi-schema-harmonizer</a> or <a href="http://wiki.civicrm.org/confluence/plugins/servlet/mobile#content/view/86213632" rel="nofollow">http://wiki.civicrm.org/confluence/plugins/servlet/mobile#content/view/86213632</a>.  The current dB may be ok.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-26T18:50:08.447Z
Answers.Text: As someone who does CiviCRM migrations professionally, this sounds like a LOT less work than migrating the data.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-24T12:20:32.050Z
Answers.LastActivityDate: 2015-07-24T12:20:32.050Z
Answers.UserDisplayName: Sonicthoughts
Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-24T16:30:00.043Z
Answers.LastActivityDate: 2015-07-24T16:30:00.043Z
Answers.UserDisplayName: Eliot Mason
Answers.Body: <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-23T18:53:45.273Z
Answers.Text: I'd appreciate such documentation.
Answers.UserDisplayName: Camille Acey
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-23T22:34:19.780Z
Answers.Text: 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.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-23T00:21:47.323Z
Answers.LastActivityDate: 2015-07-23T00:21:47.323Z
Answers.UserDisplayName: petednz - fuzion
Answers.Body: <p>Sounds like you may be in over your head. I recommend <a href="https://civicrm.org/providers" rel="nofollow">hiring a professional</a> to help you with this.</p>
  
  <p>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 <em>and</em> 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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-23T18:49:17.683Z
Answers.Text: 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 http://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.
Answers.UserDisplayName: Camille Acey
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-22T23:04:34.463Z
Answers.LastActivityDate: 2015-07-22T23:04:34.463Z
Answers.UserDisplayName: Coleman
Answers.Body: <p>Here's some tips that helped me when I had issues with a db that wouldn't upgrade due to errors.</p>
  
  <p>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:</p>
  
  <ol>
  <li>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</li>
  <li>I did a structure dump of the clean import and then compared the files using a Diff tool.</li>
  <li>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.</li>
  <li>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.</li>
  <li>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. </li>
  <li>Then I ran the upgrade to 4.3.5 and it upgraded without any errors</li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-27T04:07:03.103Z
Answers.LastActivityDate: 2015-07-27T04:07:03.103Z
Answers.UserDisplayName: frTommy
Body: <p>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. </p>
  
  <p>Help! Thanks a lot!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-27T04:30:05.417Z
Comments.Text: 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?
Comments.UserDisplayName: petednz - fuzion
Tags: <drupal><database><mysql><migration>
Title: I need to migrate data from one CiviCRM on Drupal instance to a clean one. HELP?
ThreadText: # I need to migrate data from one CiviCRM on Drupal instance to a clean one. HELP?
  
  (Asked by: username_0 on 2015-07-22)
  
  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!
  
  **Tags:** drupal, database, mysql, migration
  
  > **Comments:**
  > **username_1**: 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?  
  
  ---
  
  ## 5 answers
  
  ### Answer by username_2 on 2015-07-24. Score: 4
  
  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.
  
  > **Comments:**
  > **username_3**: As someone who does CiviCRM migrations professionally, this sounds like a LOT less work than migrating the data.  
  
  ---
  
  ### Answer by username_4 on 2015-07-24. Score: 3
  
  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.
  
  
  ---
  
  ### Answer by username_1 on 2015-07-23. Score: 1
  
  Agree with username_5. 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.
  
  > **Comments:**
  > **username_0**: I'd appreciate such documentation.  
  > **username_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.  
  
  ---
  
  ### Answer by username_5 on 2015-07-22. Score: 1
  
  Sounds like you may be in over your head. I recommend [hiring a professional](https://civicrm.org/providers) 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.
  
  > **Comments:**
  > **username_0**: 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 http://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.  
  
  ---
  
  ### Answer by username_6 on 2015-07-27. Score: 1
  
  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
  
  
  ---
  
  