Cutover

A cutover is the moment, or the bounded period, in which live work moves from the old path to the new one: users, notifications, integrations, and, for a transactional system, write authority. Everything before it is preparation and comparison; everything after it is stabilization. Because it changes who relies on what, it is executed from a plan rather than improvised.

A runbook names time, actor, and evidence

A cutover runbook lists each step with its time, the person who performs it, and the evidence that closes it. For a fictional reporting path: confirm no pending changes on the database at 05:30; record the comparison point at 06:00; run both paths; compare keys, amounts by key, links, restricted rows, and delivery time; decide at 06:50; redirect users at 07:00; verify delivery at 08:00. A step that nobody can perform in its allotted time is discovered in rehearsal, which is the rehearsal doing its job.

Go/no-go criteria are agreed before the rehearsal and not adjusted on the day: for example, zero unexplained key or amount differences at the comparison point, approved differences documented, a completed recovery rehearsal, and both trained operators available. A named decision owner applies them, and a stop rule says what happens on a failed step before the switch: keep the old path and retry another day. After the switch, a failure is handled as an incident rather than a no-go: notify users and the decision owner, stop further changes, start the recovery clock at detection, and apply the tested rollback or the controlled repair that the recovery plan names. A missed business deadline is recorded separately from a failed step. AWS describes running a validation-only comparison just before or during a production cutover window as one way to get the mismatch count at that moment.

Phased or single switch

A phased cutover moves bounded groups of work, such as one branch or one report at a time, and must handle dependencies between groups still on different paths. A single coordinated switch avoids mixed states but concentrates risk into one window. Neither is universally safer; choose by how well groups can be isolated, how data changes flow between them, how much interruption is tolerated, and how well the team can observe and recover.

A cutover gate resembles a release gate for a deployment: the candidate must meet stated conditions before it goes live, whatever else looks good. The difference is what is switched: not only a version, but the people and systems that depend on it.

Reference: AWS DMS: Data validation. Examples here are illustrative.