Managing Moving Migrations: The Only Constant is Change

TL;DR If you can’t quiesce the source and target systems in a migration you can’t use traditional migration methods.

We are doing a lot of migrations for clients and one aspect has come to the fore in nearly all of them.

During migrations things change.

I’ve observed this in:

• Migrating users between SharePoint Online Tenants
• Migrating content from Classic SharePoint Sub Sites to Modern SharePoint Sites
• Migrating data from a SharePoint Lists to SQL Tables

In all of these projects the users are expecting no downtime.

I think it’s an unintended consequence of the cloud being ‘always’ on.

How we used to do it

It used to be that to do a migration we followed a procedure like this:

• Quiesce the source and target systems by stopping all access to them, including unattended processes, ideally make the source system read only
• Export the source system content to a neutral storage system, often a file share
• Transform the source system content into the target system content and store on a neutral storage system, often a file share
• Import (Load) the target system content into the target system
• Verify that the source and target systems content has acceptable equivalency
• Awaken the target system
• Redirect as many of the source links as possible to target links
• Celebrate

This works very well and although your users lose access to the content whilst the migration occurs you do get the following benefits.

• Waterfall project methodology works well with it as everything is known in advance.
• The process can be refined before being implemented by building duplicate source systems, often from backups, and as a result the duration can be estimated quite precisely.
• Verification can be performed before users access the system.

This all depends on the initial step being able to quiesce the system if you can’t do that then you need a different model.

What Breaks

If you can’t quiesce the systems then the users will have access to both the source and target systems whilst you migrate and while this is great for them it brings a whole set of new challenges to the team doing the migration.

• Users need to know where each piece of content is at all times
• Project Managers can’t use waterfall so they can’t estimate the project
• Technology can’t practice the migration in its entirety and so can’t be sure it will work
• Governance can’t easily determine if the content is consistent

These are the four key stakeholders in any migration, and they are going to have to change how they work if it's going to be a success.

That’s enough for this week, next week I’ll look at what this means for the users and how their key issue, knowing where the content they need to work on is today can be addressed.

TL;CR If you can’t quiesce the source and target systems in a migration you can’t use traditional migration methods.