The fantasy: "we will migrate everything Friday"
Go-live migrations fail when teams treat history like a file dump. Operators need open work in the new tool by Monday morning. Finance needs closed periods left untouched. Customers need continuity on references, PO numbers, and attachments. The fantasy migration — a perfect replay of fifteen years by the weekend — creates a reconciliation project that eats the entire benefit of the new system.
Migration is not copy-paste. Master data, open work, history, and attachments each need a deliberate rule, or go-live becomes operational debt on day one.
Buckets to decide explicitly
| Bucket | Typical rule |
|---|---|
| Master data | Customers, products, sites — clean once, owner signed off |
| Open work | Jobs, orders, tickets in flight — migrate with state mapping |
| Closed history | Read-only archive or summary — rarely worth perfect replay |
| Attachments | Often the hidden cost — size, PII, links that break |
Master data is where you fix duplicates and spelling — not after go-live under fire. Open work needs a state map: old status to new status, with explicit "do not migrate" rules for zombie records. Closed history often belongs in read-only storage or a summary table; finance may only need totals, not every line replayed. Attachments break links, blow up storage, and carry GDPR questions. Plan them before Friday night, not during it.
Questions before build budget
Who reconciles mismatches when counts disagree? What is the rollback story if Monday is a disaster — can you run parallel for a week? What report proves parity on the first Monday — same open jobs, same AR balance within tolerance?
Who freezes changes during cutover? What happens to new orders created during the window? Name a war room owner with the same discipline as clear ownership for system projects.
Cutover week without heroics
Run a dress rehearsal with a copy of production, not vendor sample data. Time how long open job migration takes. Test login and permissions for every role that starts Monday — including temp accounts if seasonal ramp overlaps with your go-live.
Communicate customer-facing reference rules clearly: will invoice numbers change? Will portal links break? Training that sticks, as described in training that survives go-live, starts with "what is different on Monday" — not a generic feature tour.
Data quality is not a migration day task
Clean master data in the weeks before cutover — duplicates, dead customers, product codes nobody uses. Assign a data owner who signs off counts, not the project manager who never posts invoices. Bad master data migrates perfectly and fails loudly in production.
For open work, agree what happens to jobs in strange states — on hold, disputed, partially invoiced. Zombie records become Monday's fire. A short "do not migrate" list is healthier than pretending history is clean.
At a glance
Pair this with first 30 days after a build. Book a review — Teesside and the North East. If you are already living a bad migration, rescue is available before denial becomes the plan.