The cutover plan is the most carefully written document a release ever gets. It has a start time. It has a change window with a hard end. It names who flips DNS at 02:10, who runs the data migration at 02:25, who calls the rollback if smoke tests are still red at 03:40. Customers have been notified. The vendor has booked their on-call. Ops has cleared the weekend. Every line is specific to the quarter-hour.
Every line except the one at the top: the date.
That date was not chosen when the cutover plan was written. It was chosen months earlier, at PI planning or release kickoff, when the team looked at the scope, looked at each other, and voted. The cutover plan simply inherits it, as a constant.
A cutover plan is precise about hours and silent about the day
This is not a flaw in the plan. Cutover plans are supposed to be hour-precise; that is their entire value. Migration sequencing, the rollback point, the communications cadence, who is on the bridge call. None of that can exist without assuming a date.
The question is what that date is made of. When the team took its confidence vote, whether a SAFe fist of five or any equivalent show of hands, that vote was expert engineering judgment: the people who know this codebase best, weighing this scope against their own delivery history. They owned every assumption behind it: which throughput window was representative, whose capacity was really available, what was in scope. It was the best reading anyone could have taken of when the release would be ready.
Then it was written down as a single day, and everything downstream treated it as a fact rather than a forecast. The cutover plan most of all.
A confidence vote is a snapshot. A cutover plan is the most expensive thing you will ever schedule against a snapshot.
What moves the date underneath the plan
Between the vote and cutover weekend, the three things that erode a committed release date all do their work, and none of them appear anywhere in the cutover plan.
- Scope creep. The twelve stories that entered the Fix Version since the vote each looked small. Together they are the reason the last migration script is not written in the week the plan says the migration runs.
- Dependencies surfaced too late. The identity team’s change lands in the same window as yours. Nobody knew until the dress rehearsal, because their queue was never in your plan.
- Capacity changes. The engineer who wrote the migration runbook is now on an incident. The vote priced her time; the cutover plan still has her name on the 02:25 step.
The same inheritance runs one layer out, into the document the cutover sits inside: every field in a deployment plan gets updated except the date.
Each of these moves the real date. The cutover plan keeps the old one. So the first honest reading of the release date tends to happen at the dress rehearsal or the go/no-go meeting, days before the window, when moving it means cancelling the change window, re-notifying customers, rebooking the vendor and apologising to ops. Cutover is where a slip stops being an engineering problem and becomes a public one.
Anchor the cutover to a date that is still being forecast
The alternative is not a vaguer cutover plan. It is a cutover plan anchored to a date that is still being forecast, rather than one that was recorded once.
That is what Release Management, Roadmaps & Product Portfolio for Jira keeps for every release: the committed date, carried with a live 50/85/95% confidence band, re-forecast by Monte Carlo simulation over the team’s own throughput against whatever remains in the Fix Version. The team still owns the assumptions. The app does the arithmetic and keeps it current. Scope added since the baseline shows up as days. Blocking links sequence the work behind its blocker. A change in completion rate widens or narrows the band. The gap between the committed date and today’s 85% date is reported in days, attributed to what moved it.
With that number live, three practical moves follow.
- Book the change window against the 85% date, not the committed date. If the committed date is sitting at 50% confidence, you will rebook the window roughly one release in two. Choosing 85% is choosing how often you are willing to re-notify customers.
- Put cutover work in the Fix Version. Migration scripts, the runbook, the comms drafts, the rollback rehearsal. If they are not Jira issues in the release, the forecast cannot see them, and they are exactly the scope that turns up missing on the night.
- Read the band when you write the plan, and again at dress rehearsal. That is weeks earlier than go/no-go. If the 85% date has drifted past the booked window, renegotiate before you slip: pull a Should below the cut-line, move the window once and deliberately, or accept a lower confidence with everyone’s eyes open.
The app does not write the cutover plan, the runbook, or the hour-by-hour schedule, and it does not integrate with change-management or ITSM tooling. What it supplies is the one input the cutover plan has always taken on faith: whether the day at the top is still the day. Your release management process says what happens next; the forecast says when.
Write the plan to the hour. Anchor it to a live day.
Keep the cutover plan exactly as precise as it is. Just stop scheduling it against a date nobody has re-read since the vote. Try Release Management, Roadmaps & Product Portfolio for Jira on your next release and book the window against a confidence level instead of a hope. For the mechanics, see what the forecast reports at each step of a release process, including cutover, in the docs.
Key takeaways
- A cutover plan is hour-precise about the deployment and silent about the date it depends on; that date is inherited from a confidence vote taken months earlier.
- The vote was expert engineering judgment. The problem is that it was recorded once and never re-read, while scope creep, late dependencies and capacity changes moved the real date underneath the plan.
- Cutover is where a slip becomes public: change windows, customer notices, vendor bookings and ops weekends are all scheduled against that single day.
- Anchor the change window to the live 85% date, put cutover tasks in the Fix Version so the forecast can see them, and re-read the band at dress rehearsal, not at go/no-go.
Frequently asked questions
What should a cutover plan include?
A cutover plan typically covers the change window, the ordered sequence of deployment and migration steps with owners and timings, the go/no-go criteria, the rollback point and procedure, the communications plan for customers and internal teams, and the post-cutover verification steps. What most templates leave out is the confidence behind the date at the top. Add it: record the committed date together with the confidence level it was made at, and the current forecast date alongside it.
When should the cutover plan be written?
Late enough that the deployment steps are known, early enough to rehearse them, usually two to four weeks before the window. That is also the right moment to re-read the release forecast. If the 85% date has already drifted past the intended window, it is far cheaper to move the window then than after customers have been told. Forecasting the release continuously in Jira means that reading is available the day the plan is drafted, not just at the go/no-go.
1 Comment
Leave your reply.