Tool Documents

Running a Migration

A migration is usually estimated as a data transfer and delivered as a change project. The gap between those two is where the overrun lives.

Reviewed August 9, 2026.

The six phases

Inventory. What exists: data objects, configuration, integrations, users, permissions, documents. For a separate operational reference from Monitask, see this overview.

Decide what moves. Not everything should, and this is the decision that determines cost.

Map. Old field to new field, old status to new status. This is where the two data models meet and where the awkward cases surface.

For broader context, see Okta.

Rebuild configuration, which does not transfer and is the largest phase in most migrations.

Move the data, which is the mechanical part and the one everybody budgeted for.

And run in parallel, briefly, before switching off the old system.

The two decisions that determine cost

How much history moves.

Everything is expensive, slow, and imports years of records nobody will open.

Nothing is cheap and loses the reason people trusted the old system.

The workable answer is usually a cut-off: active records and a defined period of history move; everything older stays in a read-only archive or an export file. That single decision frequently halves the work.

And how faithfully configuration is reproduced.

Recreating the old setup exactly carries every accumulated compromise into the new tool. A migration is the only free opportunity to drop them, and organisations that reproduce faithfully spend the money and keep the problems.

The archive to keep

A full export of the old system, in a readable format, filed somewhere durable.

Not in the new tool. A file, with a date, in storage you control.

This is what makes the cut-off decision safe — history that did not migrate is not lost, it is in an archive, and the number of times anybody opens it will be small and non-zero.

And it is a statutory requirement in some categories. Accounting records outlast the software that produced them.

What goes wrong

Configuration underestimated, which is the standard overrun.

The awkward records. Every data set has some that do not map, and the plan needs a rule for them rather than a discovery.

Integrations rebuilt after the switch rather than before, which produces a period where things silently do not run.

And adoption. The new tool is worse than the old one for two weeks regardless of quality, and a migration that has not planned for that fortnight loses people during it.

Running parallel

Short. Two weeks is usually enough; two months means nobody commits to either system.

With a stated switch-off date communicated in advance.

Read-only on the old system for a defined period afterwards, if the contract allows it — and check whether it does, because access after termination is a contract term rather than a courtesy.

The short version