- Do a cleanup before migration. Meaning identify and remove any unused modules, themes, configurations. This reduces the time you have to take care of upgrading something that will not be used.
- Create backups before and during the process. Often the migration process would be broken down into several steps. It could be core, then contrib, then configuration, then content, etc. It can go wrong at any step. Having a backup during each step would minimise the risk that you would have to redo some work.
- Several tools available in the community that could assist the process. The options vary depending on the scale and requirement of the website. Here are some examples:
- https://www.drupal.org/project/migrate powerful, flexible and supports Drush.
- https://www.drupal.org/project/views_data_export simpler to use, batched data export through views, suitable for small-medium scale site.
- https://www.drupal.org/project/migrate_d2d extend the framework provided by Migrate support migration of content and data from one Drupal installation to another.
- https://www.drupal.org/project/feeds friendly interface to import, export some basic entity types.
- Check .htaccess setting in the existing site. Some sites have specific settings saved in .htaccess which, from time to time, could turn out to be the fix for your problem in the new site.
- When updating modules, themes, try not to combine too many updates in one go. Update a few, say 3 or 4, and test them. This way if you run into any trouble, it takes less time to debug and pinpoint the affected area.
- Pay attention to Status Report page.
- For custom modules/themes, follow the guideline provided in the community: https://www.drupal.org/update/modules , https://www.drupal.org/update/theme.
There are many more problems and issues you could run into during a migration. There is no set of golden rules or formula that could completely prevent all of it. The approach is more important for this type of work:
- Careful research the existing site’s structure, the more knowledge you have on the system, the less likely you would run into problem down the line.
- Allows enough time for contingency when estimating.
- Plan in details ahead and divide the work into small parts.
- Regression testing after each part is done.
All and all, I consider experience is the most valuable asset when it comes to migrations. You’d learn much more by actually doing a few migrations. Often, you would run into problems and find that fixes are not mentioned/covered in any book or guide.