The cutover playbook: how Workday and ERP go-lives get done

Teams underrun cutover because they picture it as flipping a switch. In practice it's a coordinated shutdown of the old world and stand-up of the new one: hundreds of tasks, dozens of owners, tight dependencies and a clock running the whole time. The programs that come through it clean run cutover as its own project, with one named owner. Run it by committee and nobody is there to make the 3 a.m. call.

Two documents do the work, and teams keep collapsing them into one. The freeze schedule is the timetable of what stops in the legacy systems and when. The cutover plan is the sequenced list of tasks to build, load and validate the new tenant so real users can log in. Keep them apart, and have the cutover manager reconcile the two every day.

In Workday you don't cut over into an empty system. Customers run a chain of tenants. Production is the live source of record. Next to it sit Sandbox, refreshed weekly as a copy of production, and Sandbox Preview, which gets feature updates ahead of production so you can test releases early. For a deployment you also buy implementation tenants, direct replicas used for configuration, quality assurance, user acceptance testing, integration testing and training. A common deployment runs 4 to 10 or more active implementation tenants at once.

The one that matters at cutover is the gold tenant: the pre-production build where final configuration and converted data get assembled, validated and frozen. When quality sign-off lands, that build is what moves into production. The formal gate is the move-to-production (MTP) authorization, and in Workday that's a signed form. Two milestones in the cutover plan anchor everything else: gold build complete and gold customer validation. Miss either date and everything downstream slips.

More cutovers fail on data than on anything else, and it runs through nearly every public ERP disaster. A US utility's SAP failure came down to inaccurate data conversion and not enough capacity. 2 months in, its unpaid-supplier backlog topped 15,000 invoices. The discipline that prevents it is boring and repetitive. You run mock conversions in a loop: build the conversion, load it into a lower tenant, assess the results, refine the automated package, clean more data in the source system, and repeat until the load is clean enough for the final production conversion. Mock runs do double duty. They prove the data is right, and they time the load so your go-live window is measured instead of guessed.

Reconcile in three stacked layers. Record counts and control totals come first, the fastest check for missing or extra rows. Field-level reconciliation comes next, with values checked against the transformation rules. Then business-process validation: run a real transaction end to end (requisition to payment, hire to paycheck) to prove the converted data and the configuration work together. For financials, tie the converted trial balance to the pre-cutover totals to the penny, and treat any control-total break as a hard stop. Load in dependency order: master data, then open transactions, then opening balances. Load out of order and you get orphaned records.

The freeze stops change in the legacy systems so the final data extract is clean and stable. Get the vocabulary exact so nobody has to guess. Every item gets one of three treatments, and each freeze item names what's frozen, who owns it, when the freeze starts, and in plain language what users can and can't do.

The design mistake is freezing by system. Make the blackout too long and operations rejects it, then breaks it anyway. Make it too short and you create conversion deltas that surface in the first close. Freeze by process instead: hard-freeze supplier creation and bank-detail changes early while invoice entry keeps running later, each with its own documented workaround. Whatever happens during the freeze gets logged and caught up after go-live. That catch-up is real work, so plan it: a delta conversion cycle to capture freeze-window activity, plus manual entry of the critical transactions that couldn't wait.

The runbook is a step-by-step execution plan, written so a leader who didn't build the system can still run the event. Every step carries a verb-based name, a named owner and backup, prerequisites, a planned start, finish and duration, validation evidence, exception handling and a backout action. If a step depends on tribal knowledge ("she knows how to run that script"), it isn't ready. Build proof points into the runbook itself: small, fast pass-or-fail checks with evidence capture, like the trial balance tying out or a handful of day-one transactions clearing workflow approval. Then enforce the golden rule. If a task isn't in the plan, it doesn't happen.

Run parallel payroll to confirm what you already believe is right. Nowhere does a conversion or configuration error surface faster than in pay, so if the first cycle turns up big problems, you started too early and you'll be running it again. Start with a mini-parallel, a small hand-picked subset of the workforce used as a proxy. A clean mini-parallel is your green light for full parallel. Review a full year of legacy payroll to catch the pay components that don't show up every month (seasonal staff, annual bonuses) and build scenarios for them, or you'll meet them in production instead of in a safe tenant.

Validate in layers and classify every discrepancy. Check totals, then employee, then element, which is where most errors hide. Sort each difference into must-match, allowed-with-explanation or unknown. Net pay by employee, tax withheld by jurisdiction, employer tax, deduction totals and total funding are must-match, and a mismatch with no root cause is a no-go. The bank file is a separate failure surface from the calculation, so test the transmission and the posting on their own.

The same rule holds beyond payroll. All in-scope testing (configuration, integration, end-to-end, payroll parallel, performance, regression) gets signed off before the go-live authorization, and no program goes live carrying an open critical defect, whatever the date says.

Go-live decisions fail when a date drives them instead of evidence. "We finished building" and "we're ready" are different claims, and only the second one keeps you out of trouble. Readiness means every domain independently confirmed, with proof behind it. Watch five domains.

Technical

Code freeze enforced, interfaces tested, no open critical or high defects.

Process

Integration and end-to-end testing passed.

Data

Dry runs reconcile within tolerance, owners signed off by domain.

User

User acceptance testing signed off in writing per business area, training done.

Operations

A runbook with owners and durations, monitoring configured, hypercare staffed, rollback documented and tested.

Every green rating needs evidence behind it. Every amber or red needs a mitigation plan with an owner and a date.

The go/no-go meeting carries more weight than any other meeting in the program, and it needs five things: the readiness scorecard rated by domain with supporting data, the open risk register, a defect summary by severity, the outstanding items with real dates, and an explicit recommendation of go, no-go or conditional-go with the conditions named. Score it, then let the hard gates override the score.

A program sitting at 92% green is still a no-go if it carries one unresolved critical defect, a data variance over tolerance, an unproven rollback or unstaffed hypercare. One deal-killer is an automatic no-go, whatever the average says.

The biggest shape decision is whether you cut everything over at once or in waves. It changes the freeze, the command center and the rollback plan, so decide it early and honestly. Big-bang concentrates risk into one window you can rehearse cold. Phased spreads the risk but multiplies the freezes, the catch-ups and the number of go-lives you have to run. Neither is safer in the abstract. The answer comes out of your entity count, your time zones and how immovable the deadline is.

You build the rollback plan hoping never to use it, and it's what lets everyone stay calm during the window. It has three parts. First, triggers defined in advance: opening balances that won't reconcile within tolerance, a critical integration down with no fix path inside the window, smoke tests failing on core flows. Second, a procedure. Legacy is still frozen and intact, so rollback means restoring write access, reversing external cutovers and communicating a new date. Third, a single named decision authority, usually the executive sponsor acting on the cutover manager's recommendation. With all three written down in advance, the 2 a.m. call is mechanical.

Two things keep this honest. Rollback is rarely a clean switch back to the old system. More often it means delaying go-live, extending dual-running, or running a controlled contingency process until you can re-attempt. And there's a real point of no return, which moves per stream: some streams keep the rollback option long after others have crossed into fix-forward only. A well-rehearsed cutover almost never rolls back. A rollback executed cleanly at hour 30 is a footnote, while a failed launch pushed through on hope costs you a quarter of firefighting. None of it is available unless legacy stays alive and untouched through the window, so it can't be decommissioned at cutover.