Network Cutover Planning for OCI Migrations

The network cutover is the moment a migration becomes real. Data has been copied, the target is built, and now traffic must move from the old estate to Oracle Cloud Infrastructure without dropping users on the floor. Done well it is a quiet, almost anticlimactic event. Done badly it is the part everyone remembers.

This article lays out how to plan a network cutover that is rehearsed, reversible and boring, in the best sense of the word. The work happens in the weeks before the window, not in the panicked hour after something goes wrong.

Connectivity comes first

Before you plan any cutover you need a stable network path between your existing estate and OCI. For most production migrations that means FastConnect, a dedicated private connection that gives predictable latency and bandwidth. For smaller workloads or early testing, a site to site VPN over the internet is acceptable, but it carries variable latency that can complicate parallel running.

Stand up connectivity early and keep it running through the whole transition. You will use it for data sync, for testing, and for any period where workloads on both sides must talk to each other. Treat the link as production infrastructure from the day you provision it, with monitoring and an owner.

The three cutover styles

There is no single right way to cut over. The style you choose depends on how much downtime the business can tolerate and how complex the dependencies are. The table compares the three common approaches.

Most enterprise migrations use a phased approach, cutting over one move group at a time. This aligns with the wave planning described in our guide to planning an OCI migration wave, and it limits the blast radius of any single problem.

DNS is your switch

In almost every cutover, the actual moment of change is a DNS update. You lower the time to live on the relevant records days in advance so caches expire quickly, then at the cutover you repoint the name from the old address to the OCI endpoint. Plan this carefully, because a forgotten high time to live can leave a fraction of users hitting the old system long after you thought the cutover was complete.

Inventory every name that points at the systems you are moving, including internal service names, integration endpoints and any hard coded addresses lurking in application configuration. Hard coded addresses are a classic cause of partial failures, because they ignore DNS entirely.

Routing and firewall rules

On the OCI side, confirm that route tables, security lists and network security groups allow exactly the traffic your applications need and nothing more. Build these from the dependency map produced during assessment, so you are encoding known flows rather than guessing. Test the rules with the actual application before the cutover, not with a generic connectivity check that proves nothing about the real traffic.

On the existing side, make sure the firewall permits the new flows that will cross the hybrid link during parallel running. A surprising number of cutover delays come down to an on premises firewall rule that nobody updated, silently dropping the traffic the new design depends on.

The cutover runbook

Every cutover needs a written runbook, sequenced minute by minute, with a named owner for each step and an explicit expected result. The runbook is not paperwork for its own sake. It is the script you follow at two in the morning when judgement is tired and the temptation to improvise is highest. A good runbook contains the following sections.

First, the pre cutover checklist, confirming that backups are current, data is in sync, and every prerequisite is green. Second, the freeze, where you stop changes on the source so nothing new is written during the switch. Third, the final data sync and verification. Fourth, the switch itself, usually the DNS change and any routing update. Fifth, the smoke tests that confirm the target is serving traffic correctly. Sixth, the decision point where you either confirm success or trigger rollback.

Rollback triggers must be defined in advance

Decide before the window what failure looks like and what you will do about it. Define concrete rollback triggers, for example a smoke test that fails, an error rate above a threshold, or a dependency that does not respond within a set time. Tie each trigger to the rollback procedure described in our guide to rollback strategy for OCI migrations, so the team executes a plan rather than debating one under pressure.

The key discipline is that the decision to roll back is made against the triggers, not against the mood in the room. If a trigger fires, you roll back, full stop. This removes the sunk cost reasoning that keeps teams pushing forward on a cutover that is clearly failing.

Validate before you declare success

Smoke tests during the window confirm the system is alive. They do not confirm it is correct. After the switch, run the fuller validation described in post migration validation on OCI, covering functional correctness, performance and data integrity. Only declare the cutover complete when validation passes, not when the DNS change propagates.

Communication and the war room

A cutover is as much a coordination exercise as a technical one. Set up a single bridge or war room where every participant is present, give it one clear decision maker, and route all status through it rather than letting side conversations form. The person on the bridge who owns the go or no go call should not also be executing steps, because the two roles compete for attention at exactly the wrong moment.

Brief the wider business before the window opens. Support desks should know the cutover is happening so they can interpret any user reports correctly, and stakeholders should know the expected timeline and the criteria for success so nobody panics at the first quiet minute. A short, agreed status cadence, for example an update at each runbook milestone, keeps everyone aligned without flooding the channel.

Plan for the human factors too. Cutovers often run into the small hours, when fatigue erodes judgement. Rotate roles where you can, keep the runbook authoritative so tired people follow the script rather than improvise, and make sure there is a clear escalation path if a decision exceeds the bridge owner's authority.

Rehearse, then rehearse again

The single biggest predictor of a smooth cutover is rehearsal. Run the full runbook against a non production copy, time each step, and find the surprises while they are cheap. Then run it again with the actual team who will be on the bridge during the real window. By the time you cut over production, the procedure should feel familiar rather than novel.

Network cutover planning rewards patience. The teams that treat it as a rehearsed, reversible, well instrumented event are the ones whose go lives are forgettable. For the wider context, see the complete guide to Oracle Cloud migration.