Migrate/Repair CiviCRM to new server

How Can We Help?

Migrate/Repair CiviCRM to new server

Created On
byKeith Nunn
Print
You are here:
< Back

This is simply a set of personal notes based on the instructions at https://docs.civicrm.org/sysadmin/en/latest/misc/switch-servers/. I’ve trimmed it down to a bare bones walk-though for my WordPress situation and to include some solutions for ‘gotchas’ I ran into as I went.

  1. Create two new databases. One for WP and a separate one for CiviCRM. I used the same user for both, but it might be better to use different users.
  2. Set up the new WordPress server. In this case I used a new subdomain, but that may not be desirable. If re-using a subdomain, you’ll have to play some more games with hosts files and maybe ssl certificates to smooth the process, or take the old one offline to avoid conflicts. Definitely solvable, but outside the scope of this document.
    1. create the web server directory and download the latest WordPress code. I used wp-cli to download the latest en-CA version: ‘wp core download --locale=en_CA‘
    2. create the /etc/apache/sites-available file as appropriate and symlink to sites-enabled.
    3. Run the WP web install and provide the WP database credentials
    4. use ‘certbot --apache -d site.name‘ to get ssl running (or do it later)
    5. You may wish to use WP tools like Customizer import and export to migrate some look and feel items from the old site to the new one.
      1. Add CiviCRM modules and extensions to match the old database.
  3. Download the CiviCRM plugin. Do not use the latest CiviCRM. Download the version that matches your existing database: ‘wget https://download.civicrm.org/civicrm-VERSION-wordpress.zip‘
    1. unzip it to the WP plugins directory and then activate it from the WP plugins page.
    2. When answering the questions on the CiviCRM setup, read carefully and provide the database credentials for the CiviCRM database to ensure it doesn’t get mixed with WP.
    3. DO NOT migrate the civicrm.settings.php file. You may need to transfer a value or two, but don’t bring the whole thing over. I didn’t need to copy anything.
  4. Make code and database backups of this new server. This ensures we can get back to this ‘clean’ state if things go sideways.
  5. Clean the old database to prepare for import
    1. Export the database of the old CiviCRM installation using mysqldump.
    2. Create a temporary database for cleaning the old database and import the dump file into it.
    3. Drop extraneous tables from the temp database.
      1. Some will always be worth deleting:
        • civicrm_db_name.civicrm_acl_cache, civicrm_db_name.civicrm_acl_contact_cache, civicrm_db_name.civicrm_cache,
          civicrm_db_name.civicrm_domain,
          civicrm_db_name.civicrm_group_contact_cache
      2. Others drops will be more discretionary. I deleted all the 'log_%' tables. I also dropped tables that were clearly for modules and extensions that I had removed, but left crap in the database. I was presuming that these tables were part of my problem. However, this is a dangerous game, so be careful. Go slowly and consider each removal. Because this is a backup and not the live DB, it’s not disastrous, but could set you back several steps if you guess badly. Dropping large numbers of tables can be tedious as you can’t use a wildcard, but the following code will create a script that you can then feed back in to drop the tables. I used Adminer to do this, but it should work ok in the command-line client too.
        • SELECT CONCAT(‘DROP TABLE ‘, TABLE_SCHEMA, ‘.’, TABLE_NAME, ‘;’)
          FROM INFORMATION_SCHEMA.TABLES
          WHERE TABLE_NAME LIKE ‘log_%’
          AND TABLE_SCHEMA = ‘civi_database_name’;
  6. Dump this cleaned temporary database for importing into the new site database. Using the ‘--skip-triggers‘ flag on mysqldump would probably be a good idea as CiviCRM will apparently rebuild the triggers if they are not there. I did not do this and had a 'DB Error: insufficient permissions' problem when I accessed the new database. This meant I had to do a search and replace on the dump file to replace the old database username with the new one in the 'DEFINER' statements. I then re-imported and all was well. Using '--skip-triggers' should avoid this problem.
  7. Disable the CiviCRM plugin on the new site. I didn’t do this and it turned out ok, but it makes sense.
  8. Import the cleaned sql dump file into your newly setup CiviCRM database: 'mysql -u mysql_username -p civicrm_db_name < civi_dump_file_name_of_your_choice.sql'
  9. Clear CiviCRM cache: 'rm -rf /var/www/civi.site/wordpress/wp-content/uploads/civicrm/templates_c/*'
  10. Re-enable the CiviCRM plugin.
  11. Use the following URLs in your browser to review and update directory paths and base URLs. See CiviCRM Menu: Administer >> System Settings >> Cleanup Caches and Update Paths
    • http://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm/admin/setting/updateConfigBackend&reset=1
    • Review paths: http://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm/admin/setting/path?reset=1
    • Rebuild menus: http://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm/menu/rebuild&reset=1
    • Rebuild database triggers: http://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm/menu/rebuild&reset=1&triggerRebuild=1
Tags: