In most cloud migration projects, the bulk of the calendar goes to designing the target architecture and copying data. The bulk of the risk, however, sits in a much shorter interval: the few hours of cutover, when real traffic moves from the old system to the new one. Months of work are judged inside that window. A well-written cutover runbook, rehearsed in advance and equipped with explicit rollback triggers, is what separates a quiet transition from an incident that has to be explained to the board.

Cutover is a designed event, not an all-nighter

The most common mistake is treating cutover as a night shift: gather the best engineers, start at midnight, and handle whatever comes up. This fails because it relies on improvised judgement at exactly the hour when people are least capable of it, and because nobody has agreed in advance on when to stop.

The alternative is to treat cutover as a written procedure. Every step has an owner, an expected duration, and a condition that must be met before proceeding. On the night itself the team executes an approved document rather than inventing. The hard decisions were made weeks earlier, while everyone was rested.

Change freeze criteria

Cutover needs a change freeze on the source system: no new code deployments, no database schema changes, no infrastructure configuration edits, no new third-party integrations. The reason is practical. Any change to the source after the target has been tested invalidates that testing.

A useful freeze policy states:

Start and end times as specific hours, not vague dates.
Scope: which components are frozen and which may still change.
An exception process: who may approve an emergency change during the freeze, and how that change gets mirrored into the target.
Treatment of business data: freezes usually do not cover ordinary user activity, but they may cover batch jobs, scheduled tasks and bulk data-generating processes.

If the organisation genuinely cannot freeze, that is a signal to split the project into several smaller cutovers by service group rather than attempting one big-bang move.

The final delta sync

Most data should be copied ahead of time, over days or weeks, while the old system keeps running. What remains on cutover night is only the delta accumulated since the last copy. The duration of this step largely determines the length of the outage window, so it should be measured rather than guessed.

The straightforward way to measure it is to run one delta cycle against real data a few days before cutover, with a normal working day’s worth of change, and record the actual elapsed time. For databases, distinguish two approaches:

Logical replication or continuous replication: the target tracks the source in near real time. Cutover means stopping writes, waiting for replication lag to reach zero, and switching roles. The window is short but preparation is heavier.
Backup and restore: technically simpler, but the outage equals dump plus transfer plus restore, which grows quickly with data volume.

Integrity verification belongs in the runbook as a mandatory step, not an ad-hoc gesture: row counts per table, reconciliation of key business totals, checksum comparison for object storage.

DNS and TTL must be prepared days ahead

DNS is a frequent reason a technically successful cutover still produces a long perceived outage. Records with long TTLs stay cached in intermediate resolvers and clients after you have repointed them.

Practical rules:

Lower the TTL on the relevant records well before cutover, leaving more time than the previous TTL value. Lowering a 24-hour TTL on the afternoon of cutover accomplishes nothing.
Prepare and syntax-check the new record contents in advance, so the night’s work is paste and save.
Keep the old system reachable in read-only or redirect mode rather than switching it off, so late-arriving traffic does not hit connection errors.
Where a load balancer or reverse proxy can perform the switch instead, prefer it: the change takes effect immediately and rolls back faster.
Restore normal TTL values once the system has stabilised.

Post-cutover validation checklist

Validation should be written in advance as a list of steps with concrete expected results, executable by someone who is not the system architect. It should cover:

Logging in with several account types, including one with restricted permissions.
A real end-to-end business transaction including a write, not just loading the home page.
External integrations: payment gateways, email, SMS, partner APIs. These break most often because they depend on source IP addresses or allow-lists.
Background and scheduled jobs: confirm they run exactly once, and not in parallel on both systems.
TLS certificates, HTTP-to-HTTPS redirects, subdomains.
Logging and monitoring: alerts must reach the right channel and dashboards must receive data from the new environment.
Backups: the first backup in the new environment should run and be restore-tested as early as possible.
Performance: compare response times for a few key operations against the baseline recorded on the old system.

Rollback triggers and the point of no return

The runbook must define in advance which conditions force a rollback, expressed as objective thresholds rather than feelings. Typical trigger shapes: the delta sync has not completed within the allotted time; integrity checks do not reconcile; a payment integration is not functioning; the error rate exceeds an agreed level for an agreed number of minutes after traffic is opened. The specific numbers are set by the organisation according to its own tolerance.

Equally important is the point of no return: the moment the new system has accepted writes from real users, so returning to the old system would mean losing data or performing a complicated reverse sync. That point should be named in the runbook with an expected clock time, and immediately preceded by a formal go/no-go decision made by a named person on the basis of the checklist results.

After the point of no return, the contingency plan is no longer rollback but fix-forward. That requires different resources: staffed on-call, standing access, and an open line to vendors.

Communications plan

On cutover night, information flow matters as much as command execution. Decide in advance:

One channel for the technical team, and one named person responsible for external status updates.
A fixed update schedule tied to clock times, including updates that say nothing has changed. Silence is always read as trouble.
User notification before cutover, stating the expected window and which functions will be unavailable.
Pre-written messages for three outcomes: completed as planned, running long, and rolled back.
Contact details for dependent parties: integration partners, service providers, the customer support team.

Hypercare

Cutover does not end when traffic has moved. Hypercare, typically lasting days to weeks depending on scale, is when problems surface that only appear under real load or on a business cycle: month-end jobs, periodic reports, peak hours.

During this period, keep monitoring at a higher sensitivity than normal, keep the old system readable for an agreed period before decommissioning, and maintain a dedicated incident channel with a short response time. Decommissioning the old environment should be a dated decision in the plan rather than something forgotten until the invoice arrives.

Judging whether a downtime commitment is credible

When working with a provider, a buyer should require the outage window to be estimated in a verifiable way instead of accepting a round number. A credible estimate usually has these characteristics:

It is broken into steps with individual durations: stop writes, final delta sync, integrity check, repoint, validate, open traffic.
It is based on measurements from a rehearsal against real data, with recorded results, not on general experience.
It states its assumptions: data volume, available bandwidth, daily rate of change, and what happens if an assumption proves wrong.
It carries an explicit contingency allowance rather than folding one silently into the headline figure.
It comes with rollback triggers and a decision time, because a window without a stop condition is an expectation, not a commitment.

A framework a buyer can use to sanity-check the number:

outage window = stop writes + final delta sync
              + integrity check + repoint
              + mandatory validation + contingency

If a provider cannot populate each term and explain where the figures came from, the total should not be treated as a commitment. Conversely, a longer estimate that is properly derived is usually far safer for the business than a short one that cannot be explained.

How HiTechCloud can help

HiTechCloud is an AWS partner and a Google Premier Partner, and operates in-country infrastructure. We help assess the current environment, build a cutover runbook with defined freeze criteria and rollback triggers, run delta-sync rehearsals to measure the outage window against real data, and support the hypercare period after the move. If you are planning a migration, get in touch to discuss an approach that fits your operational constraints.