Rules
Part of Software migration for the careful reader
Why does a worst-case sample matter more than a software migration ranking?
No ranking of software migration tools for 2027. The pairing decides it: build a 200 item sample of your worst cases and reconcile the result by hand.
Ranking migration tools is the least meaningful exercise in this whole category, because a migration tool is not a general product. It is a translator between two specific systems, and a tool that is excellent at one pairing can be unusable at another.
So the question is never which is best. It is which handles your pair, your object types, and your awkward cases, and the only way to find out is to move two hundred items and check them by hand.
What to take away
- Ask about your exact pairing. Support for both systems separately is not support for the route between them.
- Build a representative sample of two hundred items, weighted toward the awkward, and migrate it before you buy anything.
- Reconcile the sample yourself. The tool's success report is a description of what it attempted.
- The tool gets read access to everything you own. Assess the supplier accordingly.
Why the pairing decides it
The difficulty of a migration is a property of the difference between the two sides. Ownership models, permission structures, how versions are stored, whether comments are part of an item or attached to it, what a group means: each of those may map cleanly, partially, or not at all.
A supplier who has done your exact pairing hundreds of times has met the specific problems and usually has answers. One who supports both products but rarely joined them will discover those problems with your data.
Ask directly how many migrations of your pairing they have completed and what the usual surprise is. A supplier who cannot name a usual surprise has not done many.
Build the sample first
Two hundred items, chosen for difficulty rather than convenience. Assemble this before contacting anyone, because it doubles as the requirements document.
Worst-case migration sample
- Largest single itemsize limits, silent skips
- Deepest folder pathpath length limits
- Accents, ampersands, quotescharacter handling
- Long version historyearlier versions travel?
- Unresolved comment threaddiscussion survives?
- Disabled account ownermapping gap
- External sharepermissions map or dropped?
| Include | What it exposes |
|---|---|
| The largest single item you hold | Size limits, and whether failures are reported or skipped |
| Your deepest folder path | Path length limits, which fail silently more often than loudly |
| Names with accents, ampersands, and quotation marks | Character handling, which differs more than suppliers admit |
| An item with a long version history | Whether earlier versions travel at all |
| An item with an unresolved comment thread | Whether discussion survives, and in what order |
| Something owned by an account that has been disabled | The mapping gap that affects every departed employee |
| Something shared with an external person | Whether external permissions map or are dropped |
| An item under a hold or retention rule | Whether the obligation travels with the content |
| Something an automation created or updates | Whether machine owned content maps to anything |
| An item linked to from an item outside the sample | Whether references survive the move |
Run the same sample through every candidate. Everything after that is comparison rather than impression.
Reconcile by hand
The tool will report a number. Your job is to open items.
Reconcile by hand
- Open twenty items at random
- Open every awkward case from the table
- Confirm content, owner, visibility, timestamps
- Confirm version count and comments
- Write down every difference, even minor
- Check the failures list by item name
Check twenty at random, plus every awkward case from the table. For each, confirm the content, the owner, who can see it, the timestamps, the version count, and any comments. Write down every difference, including the ones that seem minor, because a shifted timestamp across an entire estate is a real problem the first time somebody sorts by date.
Then check the failures list. A tool that cannot give you a list of failed items by name is disqualified, whatever else it does well. One percent of a large estate is a lot of items and the only useful question is which ones.
The supplier is being given everything
This is the part that gets least attention and deserves more. A migration tool reads every document, message, and permission you hold, and in the hosted case that content passes through infrastructure you do not control.
Supplier data-path questions
- Where is the data processed?
- What is retained after the project, and how long?
- Who at the supplier can see content?
- What happens to issued credentials at the end?
- Get the answers in the contract, not email
- Issue a dedicated, narrowly scoped account
- Close that account on a named date
Ask where the data is processed, what is retained after the project and for how long, who at the supplier can see content, and what happens to the credentials you issued when the engagement ends. Then ask for the answers in the contract rather than in an email.
The supply chain risk management practices set out the standard framing for assessing a supplier who becomes part of your data path. The data security guidance for businesses states more plainly what you owe your own customers when a service provider handles their data.
Issue a dedicated account for the migration, scoped as narrowly as the tool allows, and close it on a named date. That single habit removes most of the residual risk here.
Questions worth asking before a demonstration
- How many migrations of my exact source and destination have you completed?
- What does your tool not carry between these two systems? Send the list.
- How does incremental transfer detect a change, and does it notice a permission change?
- What happens to an item owned by a disabled account?
- Can I supply the identity mapping as a file?
- What support hours cover a weekend cutover?
- What does the failure report look like? Send a real one, redacted.
The last request is the most informative and the least often made. A supplier who can show you a real failure report is a supplier who expects failures, which is the correct attitude.
Ask before the demo
- How many migrations of my exact pairing?
- What does your tool not carry? Send the list
- How is incremental change detected?
- What happens to disabled-account items?
- Can I supply the identity mapping as a file?
- What support hours cover a weekend cutover?
- Send a real, redacted failure report
What the decision usually comes down to
After the sample, the field is usually two.
How the decision usually falls
Which tool handled your awkward cases?
shortlist it
drop it
Pick the tool that handled your awkward cases, then the one with a usable failure list, then support hours during cutover. Price comes fourth, genuinely fourth: tool costs differ little next to a week fixing 4,000 items by hand.
Where to read next
The category overview sets out what generally survives a move and what does not. The features that matter explain what you are testing for in the sample, and the preparation work covers the freeze, the reconciliation numbers, and the runbook. Everything wired into the old system is a separate estimate, described in the connection rebuild.
Common questions
Should we use the destination supplier's own migration service?
Frequently yes, and it is worth pricing first. They know their side very well and their side is usually where the mapping problems land. The limitation is that they know the source less well, and their tooling may not cover an unusual origin.
Can we do it ourselves with scripts?
For a small estate with simple content, sometimes. It goes wrong at permissions, at scale, and at the point where somebody has to maintain the script during a cutover weekend. Estimate the reconciliation work honestly before choosing this, because that part does not get cheaper.
Is a consultant worth it?
For a first migration of any size, the useful thing a consultant brings is not the tool but the list of what usually goes wrong. Ask for that list during the pitch. If it is generic, you are buying hands rather than experience.
How far in advance should we choose the tool?
After the inventory and before the schedule. Choosing a tool first tends to shape the plan around what that tool does well, which is exactly backwards.
