Quality & go-live · Cutover governance
The cutover forum: bringing every workstream into cutover
Most workstreams reach cutover planning after a year of design and build, and nobody has shown them what a cutover task looks like. One forum, homework handed out in the room, then a focused session per track gets them into the plan.
A forum is where a decision is allowed to be made.
By the time cutover planning starts properly, most workstreams have spent a year on design, build and test. They've heard the word cutover, but they haven't prepared for one. Ask a functional lead to contribute to the cutover plan and you get one of two answers: nothing, or a restatement of their project plan.
That gap is why cutover plans end up written by the delivery partner from a technical point of view, with no business tasks, no decision points and no departmental activity in them.
1Cutover lead
Teaches the vocabulary once, in front of everybody.
Asking without teaching produces nothing
The tracks aren't being difficult. Nobody has told them what a cutover task looks like, how much detail is wanted, or how their build work differs from their cutover work.
The two usual fixes fail in opposite directions.
One big workshop for everyone
The agenda is cutover in general, so nothing specific gets decided. Everyone leaves with a shared sense of concern and no actions. Emailing a template and hoping is a version of the same thing: few replies, and the ones that come back have to be fixed in the session anyway.
Straight into per-track sessions
The first hour of every session goes on explaining what cutover is, once per track, by a cutover lead who's saying it slightly differently the fifth time. Terms drift. The plan ends up using three words for the same freeze state.
What works: a forum, then homework, then one track at a time
- One forum, two hours, everyone. What cutover is, what freeze means, what will be asked of each track, and when. Teach the vocabulary once, in front of everybody. Tracks hear each other's questions, which surfaces cross-track issues weeks early.
- Homework handed out in the room. Two pages, a stated return date, and a worked example already filled in so people can see what a good answer looks like. People do their thinking before they walk into the session.
- Per-track sessions. Two to three hours per track, one track at a time, starting from the returned homework. What comes out is plan lines.
Teach the vocabulary before you ask anyone for anything. 2 hours of forum, once, for everyone. 2 pages of homework. Any longer and it comes back blank. 8 terms defined in front of everybody. 48 hours to turn session output into plan lines, before the detail decays.
2Sponsor
Opens the forum with ten minutes on why.
Two hours, once, and everyone leaves with a date
The forum has two jobs: give everyone the same vocabulary, and hand out the homework.
| Min | Block | What happens |
|---|---|---|
| 10 | Why | The sponsor opens. |
| 25 | What cutover is | One diagram, walked through. |
| 30 | What freeze means | Two real transactions, through every state. This is the block where the forum earns its cost. |
| 25 | What we need | The pack, field by field, with the worked example shown. |
| 30 | Questions and booking | Calendar open, sessions booked in the room. |
The output that matters most is dates in diaries. Sessions booked later don't happen.
Short and fixed beats long and open. One published vendor readiness workshop runs ninety minutes with a fixed agenda and hypercare team leads as mandatory attendees, covering scope, acceptance, integrations, blocking issues, the cutover plan, final data migration, go/no-go criteria and the support plan.[R9]
Teaching freeze so it lands
- Notice period
- Soft freeze
- Hard freeze
- Catch-up
Skip the abstract explanation of soft freeze. Take a transaction the audience does every week, walk it through the notice period, the soft freeze, the hard freeze and the catch-up, and say who does what at each point. Then do a second one that behaves differently.
Be concrete about which populations lose access and roughly when. Vagueness gets heard as a decision that hasn't been taken yet, which invites lobbying instead of preparation. Show what piles up, because the backlog is the part nobody anticipates.
Say what you don't know yet, with a date and a decision maker attached. That's more credible than implying a complete design. It also invites tracks to influence the open questions, which is what the session is for.
The forum costs two hours of a lot of people's time. It saves an hour at the start of every session that follows, plus the rework you get when five tracks use three different words for the same thing.
3Every workstream
Sends back two pages: what it owns, what can't stop, what it needs decided.
Two pages of homework, with a worked example on top
- Transactions
- Every transaction type you own, with rough volume
- Must continue
- Which of those can't stop, and what breaks if they do
- Cutover activities
- What you must do between the last normal day and the first supported day
- Dependencies
- What you need from others, and what others need from you
- People
- Who's available during the window, and who isn't
- Decisions needed
- Anything you can't proceed without a decision on
- Concerns
- Anything that worries you about cutover, in your own words
Send it with a worked example already completed. Response quality roughly doubles when people can see what a good answer looks like, and filling one in costs you twenty minutes. Tracks always list transactions the program didn't know about. The decisions section is often the most valuable thing that comes back.
Eight words to define once
Print these as a one-page reference inside the pack. People use it, and it keeps the plan's language the same across every track.
- Cutover
- The whole period from the last normal business day to the first supported day.
- They assume the go-live weekend.
- Freeze
- Restricted transaction entry, in defined states, per domain.
- They assume one date when the system switches off.
- Soft freeze
- Named users only, named transaction types only, everything else deferred.
- They assume a polite request to slow down.
- Blackout
- No access at all while extraction and load run.
- They assume it's the same thing as the freeze.
- Catch-up
- Entering everything deferred, after go-live, by named people.
- They assume the program handles it centrally.
- Gate
- A stop with named criteria and a named decision maker.
- They assume a status checkpoint.
- Cutover task
- One action, one owner, one predecessor, one validation.
- They assume a line in their project plan.
- Rehearsal
- A full dress run of the runbook, start to finish. The data load is one part of it.
- They assume the mock conversion they already did.
4First tracks in
Has the capacity to go early and sets the standard the other tracks copy.
Start with the tracks that have room to go first
Don't start every track at once. Early output is what makes the rest of the series easy to schedule.
Run early
Has capacity, simple
Quick wins that show the process works, with visible plan lines within days of the forum. Useful for showing the program that cutover planning has started.
Start here
Has capacity, complex
The highest value per session hour, and often the tracks that finished testing early. Their output sets the standard the other tracks copy, so use their session as the worked example for everyone else.
Lowest priority
No capacity, simple
A small cutover contribution you can gather later. Don't spend scheduling effort chasing them now. A short session or a written exchange may be enough.
Schedule late
No capacity, complex
Usually the biggest tracks, still finishing testing. They need the most session time and have the least to give. Prepare their draft material for them so the session is shorter, and don't let their unavailability delay the whole series.
5Functional lead
Brings the homework and leaves with plan lines and a date for the join session.
One track, one room, two to three hours
The session starts from the returned homework and ends with plan lines.
- 30 to 40 minWalk the homeworkWatch for lists shorter than reality.
- 60 to 90 minSequence the trackWatch for tasks that belong to another track.
- 20 to 30 minOwners and durationsWatch for names given on someone's behalf.
- 20 to 30 minFreeze and catch-upWatch for optimism about catch-up volumes.
- 10 minCloseDon't leave without a date for the join session. That's where cross-track work gets settled.
Facilitation is most of the difference. Read their homework and mark the gaps before you walk in. Prepare a draft sequence so the room has something to react to. Capture into the plan format live, on screen. Ask what has to be true before this can start, instead of what happens next. When someone says the partner does that, ask who on the partner side and get a name. Push back on durations that sound like round numbers. Stop on time and book a second session.
Report output after every session
Measure the series on what it produces. Report these after every session, because visible output within days is what keeps the sessions in people's calendars when testing gets busy.
- Tracks engaged
- Every track has had a session or has a booked date. None quietly skipped.
- Plan lines added
- The primary output. Report the count after every session.
- Owners confirmed
- An individual and a backup per line, confirmed with the person directly instead of through the track lead.
- Cross-track dependencies
- Found in join sessions. Nothing central can stand in for them.
- Unowned items found
- The fifth number. It usually rises through the series and then falls, and it's the clearest signal of whether the ownership work is being done. If it never rises, nobody is asking hard enough.
6Difficult tracks
Three or four in any program, each difficult for a different reason.
The tracks that resist, and what each one needs
Three or four tracks in any program will be difficult, for different reasons. Each needs a different response, and chasing doesn't work for any of them.
| Pattern | What it looks like | Response |
|---|---|---|
| Still in testing | Genuinely has no capacity, and says so. | Accept it, schedule them late and prepare their draft material. Don't treat it as resistance. |
| Thinks it isn't affected | Believes cutover is a technical exercise that doesn't touch them. | Walk one of their own transactions through the freeze in the room. That settles it in five minutes. |
| Sends a deputy | The person who knows the work isn't in the session. | Reschedule. The wrong person produces material that has to be redone. |
| Answers at project level | Cutover activities described as "complete data conversion." | Take one line and break it down live with them. They'll copy the pattern for the rest. |
| Won't name individuals | Offers a team name, because naming feels like blame. | Explain it as who gets called at two in the morning, and leave the word accountability out of it. That usually resolves it. |
| Owns something nobody wants | Handed an activity outside its competence. | Don't force it in the session. Record it as unowned and escalate it as a decision. |
7Named owner
Confirmed directly, one by one, with a backup for every line.
Session notes become plan lines within 48 hours
The session produces raw material. Converting it has to happen within days, or the detail decays and you have to interview the track again.
- Write it up in 48 hours. Use the agreed plan format, while the reasoning is still recoverable, and send it back for them to confirm.
- Confirm names directly. Contact each named owner individually. Names given in a session by someone else are proposals.
- Book the join sessions. Every dependency named implies a session with the other track. Book them as track sessions finish instead of saving them for the end.
- Feed the freeze design. Where two tracks classify the same transaction differently, resolve it explicitly and publish the update back.
From the field
The joins can't be assembled centrally. Merging two tracks' outputs at a desk looks efficient and invents dependencies neither track agreed to. Run the join sessions with both leads present, sixty to ninety minutes, two tracks at a time. They routinely surface several tasks neither track thought it owned, which is the kind of gap that stalls a window.
What has to follow the series
Three things have to follow the series. All three routinely get left out of the plan for the plan.
- A second pass for late tracks, scheduled explicitly. Their material is usually the thinnest, and they often carry the most cutover risk.
- The walkthrough. Read the whole plan out in sequence order with everyone present, so people hear where their work sits next to everyone else's for the first time. Read it out instead of presenting it. A presented plan gets nods. A read plan gets objections, and objections are what you're after.
- Folding in the rehearsal, treated as the main source of plan corrections instead of a pass or fail event. One published prescriptive guide books the post-cutover retrospective before the window opens, as a pre-migration checklist item.[R7]
8Decision maker
Named before the window opens, while it's still cheap.
In the window, the forum hands over to a faster cadence
The forum is a planning body. It has a successor, and the handover should be designed ahead of time.
As the window approaches, the pattern that works is a cadence that escalates, with workstreams pulled in when they need intervention instead of on a fixed calendar. One published health system program ran bi-weekly operational readiness meetings led by named operational leads. It added a weekly session that any workstream needing intervention had to attend, to present its recovery plan for comment and escalation, and those calls moved to daily for a specific workstream as required.[R2]
- Bi-weekly Operational readiness meetings, led by named operational leads
- Weekly Any workstream needing intervention attends and presents its recovery plan
- Daily Calls for a specific workstream, as required
The forum pulls a track in when it goes red, without waiting for the next scheduled slot. Prescriptive migration guidance formalizes the same idea as a communication and governance plan with a channel, method, owner and frequency per audience, so senior stakeholders, the technical team and downstream operations each get told different things at different times.[R6]
Federal migration methodology is explicit about level: encourage decisions at the lowest possible level while allowing important or contentious issues to be raised through the governance model, alongside daily meetings to monitor progress.[R1] National audit work found the same from the other direction. On one multi-organization program, a group of workstream senior owners became the main forum for program-wide operational decisions in the run-up and was judged more effective than its predecessor. The same report warns that adding boards risks confusing a program.[R3]
When a decision is taken outside the forum
- £48.65M
Combined regulatory penalty after a retail bank's core banking migration. A decision to cut the scope of non-functional testing was taken outside the appropriate governance forum and treated internally as a purely technical decision.[R4][R5]
- £32.7M
Paid in customer redress on the same migration. The regulator found the bank failed to take that decision within the governance structure meant for such decisions and escalation.[R5]
- 3
Separate bodies authorized that migration in stages: a board sub-committee to initiate, an executive team to execute, and the sub-committee again to complete. All were defined before the window.[R4]
Name the decision maker while it's still cheap. Vendor implementation guidance puts defining who makes the final go/no-go call, and the criteria for how many open defects are acceptable, inside the cutover strategy instead of leaving it to the meeting.[R8]
A forum is where a decision is allowed to be made. Teach the vocabulary once, hand out the homework in the room with a worked example, run focused sessions from prepared material and report output after every one. Then the people who have to execute the cutover plan are the ones who wrote it, which is what makes it hold.
Sources
- R1 US General Services Administration, "Modernization and Migration Management (M3) Playbook, Phase 4: Migration." ussm.gsa.gov
- R2 Published health system board paper on an electronic patient record program cutover, March 2022. ashfordstpeters.info
- R3 UK National Audit Office, "Lessons learned: Governance and decision-making on mega-projects," HC 545, March 2025. nao.org.uk
- R4 Financial regulator final notice concerning a retail bank core banking migration, December 2022. fca.org.uk
- R5 Financial regulator press release confirming penalties and redress for the same migration, December 2022. fca.org.uk
- R6 Amazon Web Services, "Best practices for cutting over network traffic to AWS during a migration," AWS Prescriptive Guidance. docs.aws.amazon.com
- R7 Amazon Web Services, "Creating a cutover runbook for application migration," AWS Prescriptive Guidance. docs.aws.amazon.com
- R8 Microsoft, "Transition to new solutions successfully with the cutover process," Dynamics 365 Implementation Guide, 2024. learn.microsoft.com
- R9 Microsoft, "Go-live readiness workshops," FastTrack guidance, 2023. learn.microsoft.com
Public cautionary cases are cited by source and left unnamed in the body so the article stays vendor and organization neutral. Field examples come from real Workday and ERP implementations, fully anonymized. General guidance, not legal or regulatory advice.
The cutover plan construction standard, on two pages.
The task schema, the line-level quality bar, the decomposition rules, the dependency types and the baseline gate, plus the workstream homework pack and the vocabulary sheet. Built to hand out in the forum.
Run the forum with someone who has run it before.
If you're about to ask fifteen workstreams for cutover input and you're not sure what to ask for, an independent facilitator through the first three sessions sets the standard for the rest.