How to cut custom software over to production
Before custom software moves to production, write an ordered cutover runbook that names who does each step, what counts as done, and what sends the service back to the old environment. If the runbook still has no owners and no rollback conditions, do not hand production to users. User acceptance is about who works the checklist. Acceptance criteria are about what counts as done. This runbook is the sequence for the night of the cutover.
On this page
- Keep the runbook separate from the acceptance list
- The AWS template asks what, who, and when
- Microsoft separates cutover from the go/no-go
- Name a person and the step that must finish first
- The signer decides go or no-go at the checkpoint
- Write the rollback trigger before the night
- Check the result, then tell people
- Stay on the old environment until the runbook is complete
Keep the runbook separate from the acceptance list
The runbook is the sequence people follow that night: what stops first, which data moves next, which address must change before users come in, and which check marks the cutover finished. User acceptance asks whether the intended user produced each result on the list. Acceptance criteria name the visible result, the owner, and whether a demonstration or user acceptance shows it. The three documents can point at one another by version. Do not turn the acceptance list into the cutover steps. How the acceptance is operated is in How to run user acceptance testing for custom software. What counts as done is in How to write acceptance criteria for custom software.
If scope still has to change before cutover, open a change request. Do not write a screen that was just finished into the runbook during the cutover meeting. The runbook points at the specification version already approved. How a change is recorded is in How to control scope changes in custom software. Delivery stays with Custom software, websites, and applications. The first line of the runbook carries the specification version and the planned date and time, so a later reader can see which version was signed.
The AWS template asks what, who, and when
Read on 20 October 2026, the AWS Prescriptive Guidance cutover runbook template says a cutover runbook should include all activities performed during the cutover, and that a pre-migration checklist matters just as much. The two can be merged into one document, and both should answer what activities are performed, who performs them, and when they should be performed. The page includes examples of a pre-migration checklist, a cutover runbook, and a rollback plan, and it uses task IDs to speed communication. The page shows no publication date. The tasks in the template are a migration example, not steps every custom-software release must copy.
The cutover table on that page has task ID, task, dependency, team, owner, planned start and end, actual start and end, status, and notes. The example runs from telling stakeholders the application will be down, confirming source backups, and stopping source services, through migration, checking that target infrastructure is up, changing DNS, starting services on the target, technical and business verification, and telling stakeholders the migration is complete. The rollback table starts by stopping application and database services on the target, then shutting down target servers, pointing DNS back to the source, checking DNS, starting the source, synchronising data back if required, starting services on the source, repeating technical and business checks, and telling stakeholders the migration was rolled back. A custom-software runbook keeps owner, planned time, actual time, and status on every step, and rewrites the steps for the environment this release actually changes.
Microsoft separates cutover from the go/no-go
Read on 20 October 2026, Use the go-live checklist on Microsoft Learn groups the list into go-live readiness, cutover, solution scope review, solution acceptance review, user acceptance test completion, performance testing completion, system integration testing completion, data migration readiness and validation, confirmation of external dependencies, change management for initial operations, and operational support readiness. The page shows no publication date. The cutover section lists three tasks: complete all activities in sequence, meet the exit criteria, and get sign-off from stakeholders at the cutover go/no-go checkpoint.
Under go-live readiness, one task is to create a cutover plan that considers all dependencies, the timing of activities, roles and responsibilities, instructions, verification steps, and any other documentation associated with each activity. The same section also asks that scripts and processes planned for the cutover migration be tested and signed off by the business, that external dependencies such as partner systems line up with the go-live timeline and scope, and that production monitoring, maintenance, and the handoff to a support team be prepared. Those are preparations the page lists. They do not require a team to buy Dynamics 365 before it can write a runbook. The runbook names sequence, exit criteria, and the person who signs the go/no-go.
Name a person and the step that must finish first
Each line of the runbook names the step, the step that must finish first, the person who does it (a name, not a whole team), planned start and end, the result someone else can see, and the status. The AWS cutover runbook best practices page says to identify the individuals responsible for the tasks, rather than entire teams, so ownership is explicit. It also says to schedule at least two walkthroughs, invite the task owners, and hold the final walkthrough two or three days before the cutover so last-minute blockers can be raised. That page shows no publication date; it was read on 20 October 2026. Attendance and the conclusion go on the cover of the runbook, not in chat.
Steps that can run together are marked as such. A backup and preparation of the target environment can overlap. Changing the public address waits until writes have stopped. The same best-practices page, to shorten downtime, says to group tasks that can run in parallel, to name the outage window in which the migration must finish, and to align on a rollback plan if the migration exceeds that window. The person responsible for production writes the outage window into the runbook and names who announces a rollback when the window is exceeded. That person is named before the checkpoint, not found on the day.
The signer decides go or no-go at the checkpoint
The go/no-go checkpoint sits before users are sent in, not after the service is already public. At the checkpoint, three things are visible: every step marked as required has an actual finish time, the exit criteria are met, and the signer has signed the runbook. That is what the Microsoft cutover section asks for: sequence, exit criteria, and stakeholder sign-off at the go/no-go checkpoint. The signer is named at the walkthrough. If that person is absent, the deputy already named in the runbook signs. The group chat does not pick a new signer on the spot.
Exit criteria use the acceptance lines that already passed and that this cutover depends on, plus the checks this runbook adds, such as signing in to production, completing one critical transaction, and confirming the old environment has stopped taking writes. A wish that never appeared in acceptance is not added to the exit criteria at the checkpoint. If it must be added, it goes back to a change request and this cutover stays on the original runbook. The checkpoint conclusion is either go or return, with a time and a signature.
Write the rollback trigger before the night
Rollback is not designed after the cutover has already failed. The runbook has its own rollback section: who announces it, which step it starts from, which copy of the data is authoritative, which address is restored, and which check must pass before users are told to stay on the old environment. The AWS application migration process page says to plan for failure, and that if the migration is not successful the rollback procedure already written in the cutover plan should be performed. The best-practices page treats exceeding the outage window as a case for that rollback plan. Both pages were read on 20 October 2026 and show no publication date.
Triggers a custom-software team might pre-select include a failed technical or business check, an outage window that ends before users can be admitted, and writes in production that cannot be reconciled to the old environment. The responsible person ticks the ones that apply before the night. When a ticked trigger occurs, the rollback table is followed in order. The AWS example starts by stopping services on the target. If this release has no target-server step, the rollback table is rewritten for the environment that must actually be restored, and it still keeps an owner, a status, and a notification. When rollback finishes, the last line records the actual time and who was told.
Check the result, then tell people
The end of the cutover table is the check, not the announcement. The AWS template splits post-migration application testing into technical verification and business verification, and only then communicates completion to key stakeholders. Custom software follows that order. The person responsible for production checks that the service is up and that a critical transaction completes. The intended user or the business owner then checks that one real transaction matches the result written in the runbook. Both checks have a time and a signature before the notice "production is live" goes out. The notice names who provides support and from when.
Microsoft's operational support readiness section asks for a monitoring and maintenance plan for production, a transition of operational support from the implementation team to a support team, training and access for that support team, a help desk and ticket process, and a notice to stakeholders and users when the system is ready, with a support contact. The page lists hypercare, an elevated level of support right after go-live, among items the operational support and maintenance plan should include. A custom project writes the start and end of that support, the owner, and the contact on the last page of the runbook, and does not invent a separate time limit. The source environment is retired only after the business check and the health of the application are written in the runbook.
Stay on the old environment until the runbook is complete
If the owner, the rollback conditions, or the go/no-go signer is still unnamed, the cutover date stays on the old environment. Add the names and the rollback table, then move the date. The same holds when the walkthrough has not happened, or when the final walkthrough still has an open blocker. Users are not pointed at the new environment. The blocker is written in the runbook's issue log, with a name and a date to look again.
Length of downtime, defect counts, and support hours stay in the company's own rules, with a date. Neither the AWS template nor the Microsoft checklist assigns those numbers to a custom project. Before the runbook is treated as ready, three things are visible on it: every step has a named person and a predecessor, the go/no-go has a signer, and rollback has a trigger and an order. The cutover date goes into the notice when those three are on the runbook.