Best Practices for Planning a Migration to a New Platform
1) Don’t use your dev site, use a dummy site.
- The Migrate Module indexes each piece of content and creates an allocation table to associate the unique ID of the content with the NID. This can get needlessly large if you do this on your Dev site.
- You want to mess up a site that won’t eventually go live. You will be running migration a lot before you get it right. Spin up a test site and run your migration script there.
2) Create temporary fields to store debugging data
- Debugging data may be a pain. Especially when getting content and massaging it into a field accurately. This is challenging when it comes to cleaning HTML as it is migrated from other websites.
3) Understand EXACTLY what you’re migrating
- There can be A LOT of facets to a migration of a single type of content. Despite migrating JUST a page we still need to understand the ACTUAL content that’s being migrated. For instance if there are links on the page and they reference a domain on the site that is ALSO being migrated, there is a possibility that we need to migrate these artifacts. Some common elements are:
- Links that belong to the same domain
- Links to files that belong to the same domain