Why, when, and how much migration planning

Why migration planning

Most migrations aren’t really planned, but instead just started (relatively blindfolded) late in the game when it is close to launch. This almost always leads to results that are less than ideal and often stalls the entire launch.

Migration planning is crucial for three reasons:

• Increase quality. A migration is a perfect opportunity to increase the quality of the content, not just keep the status quo. Beyond simply increasing the quality upon launch it is also possible to set the stage for increased quality over the long term.
• Decrease effort / cost. There are often ways of optimizing a migration to reduce effort / cost from the initial, obvious approach. 
• Reduce risk. Migrations fall off the rails all the time. There will always be surprises, but migration planning helps to limit them.

When migration planning

Migration planning fits within a larger process of large digital change, for instance replatforming or redesigning. Most projects follow a flow something like the following, and migration planning helps in each (you can also download the one-page checklist):

• While conceptualizing the overall project. The migration key during this phase is to anchor the vision for the project with the realities of getting there so that expectations are not set early that will be impossible to implement effectively.
• While developing any RFPs. Early overall digital strategy comes before sending out RFPs to ensure strong alignment, but from a migration perspective specifically you need to spell out what migration expectations are of any vendor. These expectations will include what you expect your vendor to do and what your responsibilities will be, as well broadly speaking what you intend on migrating and the quality you expect.
• While defining the project plan. Even in today’s agile world there are key questions about how things will be sequenced and how the presence will be structured overall. When higher quality is expected, the project may need to be structured differently, for instance to implement some key templates earlier to make sure the content can be migrated well to them as well as the time to correct issues if not.
• When architecting the solution. The way the solution is architected plays a role in how the migration goes. For instance, it may be desirable to have templates that degrade better with varying content quality levels rather than raising old content to the same standard (obviously that may be precisely what you do NOT want to happen and that’s fine too — the point is this stuff needs to be considered while architecting the solution).
• During solution implementation. As mentioned above, we hopefully are able to define the project plan in a way where the migration can start earlier, in which case there is less of a clear line between solution implementation and the migration itself. That said, whether the two overlap or not migration planning still needs to happen during the solution implementation since some of the details of the migration may only become obvious during implementation (for instance, perhaps it was assumed that images would move over as managed assets but during implementation this functionality is jettisoned — this will effect how the migration is planned).
• During migration itself. Although of course the migration planning should be planned by the time the migration happens, it is an iterative process and the plan does need course correct from time to time.

How much migration planning

You have three control knobs at your disposal in migration planning: weight, distance, and quality (answer these ten questions to get a rough cut at where you are on weight and distance). Basically, migrations are more complex the more you are trying to move (the weight, or complexity of the current presence) across a longer distance to achieve higher quality. We can make the migration easier by moving less, attempting less, and going for lower quality. The magic is tweaking those control knobs effectively.

So the amount of migration planning depends on how complex a migration you face (note that this is really the size of the migration — if you’re the only one who is thinking the weight, distance, and quality can be such that the migration is easy then you still have a lot of planning and effort to get agreement on that):

• A simple migration is both focused on the amount of changes you are attempting (for example, not trying to consolidate many sites or site sections) and the current digital presence is fairly simple in the first place (for instance, it is small and not a lot of languages). In this case, the least amount of migration planning is required. That said, it’s important at the step of conceptualization to keep in mind the migration needs to ensure the vision can be accomplished, and, although the stakes aren’t as high, it’s best to try to optimize the process of migration.
• A medium-sized migration is either a bit more aspirational (you are attempting to make bigger changes) or you are starting from a larger / more complex site, but not both. Since this is on the cusp of a simpler migration, first consider whether you could make it smaller and phase the migration over a longer time period (learning as you go). If you are using external resources, the RFP definition becomes especially important for a medium-sized migration.
• A complex migration is both aspirational and starting from a larger / more complex presence (or simply it’s a huge site or you are trying to accomplish tons). This requires the most planning. The big shift for the complex migration is the importance of including the migration in the definition of the overall project and the architecture of the solution. This is particularly important since you don’t want to get this wrong early and have bad repercussions for a long time thereafter.