7 things about software migration comparison worth your time

Most comparing in a migration project centers on tools, which is the smaller decision, while the larger one is the shape of the move.

Will everyone change on one night, will two systems run side by side for a while, or will departments go one at a time? Or will you stop trying to bring the past with you?

Those four shapes have genuinely different risk profiles, costs, and failure modes. Choosing between them deliberately is worth more than any tool selection.

What to take away

The four shapes

Note what is not in the table: the size of the estate. Size decides how long the transfer takes, and almost nothing else. What decides the shape is the density of work across group boundaries.

The single cutover

One weekend, one announcement, one answer to where things live. It is the shape most organizations should choose and the one that frightens people most.

Its virtue: no one ever has to think about which system to use. Its cost: concentration of risk, manageable if the dry run was honest and the fallback is defined.

The failure mode: a Saturday problem affects everyone Monday. That is why pausing criteria must be written in advance, not decided while tired.

The parallel run

Both systems available, with the intention that people migrate their behavior gradually. It sounds prudent and it is usually the worst option available.

The reason is not technical. A person deciding where to put something will decide differently on different days. At the end of the period you have two incomplete estates, two search indexes, and no way to tell which copy of a document is current. Every migration that ends badly in this way ended badly for the same reason.

There is one situation where it is right: where the old system must remain live for a defined external reason, such as a contractual obligation or a regulator's process that runs to its own timetable. Then it is a constraint rather than a choice, and it should be bounded by a date.

Staged by group

One department, then the next. Risk is spread, the first group teaches you what the runbook missed, and support is manageable.

It works when the boundary is a rule anyone can state: this whole department, from this date, for everything. It fails when people work across the boundary daily, because a shared document with half its collaborators in each system produces exactly the split described above.

Test the boundary before choosing this shape. Look at a week of real collaboration and count how much of it crosses the line you propose to draw. If more than a small fraction does, choose a single cutover instead.

Archive and start fresh

The most underused option. The new system starts empty. The old one is frozen, kept reachable and read only, and eventually exported to a searchable archive.

It is cheap, it is fast, and it removes almost all of the mapping problems, because nothing is being mapped. It is also the option that most often meets resistance, on the grounds that history is valuable. Test that claim before accepting it.

Look at how far back your own searches actually went over the last month. For a great many organizations the honest answer is weeks, with a small number of important exceptions that a read only archive serves perfectly well.

Where the old system is genuinely old, this shape also stops you carrying its structure into the new one. That is the recurring theme in the published advice on moving away from legacy systems: the expensive part is rarely the data, it is the assumptions that travel with it.

Comparing them upward

At some point this becomes a decision somebody else signs. The comparison that lands is not a feature table; it is three sentences per option covering what could go wrong, who it would affect, and what it would cost to recover.

Frame it as a risk choice with a recommendation. Be specific about how each option disrupts ordinary work. That cost is what people feel and complain about.

The board toolkit guides the level and register for that talk. Its point applies: leaders decide well with consequences, badly with implementation detail.

Where this fits

The category overview covers what survives a move in general. The preparation work stays the same whichever shape you choose, but the freeze looks different for a staged move.

The tool selection should come after this decision rather than before it. The connection rebuild has to follow the same shape as the data, or your migrated system's plumbing points at the old one.

Common questions

Can we start staged and switch to a single cutover?

Yes, and it is a reasonable plan: migrate one willing department, learn, then move everyone else at once. What does not work is drifting from staged into parallel because the schedule slipped, which is how most parallel runs actually begin.

How long is too long for a parallel period?

Any period long enough that people forget which system is authoritative, which in practice is about two weeks. If you need six months, you are not running a migration, you are running two systems, and it should be budgeted and staffed as such.

Does the archive option satisfy retention obligations?

It can, provided the archive is genuinely searchable, access is controlled, and someone owns it. An export sitting in a folder that nobody can search is not a records archive. Confirm the arrangement with whoever owns records before choosing this shape, not after.

Which shape do most organizations regret?

The unplanned parallel run, by a wide margin. It is rarely chosen and frequently arrived at, and the cost shows up months later as duplicate documents and a search that never finds anything on the first try.