The data object migration plan: what moves, and when

Whether a cutover is calm or chaotic is rarely decided by the ETL. It's decided by whether someone wrote down, weeks earlier, exactly what data moves into the new system — and on which day.

What most people call a "migration plan" is really a field-mapping spreadsheet: this source column goes to that target field. That mapping matters — it's one of the steps in my 8-step method per data object — but it only answers how a single object is translated, not what moves when. The migration plan sits one level above: the overarching timeline across all data objects — what loads when, who freezes what, and when the business has to stop creating data in the old system. Here's the shape of it.

A note on the labels: TGL is the technical go-live — the point where the system is deployed, migrated and IT-ready, but before anyone starts using it. BGL, the business go-live, is when the organisation actually switches over and starts working in it, often the next morning (TGL on a Sunday evening, BGL Monday morning). Every offset here counts back from TGL, because that's the date the migration has to hit.

Bulk load, then delta load

You don't move everything in one heroic overnight run. You stage it.

A bulk load is the first full load of an object, done well ahead of go-live. A delta load is everything that was added or changed in the source since that bulk load — you catch up the difference. So you load the master data weeks early, let people keep working in the old system, and accept that your copy goes stale immediately. That's fine: catching up the difference is exactly what the delta is for. Close to go-live you migrate the transactional and inventory data — the open orders that are left, plus stock balances and their cost — reconcile, and go live.

Staging this way turns one impossible night into a series of manageable steps — and, crucially, it lets you rehearse. A bulk load you can run a month early is a bulk load you can run twice.

Master data and transactions freeze on different dates

This is the part most plans get wrong, and it's the whole reason the plan needs dates rather than a checklist.

Master data — items, customers, suppliers, prices, structures — is stable and forgiving. It changes, but slowly and predictably, which is why a delta handles it comfortably. So you can freeze it early: say a week before go-live, no new items, no customer changes. Just before the freeze you run one final delta of all master data, so the frozen copy is complete and current — after that master data is done, and the cutover itself only has to move transactions.

Transactional data — open orders, balances, in-flight documents — lives right up to the last minute. A record that was correct on Tuesday is wrong by Friday. So it gets a later, separate cutoff, a few days out: the window where the business stops creating new orders and deals with the open ones. Concretely, in a retail setting: warehouses and stores have to finish any goods receipt before the cutoff, and after that date they make no stock transfers or other transactions in the systems. It's a hard, physical deadline — not a soft suggestion.

Two data types, two freeze dates. Say both to the business early and loudly, because these are real operational constraints — people can't just keep working as normal — and everyone will forget which date applies to what. A freeze isn't a technical event. It's a decision about when users must stop creating and changing data, and it belongs to the business, not the migration team.

The cleanest way to migrate a hard object is to not migrate it

The hardest objects to migrate are open transactions. So empty them in the real world before the transactional cutoff, and there is nothing left to migrate.

On a recent retail cutover, the rule for open sales orders was exactly that: the warehouse took ownership of clearing the board — ship everything shippable, cancel every line that won't ship — so that by migration day there were effectively none left to carry across. The messiest data object was solved operationally, by the people who own the process, not technically, by a script. (For a worked example of what "open" really means at the line level — part-received, part-invoiced — see migrating into Infor M3.)

That's the mindset shift: some of your worst data problems aren't data problems. A back-order is real customer demand — you can't just "close" it in a script without either losing the demand or re-keying it natively in the new system, and that is a business decision, not an ETL rule. So you push those decisions to the process owners, early, and shrink the technical migration down to only what genuinely has to move.

The plan is a dated runbook with named owners

Put those two ideas together and the artefact almost writes itself. For each data object, one line:

• what it is (customers, open POs, GL opening balances),
• how it moves (bulk, delta, or "closed in the source, not migrated"),
• when — the calendar day relative to go-live,
• who owns it — a named person, not a team.

That is the plan. Not a mapping spreadsheet — a runbook. And it's deliberately a work in progress: you draft it early, walk it with the business, discover that the finance close needs an extra day for invoice matching, that back-orders have no clean owner, that history nobody agreed to archive is quietly assumed to migrate. Every one of those is a question you want to answer in a planning meeting, not at 3am on cutover night.

Reconcile every pass, too — on value, not just row counts, so you catch the load that "succeeded" but carried the wrong number. That deserves its own treatment: proving the migration was correct.

The takeaway

The teams that struggle treat migration as a technical lift-and-shift and meet the business questions on cutover night. The teams that sail through have already had the awkward conversations — what's the master freeze date, what's the transactional cutoff, who clears the back-orders, where does history actually live — weeks earlier, when there was still time to answer them.

Decide early what moves and when, give master data and transactions their own freeze dates, and clear the hardest objects in the real world before you migrate anything. Write it down as a dated runbook with named owners.

Do the boring planning. The migration is the easy part.

Planning a cutover and want a migration plan that holds up on the night? Get in touch — I'm happy to share how I work.

---

Related reading: Migrating into Infor M3 · Migrating into Business Central with RapidStart · Big bang vs. phased migration · Reconciliation: proving the migration was correct.