Software migration: a practical reference for 2027

Every migration is sold as a copy operation and turns out to be a translation. Two systems almost never model the same thing the same way, so the interesting work is not moving the bytes. It is deciding what to do about everything that has no equivalent on the other side.

This is a reference for planning one: what breaks, what order to do things in, what to keep running while you switch, and how to prove afterwards that it actually worked.

What to take away

The instinct is to switch everything at once because a split state feels messy.
A freeze is when nobody may write to the old system and the new one is not open yet.
Most migration plans have a rollback section that has never been tested and would not work.
The last few percent takes a disproportionate share of the effort.

Decide what "done" means before you start

Most failed migrations were never defined. Somebody said "move us off the old system by the end of the quarter" and nobody wrote down what state the new system had to be in for that sentence to be true.

Write the finish line down first, in terms someone else could check:

Which data has to be in the new system, and which data only has to be retrievable from somewhere.
Which workflows have to work on day one, and which can be rebuilt over the following months.
Who is allowed to still be using the old system after cutover, and until when.
What has to be true before you cancel the old contract, which is a different and later date than cutover.

That last distinction saves more money than any tooling choice. Cutover is when people start working in the new place. Decommission is when you stop paying for the old place. Collapsing them into one date is what forces teams into rushed, unverified switches.

What never migrates cleanly

You can move files and records. The things that surround them are where the work is. Assume every item below needs a decision rather than a transfer.

What breaks	Why it breaks	What to decide
Permissions	Systems use different primitives: inherited folder rights, group membership, per-item shares, roles. There is rarely a one-to-one mapping	Map to the new system's model deliberately. Never let a tool guess. Migrating with everything wide open "for now" is how permissions become permanent
Timestamps	Many tools stamp created and modified dates at the moment of import, not the original date	Decide whether original dates matter. If retention clocks, sorting, or "recently changed" views depend on them, this is a blocking requirement, not a nice-to-have
Ownership	The account running the migration often becomes the owner of everything it touches	Check what the tool does with ownership before the bulk run, not after
Links	Every saved URL, bookmark, embedded reference, and pasted link into the old system dies or silently points at stale content	Inventory where links live: documents, tickets, wikis, email signatures, scripts, dashboards
History	Version history, comment threads, audit trails, and edit attribution frequently arrive flattened or not at all	Decide whether history is a compliance requirement or a comfort. If it is a requirement, you may need to keep the old system readable rather than move it
External identities	Guests, contractors, and clients exist as accounts in the old system that do not exist in the new one	Build the external-user list early. It is always longer than anyone expects
Integrations	Anything connected by API or webhook is pointed at the old system by hard-coded URL, token, or account	Every connection is a separate small migration with its own owner
Custom fields and states	Custom statuses, tags, categories, and fields rarely have twins. Fitting them into the new model loses information	Agree the mapping in writing with whoever depends on those fields

There is also a category of quiet corruption worth naming: filenames. Systems disagree about which characters are legal, how long a full path can be, whether case matters, and how they store accented characters. A bulk move can silently rename, truncate, or skip items. Ask your tooling what it does with a name it cannot represent, and make sure the answer is "logs it", not "fixes it".

Sequence it in this order

The order matters more than the tooling. Each step here exists because doing it later costs more.

Inventory before you evaluate. You cannot judge a destination without knowing what you are sending. Count items, volume, largest single object, account list, external accounts, integrations, and anything with an unusual permission.
Find the outliers first. The oversized file, the folder with a decade of history, the one workflow with fifteen custom states, the shared account nobody will admit to using. Outliers determine feasibility. Averages do not.
Set up identity in the destination before any content moves. Accounts, groups, and roles must exist before permissions can land on them. Migrating content into a system with no group structure means re-doing permissions by hand later.
Do a small, real pilot with real permissions. Not a test folder of sample files. Pick one team with genuinely messy data and migrate them properly.
Measure the pilot's throughput and extrapolate honestly. Bulk transfers hit rate limits and throttling. The pilot tells you whether your window is plausible.
Run the bulk pass early, while the old system is still live. Most of your data is not changing daily. Move it long before cutover.
Run delta passes for what changed since. The gap between bulk pass and cutover is covered by repeated incremental syncs, each smaller than the last.
Freeze, final delta, cut over. The freeze window only has to cover the last, smallest delta, that is the entire point of the preceding steps.
Run in parallel, read-only on the old side. See below.
Verify, then decommission. Separately, and later.

Coexistence: what to run in parallel, and for how long

The instinct is to switch everything at once because a split state feels messy. The split state is usually cheaper than the alternative.

Things that genuinely can run in parallel:

The old system in read-only mode. This is the single highest-value safety net. People can still find the thing they need, and nobody can create new content you would have to migrate again. If the platform has no read-only mode, removing write permissions from everyone achieves the same thing.
Old and new side by side for a pilot group who report problems before everyone else meets them.

Things that must not run in parallel:

Two systems both accepting new writes for the same data. You will get divergence, and reconciling divergence by hand is worse than any migration.
Anything with a delivery path, such as mail routing or inbound webhooks, split across two destinations. Split delivery means messages land in two places and neither is complete.

Decide the read-only window in advance and announce its end date at the same time you announce cutover. An open-ended "the old system is still there if you need it" turns into a system you are still paying for a year later, because nobody was ever told to stop relying on it.

The freeze window

A freeze is when nobody may write to the old system and the new one is not open yet. It is pure downtime, so make it small and make it boring.

Schedule it when your organization is least active, and check that the "least active" window is the same across every timezone you employ.
Publish exactly what people cannot do, not just that "the migration is happening".
Have a named person authorized to call it off, and a documented condition for calling it off.
Know how long a rollback takes before you need one. If the answer is "longer than the freeze window", the freeze window is too short.

For anything DNS-driven, lower the record's time-to-live well ahead of the change, so caches expire quickly when you flip. Raise it back afterwards. Doing this on the day is too late: the old value is already cached at its old duration.

Verification: prove it, don't feel it

"It looks fine" is not verification. Decide these checks before cutover and run them after:

Counts, at several levels. Total items, items per account, items per top-level container. Matching totals with mismatched distribution means something moved to the wrong place.
Spot-check by sampling deliberately, not randomly. Take the largest item, the oldest item, the most-shared item, one item with unusual characters in its name, and one item owned by someone who has left.
Permissions from the user's seat. Not from an admin console, which sees everything. Have real people confirm they can reach what they should and, more importantly, have someone confirm they cannot reach what they should not.
The reconciliation list. Every migration tool produces skipped, failed, or transformed items. Read that report. A run that reports zero problems usually means the report is not being generated.
One end-to-end workflow. Pick a process that crosses systems, a request that becomes a task that produces a document that gets shared externally, and walk it all the way through.

Keep the verification results. When someone asks in six months whether something was migrated, a dated report beats memory. Formal records transfers work this way for the same reason: the published transfer guidance treats a transfer as complete when the receiving side has been checked against an agreed description, not when the copying stops.

Rollback that is actually possible

Most migration plans have a rollback section that has never been tested and would not work. A real rollback needs three things:

The old system in a restorable state, not just present. If you have already deleted, converted, or reconfigured it, rollback is fiction.
A way to bring back anything created in the new system during the attempt, or an accepted decision that such content will be lost.
A decision-maker and a deadline. Rollbacks fail because people keep hoping for another hour.

If genuine rollback is impossible, and after a cutover it often is, say so plainly in the plan and invest the effort in the pilot instead. An honest "we cannot go back after this point" changes how carefully people test beforehand.

The long tail

The last few percent takes a disproportionate share of the effort. Budget for it explicitly:

Individuals with unusual setups who were not in any pilot.
Automations nobody documented, discovered when they stop firing.
Content owned by departed staff, which needs a new owner before it can be moved at all.
Archives that everyone agreed were unimportant until the moment they were needed.
Bookmarks, saved searches, and links in places you do not control, including other people's email.

The practical answer to the long tail is a single named owner and a visible list, worked down weekly, rather than a stream of individual complaints.

Decommission deliberately

Before you cancel anything:

Take a final export in a format you can read without the vendor. Verify you can actually open it, on a machine that has never had the old software installed.
Confirm your retention obligations are met by the new system, or by that archive, and write down which.
Check what the contract says happens to your data after termination, and how long you have to retrieve it.
Remove the old system's access to everything else: its API tokens, its service accounts, its ability to send mail as your domain. A decommissioned system with live credentials is a security problem waiting for a quiet week.
Ask what the supplier actually does with your data once the account closes, and get it in writing. Disposal is genuinely harder than storage, which is the whole premise of the published media sanitization guidelines, and a lapsed subscription is not a deletion.

What makes a migration expensive

Almost none of the cost is the transfer itself. It is:

Rebuilding permissions, because they did not map and nobody planned for it.
Rebuilding integrations, one at a time, each needing a different owner's cooperation.
Retraining, especially for the people who had the old system's quirks memorized.
Running both systems for longer than planned, because decommission was never given a date and an owner.
Recovering from an unverified cutover, which is the expensive one, because you are doing forensic work under time pressure with unhappy users.

That list is also the argument for checking export quality before you sign anything. The question to ask a prospective vendor is not "can we export our data", everyone says yes. It is: in what format, including which of the fields above, produced by whom, how long does it take, and can we run it ourselves without asking you.

A vendor whose export answer is vague is telling you what leaving will cost.

Where to read next

Each estate has its own specifics, and the three most organizations move first are covered separately. The mail estate has the tightest cutover, because delivery either works or does not. The storage estate is dominated by permissions and by folder structure. The collaboration estate is the one where history usually does not travel at all. Everything wired into the old system is a project of its own, described in the connection register.

Common questions

How far ahead should we start planning?

Start the inventory as soon as the move is likely, not once it is decided. The inventory is useful whether or not you go ahead, and it is the part that always takes longer than expected because it depends on other people answering questions.

Can we avoid a freeze entirely?

Only with incremental transfer, and even then you usually want a short one to make the final pass complete. What you can avoid is a long freeze, which is the version that pushes people into personal accounts and email attachments.

Who should be told, and when?

Everyone affected, twice: once about three weeks out with what will change, and once about three days out with what to do on the day. Say plainly what will not survive the move, because a limitation announced in advance is a fact and the same limitation discovered afterwards is a failure.

What is the most commonly underestimated part?

The connections, followed by the fortnight of reduced output afterwards. Both are predictable and neither appears in a supplier's estimate, because neither is their work.