Cutover and Go-Live
The window where the old system stops and the new one starts. Usually 48–96 hours, always over a weekend or a month-end, and always the most stressful part of the project.
The cutover plan
A minute-by-minute task list with owners, durations, and dependencies. For a mid-size implementation: 200–600 tasks.
# Task Owner Start Dur Depends Status
────────────────────────────────────────────────────────────────────────────────────
001 Communication: system freeze notice PMO Thu 17:00 — — ✅
002 Stop new transactions in legacy Ops Fri 18:00 — 001 ✅
003 Complete in-flight legacy transactions Ops Fri 18:00 2h 002 ✅
004 Final legacy backup Infra Fri 20:00 1h 003
005 Legacy trial balance extract Finance Fri 21:00 30m 003
006 Final master data extract DataTeam Fri 21:00 1h 003
007 Final open items extract DataTeam Fri 22:00 1h 003
008 Transport final config to PRD Basis Fri 22:00 1h —
009 Transport final code to PRD Basis Fri 23:00 1h 008
010 PRD smoke test QA Sat 00:00 1h 009
011 Load org structure and config DataTeam Sat 01:00 30m 010
012 Load business partners DataTeam Sat 01:30 2h 011
013 Reconcile business partners Finance Sat 03:30 1h 012
014 Load materials DataTeam Sat 03:30 3h 011
015 Reconcile materials SupplyCh Sat 06:30 1h 014
...
042 Load GL opening balances Finance Sun 06:00 2h all loads
043 Trial balance reconciliation Finance Sun 08:00 2h 042
044 ★ GO/NO-GO DECISION Steering Sun 11:00 1h 043
045 Enable user access Security Sun 12:00 1h 044
046 Activate interfaces Integr. Sun 13:00 1h 044
047 Activate background jobs Basis Sun 14:00 30m 044
048 First transaction validation KeyUsers Sun 15:00 2h 045
049 Business readiness confirmation Ops Sun 17:00 — 048
050 Communication: system live PMO Sun 18:00 — 049
Every task has a named owner, a duration, and dependencies. “Team” is not an owner. Print it, put it on a wall, and update it in real time.
The rehearsal
Do the full cutover at least twice before the real one. Not a walkthrough — an actual execution against a production-sized copy.
The rehearsal answers:
- Does it fit in the window? (It usually doesn’t the first time)
- Which tasks take longer than estimated? (Data loads, always)
- What did we forget? (There’s always something)
- Do the dependencies work?
- Can the team physically sustain it?
Rehearsal outcome you want to see: the plan finishing 6+ hours before the window closes. That buffer is what absorbs the problem you haven’t thought of yet.
The freeze
T−14 days Master data change freeze (except emergencies, with approval)
T−7 days Configuration freeze in DEV
T−5 days Code freeze; final transports built
T−3 days Legacy: no new master data, no new orders beyond the cutover date
T−1 day Legacy: transaction freeze — the business stops
T Cutover window
T+1 Go live
The freeze is a business decision with a real cost — a company that can’t take orders for 48 hours loses revenue. Which is exactly why cutover windows are weekends, holidays, or the annual shutdown period.
Data loads during cutover
Loads follow the dependency order from Data Migration. During cutover specifically:
- Each load is followed immediately by reconciliation. Don’t batch all loads then reconcile — you lose the ability to isolate a problem.
- Each reconciliation is signed off by the business owner before proceeding.
- A failed reconciliation triggers the escalation path, not “we’ll fix it Monday”.
- Every load is timed, and actuals are compared to the rehearsal.
The go/no-go decision
A scheduled meeting with defined attendees and defined criteria, at a defined point in the plan. Not a vibe check at 3am.
GO/NO-GO CHECKLIST
[ ] All data loads complete and reconciled, signed off per object
[ ] Opening trial balance matches legacy exactly
[ ] Smoke test passed: create order → delivery → invoice → payment
[ ] Interfaces tested end to end with real partners
[ ] Critical reports produce correct numbers
[ ] User access provisioned and spot-checked
[ ] Support team in place and reachable
[ ] No open critical defects
[ ] Business confirms readiness to operate
Decision: GO / GO WITH CONDITIONS / NO-GO (rollback)
Decided by: Steering Committee
Time: Sunday 11:00
“Go with conditions” is a legitimate and common outcome — go live, with a named workaround for a specific issue and a fix committed by a date. It needs to be documented, not verbal.
Rollback
You must have a plan, and you must have rehearsed it.
ROLLBACK TRIGGER: any of —
- Opening balances cannot be reconciled
- Critical business process demonstrably broken
- Data corruption detected
- The window will be exceeded with no path to completion
ROLLBACK PROCEDURE:
1. Steering committee decision (only they can call it)
2. Communicate to all users immediately
3. Restore the legacy system to writable
4. Unfreeze legacy transactions
5. Restore the ERP database to its pre-load state
6. Communicate the new plan and date
7. Post-mortem within 48 hours
ROLLBACK DEADLINE: the point after which rollback is no longer possible
— typically once users have entered live transactions in the new system.
Know this time. Mark it on the plan.
The rollback deadline is the most important time on the cutover plan. After it, you are going forward whatever happens. Everyone should know when it is.
Hypercare
The first weeks after go-live.
Week 1 Project team on-site, floor walkers, war room, daily issue triage
Week 2-4 Reduced on-site presence, daily triage continues
Week 4-6 ★ FIRST MONTH-END CLOSE — the real test
Week 6-8 Transition to normal support
Week 8+ Formal handover; project closure
The war room
A physical or virtual room where the project team sits together during hypercare:
- Issues logged, triaged, and assigned within minutes
- Daily stand-up with the business
- A visible issue board
- Direct escalation path to decision-makers
Floor walkers — project team members physically among the users for the first week — are disproportionately effective. Most day-one issues are “I don’t know how to do this”, not defects, and a five-second answer beats a two-day ticket.
The first month-end close
This is the moment the project is actually judged. Everything up to now was transaction entry; the close is where errors in configuration, migration, and design become visible as numbers that don’t reconcile.
Plan for it:
- The full project team available
- A rehearsed close checklist
- Extra time in the schedule (the first close takes 2–3× normal)
- Reconciliations at every step, not just at the end
- Someone senior from finance who can make judgement calls
Issue triage during hypercare
P1 Business stopped Response 15 min, fix immediately, 24/7
P2 Major process impaired Response 1 hour, fix same day
P3 Workaround exists Response 4 hours, fix within a week
P4 Minor / cosmetic Next release
Common day-1 categories:
40% "How do I…" → training gap, not a defect
25% Authorisation missing → role design gap
15% Master data missing/wrong → migration gap
15% Genuine defects
5% Performance
That 40% is normal and predictable. It’s why floor walkers and quick-reference guides matter more in week one than developers do.
Communication
Under-communicated cutovers create panic. Over-communicate:
T−30 What's changing, when, and what it means for you
T−14 Training schedule and freeze dates
T−7 Detailed timeline; who to call for what
T−1 "System unavailable from Friday 18:00"
T Regular updates during the window, even "on track, no news"
T+0 "System is live" with the support contacts
T+1 Daily updates for the first week
Silence during the cutover window is interpreted as disaster. A scheduled “still on track” message every four hours costs nothing and prevents a lot of speculation.
Post-go-live watch list
Monitor closely for the first month:
- Interface error queues — check hourly at first
- Failed background jobs
- Documents stuck in incomplete or blocked status
- GR/IR and clearing account balances (should net near zero)
- Subledger to GL reconciliations
- System performance and response times
- Authorisation failure logs (reveals role design gaps)
- Number range consumption
- User adoption — are people actually using it, or reverting to spreadsheets?
- Open issue count and trend
That last one is the key health indicator. Issue count should peak in week 1 and decline steadily. A flat or rising trend at week 3 means something structural is wrong.