- 1. Building the plan
- 2. Ownership and the RACI
- 3. The cutover forum
- The cutover playbook
By the time cutover planning starts properly, most workstreams have spent a year on design, build and test. Cutover is a word they have heard. It is not a thing they have prepared for. 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.
They are not being difficult. Nobody has told them what a cutover task looks like, what level of detail is wanted, or how their build work differs from their cutover work. Asking without teaching produces nothing.
1Two standard approaches, two opposite failures
2Forum, homework, then focused sessions
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 caused by five tracks using three different words for the same thing.
Measure the series on output, not attendance. Report these after every session, not at the end, because visible output within days is what keeps the sessions in people's calendars when testing gets busy.
Track the count of unowned items found. It usually rises through the series and then falls, and it is the clearest signal of whether the ownership work is being done. A series where that number never rises is a series where nobody is asking hard enough.
3Which tracks start first
Do not start all tracks at once. Early output is what makes the rest of the series easy to schedule.
Has capacity, complex: start here
- Highest value per session hour
- Their output sets the standard other tracks copy
- Often the tracks that finished testing early
- Use their session as the worked example for everyone else
No capacity, complex: schedule late
- Usually the biggest tracks, still finishing testing
- Need the most session time, have the least to give
- Prepare their draft material for them so the session is shorter
- Do not let their unavailability delay the whole series
Has capacity, simple: run early
- Quick wins that demonstrate the process works
- Visible plan lines within days of the forum
- Useful for showing the program that cutover planning has started
No capacity, simple: lowest priority
- Small cutover contribution, gatherable later
- Do not spend scheduling effort chasing them now
- A short session or a written exchange may be enough
4The forum agenda
Two hours, once. The objective is not to plan anything. It is to establish shared vocabulary and issue the homework.
Teaching freeze so it lands. Do not explain soft freeze in the abstract. 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, because vagueness gets heard as a decision not yet taken, which invites lobbying instead of preparation. Show what accumulates, because the backlog is the part nobody anticipates. And say what you do not know yet, with a date and a decision maker attached. That is more credible than implying a complete design, and it invites tracks to influence the open questions, which is what the session is for.
5The homework pack
6The words to define once
Print this as a one-page reference inside the pack. It gets used, and it keeps the plan's language consistent across every track.
7The per-track session
8The tracks that resist
Three or four tracks in any program will be difficult, for different reasons. Each needs a different response and none of them is chasing.
| Pattern | What it looks like | Response |
|---|---|---|
| Still in testing | Genuinely has no capacity, and says so | Accept it, schedule late, prepare their draft material. Do not treat it as resistance |
| Thinks it is not affected | Believes cutover is a technical exercise that does not touch them | Walk one of their own transactions through the freeze in the room. Settles it in five minutes |
| Sends a deputy | The person who knows the work is not in the session | Reschedule rather than proceed. 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 decompose it live with them. They copy the pattern for the rest |
| Will not name individuals | Offers a team name, because naming feels like blame | Explain it as who gets called at two in the morning, not as accountability. Usually resolves it |
| Owns something nobody wants | Handed an activity outside its competence | Do not force it in the session. Record it as unowned and escalate it as a decision |
9Turning session output into plan lines
The session produces raw material. Converting it has to happen within days, or the detail decays and the track has to be interviewed again.
The joins cannot be assembled centrally. Taking two tracks' outputs and merging them 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 exactly the class of gap that stalls a window.
Three things have to follow the series and all three routinely get left out of the plan for the plan. The second pass for late tracks, scheduled explicitly rather than assumed away, because their material is usually the thinnest and they often carry the most cutover risk. The walkthrough, where you read the whole plan out in sequence order with everyone present, so people hear where their work sits relative to everyone else's for the first time. Read it rather than presenting it: a presented plan gets nods, a read plan gets objections, and objections are the point. And folding in the rehearsal, treating it as the primary source of plan corrections rather than 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].
10What the forum becomes during the window
The forum is a planning body. It has a successor, and the handover should be designed rather than assumed.
As the window approaches, the pattern that works is escalating cadence with workstream-triggered intervention rather than a fixed calendar. One published health system program ran bi-weekly operational readiness meetings led by named operational leads, plus a weekly session to which any workstream requiring intervention was mandated to attend and present its recovery plan for comment and escalation, and those calls moved to daily for a specific workstream as required [R2]. The forum pulls a track in when it goes red. It does not wait 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 on level: encourage decisions at the lowest possible level while allowing elevation of important or contentious issues 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 decision-making in the run up, and was judged more effective than its predecessor, while the same report warns that adding boards risks confusing a program [R3].
Name the decision maker while it is 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 rather than leaving it to the meeting [R8].
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.