Software migration features and the trade-offs behind them

A migration tool has one job that sounds simple and is not: read everything out of one system, then write it into another so the second means the same as the first. Bytes are the easy part.

Meaning is carried by permissions, ownership, timestamps, versions, and links. Every one of those is stored differently on each side.

The features below are the ones that decide whether you get a working estate or a pile with the right file count.

What to take away

Features that decide the schedule

Incremental or delta transfer. The tool moves everything once, then repeatedly moves only what has changed since the last pass. This is what allows a bulk copy over two weeks and a freeze of a few hours rather than a freeze of two weeks. Ask how change is detected, because a tool that compares modification dates will miss anything whose date is not updated when its permissions change.

Throughput and throttling. Both ends impose limits, and a tool that ignores them gets refused and slows down anyway. The useful question is not how fast it goes but whether it behaves properly when the far end says stop, and whether it can be scheduled to run heavily overnight and lightly during the day.

Resumption. A run will be interrupted. Ask whether it resumes from where it stopped or starts again, and whether resuming re-copies items it already moved.

Filtering. The ability to move a subset by date, by owner, by folder, or by type. This is what makes a staged migration possible and what lets you leave a decade of dormant material behind rather than paying to move it.

Permission and identity mapping

This is where the real difficulty lives, and it is worth understanding before you compare anything.

Every item has an owner and a set of people who can reach it.

Those people are separate account objects, possibly with different addresses, and the groups they belong to may not exist. The tool needs a mapping table, and product quality largely depends on what it does with that table.

Ask four things. Can I supply the mapping as a file instead of matching by address?

What happens to an item owned by an account with no counterpart, including everyone who has left? What happens to a permission granted to an external person? Does the tool report each item it could not map, or assign a default owner quietly?

The last one matters most. A tool that silently reassigns unmappable items to the administrator produces a destination where one account owns forty thousand things and nobody can tell which were originally whose.

The mapping table should come from your account administration records, not from the migration tool's own matching.

The tool matches on whatever string it can see, but your directory knows which of two similar addresses is current.

Reporting is the deliverable

Treat the tool's output as the product you are buying. It should give you counts by type on both sides, a list of every item that failed with a reason, a list of every item that was transformed rather than copied exactly, and all of it exportable.

A summary that reports ninety nine percent success is not usable. One percent of a large estate is thousands of items, and the only useful question is which ones. Insist on the list.

Where a transfer is done partly to satisfy somebody's right to receive their own data, the standard for a good export is a helpful benchmark.

The regulator's description of data portability says data should arrive usable, not merely delivered.

Ask what it cannot carry

Every tool has a list, and the good suppliers publish it. If yours will not, that is your answer.

The last row deserves particular attention. If anything in your estate is under a legal hold, confirm in writing how the tool handles it, because a transfer that drops a hold is a serious problem with no technical warning attached.

What happens to the source

The migration is not finished when the copy verifies. The old system still holds a complete copy of everything, and at some point that has to be dealt with properly rather than by letting a subscription lapse.

Set the retention period for the source and get the records owner to agree. Then ask what the supplier does when you close the account: how long the data persists, and if it is deleted or only inaccessible. Ask if they will confirm in writing.

Disposal is harder than storage, which is the premise of the published media sanitization guidelines.

Features that matter less than they look

A pretty interface, since this tool is used intensively for six weeks and then never. A very long connector list, because only the pair you have matters. And automatic scheduling, which sounds useful and is usually replaced by a person watching the first few runs anyway.

What does matter, and is easy to miss, is support during the window. Ask what hours help is available and whether that covers your cutover weekend, because a stuck run at two in the morning is exactly when the answer becomes expensive.

Where this fits

The category overview covers what does and does not survive a move. The preparation work is where these features get exercised, particularly the dry run and the reconciliation counts. And everything wired into the old system is a separate project with its own estimate, described in the connection rebuild.

Common questions

Can we just use the export and import features of the two products?

Sometimes, for small estates and simple content. It fails on permissions, on incremental transfer, and on scale, which is the same as saying it fails on everything that makes migration hard. For a team of ten with a few thousand files, it is often the right answer.

Does the same list apply to a storage move?

Broadly, with different emphasis: folder structure and sharing state dominate, and the storage migration notes cover the reconciliation habits that suit an estate measured in files rather than accounts.

Should the tool run from our network or as a service?

It depends on whether your source is reachable from outside. A service is simpler and means handing a supplier read access to everything you own, which deserves the same scrutiny as any other supplier decision. Ask where the data passes through and what is retained afterwards.

How do we price a migration tool?

Most are priced per account or per volume, for a period. Model it against the estate you intend to move rather than the estate you have, since filtering out dormant material can change the figure substantially. Add a margin for a second run, because there is almost always a second run.

What if a tool cannot carry something we need?

Decide early whether the thing is required or merely wanted. Requirements change the tool selection; wants get recorded in the list of what people will notice, and told to them before the move rather than after.