Skip to main content
Aurikle
AI and systemsAurikle

How to write a rollback plan for custom software go-live

A rollback plan for custom software go-live names the condition that may start a return, who may decide, whether this return restores data or turns a feature off, and who is told after the decision. The cutover runbook is the order of steps that night. This page is how the return decision itself is written.

On this page
  1. Write the rollback plan apart from the cutover runbook
  2. Write each trigger as something another person can see
  3. Name the person who decides apart from the person who acts
  4. Choose data restore or the feature switch before the night
  5. Turning a switch off does not clear rows already written
  6. Name who is told, and on which channel
  7. Rehearse with the same people and the same triggers
  8. Do not attach an unfinished decision page to the cutover notice
Matching serviceCustom software, websites, and applicationsRead this note

Write the rollback plan apart from the cutover runbook

The cutover runbook answers which service stops first that night, who signs that production may open, and which step a return starts from. The rollback plan answers which condition may start a return, who is allowed to make that decision, whether this return restores data or turns a feature off, and who receives which message after the decision. The two documents can point at each other's versions. The night's task list is not rewritten as the decision page, and the decision page is not split into every task row. The night's sequence is in How to cut custom software over to production.

Change control asks whether the specification changes. Data migration asks about the field map, the rehearsal, and which extract is authoritative. Handover asks who holds the system after production opens. None of the three replaces the triggers and the decision-maker on this page. See How to control scope changes in custom software, How to migrate data into custom software, and How to prepare a custom software project handover. Delivery stays with Custom software, websites, and applications.

Write each trigger as something another person can see

Read on 23 October 2026, the cutover strategy on Microsoft Learn says a cutover plan includes the order and timing of each task, the owner and a backup, the instructions and the tools, verification and sign-off, and a rollback plan if something goes wrong. The page shows no publication date. It is written for Dynamics 365 projects. It does not require a custom project to buy that product. It does not list the triggers a custom project must use, and it does not say a return must restore a particular backup.

The triggers are therefore written for this go-live. Each one is a condition another person can see, and it points at a check that already exists. Examples are a technical or business check that did not pass, a window on the runbook that has ended while users still cannot be let in, and data written in production that cannot be traced to the source. "Feels unstable" and "someone objects" are not triggers. Each trigger is matched to one response in the plan: restore data, turn a feature off, or both, with which comes first. A condition matched to no response does not go on the list of conditions that may start a return.

Name the person who decides apart from the person who acts

The same page says to decide who makes the final judgment on whether the solution may enter production, and it calls that judgment go/no-go. That is the gate for opening production. The name and the criteria sit on the cutover runbook. The rollback plan has a separate line: after which condition, who may declare a return. The two lines may name the same person. The lines stay separate. If the person who would declare it is absent that day, the deputy already named on the plan declares it. The name is not changed in a group chat on the day.

Each trigger also names who carries it out: who restores the data, who turns the switch off, and who checks that the work finished. The person who carries it out is not the person who decides, unless the plan says one person holds both and the two columns remain. The page requires an owner and a backup for cutover tasks. The rollback plan follows that, and it does not write "the engineering group" as the decision-maker. Once the decision is written, the people who carry it out follow the matching order. They do not change the order on the spot. If the order lives in the cutover runbook, this page points at that version. The steps are not copied a second time.

Choose data restore or the feature switch before the night

When data has already been written in production and cannot be traced to the source, the plan chooses a data restore. Which extract is authoritative, whether the rows this load wrote are removed first, and which counts are checked after the removal, live in the data-migration plan. This page only points at that version. See How to migrate data into custom software. A trigger with no extract version cannot be marked "restore data".

When the new behaviour can be turned off and the previous behaviour is still in the same release, the plan may choose a feature switch. A trigger that needs both says whether the switch comes first or the restore comes first, and which check shows that the return is finished. The word "rollback" alone, with no choice, leaves the people who carry it out to assume different things on the day. The choice sits on the same row as the trigger. Changing the choice is a new version of the plan first.

Turning a switch off does not clear rows already written

Read on 23 October 2026, Use Azure App Configuration to manage feature flags on Microsoft Learn says feature flags let a team control functionality without redeploying code. The page describes Switch as a simple on/off control, for short-lived operational toggles and for cases where a single on/off control is enough, and it says Switch is used to enable or disable functionality immediately for all users. The page shows no publication date. It is written for Azure App Configuration. It does not require a custom project to buy that product, and it does not say that turning a flag off restores a database to a previous copy.

If the plan chooses a switch, it names the switch that actually exists in this system, who may turn it off, and which previous behaviour users then see. A separate sentence says where rows already written remain: the switch governs behaviour, and it does not delete rows. Deleting rows or reloading them goes back to the data-restore choice, and points at the extract version in the migration plan. A system with no such switch does not have an invented name written on the plan. The page also describes a gradual percentage rollout and experiments. Those are not the default response in a return decision. This page does not copy a percentage into a return condition.

Name who is told, and on which channel

The cutover-strategy page puts communication in the cutover strategy: who the stakeholders are, when and how they receive or send messages, and whom they contact with a question. It also says to decide which kind of message fits which situation. The examples are starting the cutover, finishing a task, finding a problem, and going live. Those examples do not include a separate "a return has been decided". The return message is therefore a line this plan adds, and the plan says it was added here, not taken from those four.

The line names, after the decision-maker declares the return, who receives it, which channel already in use carries it, which trigger number the message includes, which environment users stay on, and who takes support. A channel that exists only for that night is not created. If the channel cannot send that day, the plan names a backup channel and a backup person. The time the message went out is written back on the decision page. Without this line, the return can finish while users and support are still looking at the new environment.

Rehearse with the same people and the same triggers

The page calls the practice beforehand a mock cutover or a dress rehearsal, and it says to use the same data, tools, and people, and to do it more than once, until the team is confident. The walkthrough of the cutover runbook stays with the cutover note. This rehearsal walks only the decision page: read a trigger aloud, the decision-maker says whether the choice is restore or switch, the person who would carry it out points at the runbook version that holds the order, and the person who would notify points at the channel and the recipients.

If the rehearsal cannot name the switch, cannot point at an extract version, or leaves the recipients blank, that trigger comes off the list of conditions that may start a return. The plan is versioned, and that trigger is rehearsed again. A recipient is not added aloud in the rehearsal meeting. The rehearsal record has the date, the decision-maker who was present, the trigger numbers that were walked, and the numbers that were taken off. The page does not say how many rehearsals to run. It describes the cutover window as usually less than 48 hours. That is the page's wording for a Dynamics 365 cutover. This plan does not copy it as a time limit. The length of the window is the one the company has agreed, dated.

Do not attach an unfinished decision page to the cutover notice

If the triggers, the decision-maker, the choice of restore or switch, or the recipients are still unwritten, this rollback plan is not attached to the cutover notice. The missing item is written on the cover. A condition that no one has signed in the business check is not added to the triggers on the day. Adding it is a new version of the plan, and that trigger is rehearsed.

A length of downtime, a defect count, and the price of a switch product stay in the company's own rules and on the quote for this job, with a date. The pages above do not assign those numbers to a custom project, and they do not rank products. Before the plan is handed on, three things are visible: each trigger is a condition someone can see and is matched to restore or switch, the decision-maker and the deputy are named, and the notice names recipients and a channel. The version of the rollback plan is written into the cutover runbook when those three are on the decision page.

Related notes