Cutover and Go-Live for Finance Systems

Cutover is the tightly-planned transition from the old system to the new one — migrating the data, switching over, and going live — usually inside a short, high-stakes window. Go-live is the moment within it when the new system becomes the system of record. For finance systems, cutover is dominated by two things: getting the opening balances exactly right, and timing the whole thing around period-end so the books are clean. It's the phase where months of good work are either landed safely or undone in a weekend — which is why it's run from a rehearsed runbook, not improvised.

What cutover and go-live are

Cutover is the sequence that takes you from "built and tested" to "live, old system retired." Go-live is the point of no return inside that sequence — gated by a formal go/no-go decision. Everything before go-live is reversible; everything after commits you to the new system for real.

Why finance cutover is high-stakes

Most systems start empty. Finance systems start with the entire past carried forward:

• Opening balances must be exact. Every account balance in the new system has to tie, to the penny, to the old one at the cut. A wrong opening balance corrupts every report from day one.
• Open items can't be lost. In-flight invoices, unreconciled payments, open deals — miss one and it simply vanishes from the books, surfacing months later as an unexplained difference.
• The window is narrow. Finance cuts over around a period boundary, so the migration, reconciliation and checks are compressed into the few days the books are quiet.

"

Most systems go live empty and fill up. Finance systems go live full — with every balance and open item carried across — which is why the migration, not the software, is where cutover succeeds or fails.

The cutover plan is a runbook

A cutover plan is not a milestone in a Gantt chart — it's a runbook: a minute-by-minute sequence of tasks, each with a timing, an owner, a dependency, and a done-check. "Extract balances from legacy (Fri 18:00, owner: X), load to new (Fri 20:00, owner: Y), reconcile (Sat 09:00, owner: Z)…" The plan's job is that on the day, nobody is improvising — they're executing a script that's already been proven.

Data migration is the core

The bulk of finance cutover is data migration, in three layers:

• Master data — accounts, entities, bank details, counterparties, standing instructions. Migrated and validated first.
• Opening balances — the carried-forward position at the cut.
• Open items — the in-flight transactions that must continue their life in the new system.

And the non-negotiable rule: reconcile every migrated layer. Migration isn't done when the data loads; it's done when the loaded data is proven equal to the source. Counts and control totals, source versus target, exactly as with any interface.

Timing around period-end

Finance cuts over at a period boundary — ideally right after a close — so there's a clean line: the old system owns everything up to the cut, the new system owns everything after. Cutting over mid-period means splitting a period across two systems, which turns the first close into a reconciliation nightmare. Pick the boundary, and protect it.

The go/no-go decision

Before go-live, a go/no-go checkpoint: against pre-agreed criteria — migration reconciled, critical checks passed, UAT signed off, support ready — the accountable owners decide, explicitly, to proceed or not: a governance decision in its own right. The value is having defined the criteria in advance, so the decision is made against a standard, not against how tired everyone is at 2am.

Rehearse it, and plan the fallback

Two things separate calm cutovers from disasters:

• A dress rehearsal. At least one full mock cutover on a copy — run the entire runbook end to end, time it, find what breaks. The real cutover should be the second time you've done it, not the first.
• A fallback plan. A defined way back if go/no-go fails or something breaks past the point of proceeding. Knowing you can revert is what makes the go decision safe to take.

Hypercare after go-live

Go-live isn't the end — it's the start of hypercare: a period of heightened support right after, when the real users hit real edge cases and need fast help. Staff it deliberately. The first close on the new system is the true test, and it's where issues the whole project missed finally show up.

What usually goes wrong

• Unrehearsed cutover. The runbook's first real run is the live one, so the surprises land at the worst possible moment.
• Unreconciled migration. Data loaded but not proven equal to source, so a wrong opening balance is discovered weeks later in the books.
• No go/no-go criteria. The decision to proceed is made on optimism and fatigue, not evidence.
• No fallback. No way back, so a failing cutover has to be pushed forward regardless.
• Cutting over mid-period. No clean boundary, so the first close spans two systems and reconciles to nothing.

Run cutover from a rehearsed runbook, migrate and reconcile every layer, cut at a period boundary, gate go-live with real go/no-go criteria, keep a fallback, and staff hypercare — and the riskiest weekend of the project becomes a controlled, boring success. Which, for a finance go-live, is exactly what you want it to be.

Work the gate: the free Cutover & Go-Live Readiness Checklist turns this into a live go/no-go — the critical items gate the verdict, and it never shows GO until open items are owned and an authorized owner has actually decided.

Part of the Finance Systems Delivery guide. See also user acceptance testing and fit-gap analysis. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.