Never Migrate!

“We’re going to build a new service and then migrate the users across.”

How often have I heard this from product owners over the years? Too many, that’s for certain.

As much as possible, you should avoid having to migrate users from one product to another. Why? Because it’s almost always going to end in tears.

Building the replacement

This is what the product owner thinks is going to happen as they build the new system:

Here is what will actually happen:

Far from leaving the existing product alone, you still need to sell and support it. So changes get made, functionality continues to develop, bugs are fixed and systems are optimised.

At the same time, estimates of how quickly the replacement will be built are too optimistic. It turns out that the existing system — which everyone agrees is terrible — nevertheless incorporates years of accumulated knowledge about the business and users which is not documented anywhere.

As time progresses the functionality of the replacement draws ever nearer to that of the existing solution, but never seems able to match it.

Migrating Users

After a certain amount of time the decision is made to begin migrating users to the new system regardless. Here is what the migration plan looks like:

Here is what actually happens:

Some users are happy to migrate and do so quickly.

Those that are left prove progressively more difficult to move. Often they use more esoteric features, which have yet to built in the new version. Sometimes they are the highest-value customers — they drag their feet, but no one in the business wants to annoy them by forcing the issue.

Five years later, there are still two systems and no sign that the old one will ever be shut down.

How do we avoid this nightmare?

Remodel the existing solution from the inside out, replacing elements piece-by-piece so that the experience is gradually transformed, without users having to switch over.

Agree a hard switch: work to create the new version, but switch to it decisively once it reaches maturity. In this approach, the access point doesn’t change — users just log in one day to see the new experience rather than the old one (obviously you need to invest in advertising the change in advance and helping users prepare).

Some users may be lost in this process, but the overall saving in time and complexity compared to supporting two versions in the long term is often sufficient compensation.