Oracle migration with minimal downtime: why you start from the cutover

A critical Oracle database can be migrated with only a few minutes of downtime if the heavy work is done first, while the system is still running. You prepare the new database, keep it in step through continuous replication and fix the cutover in advance. The cutover is the moment when applications stop writing to the old system and move to the new one. It has to be designed first, because its length determines the technique, the tools, the licences and the timetable. No one can promise that there will be no downtime at all. Downtime is reduced and planned.

A typical scenario. A company that sells online in several countries has to move its order database to a new platform. The first plan allows for six hours of downtime on a Saturday night, with a full export and a fresh load. But customers place orders at all hours, from different time zones, and no one can say whether six hours will be enough. The problem is not working faster. It is changing the order in which things are done.

What is the cutover, and why is it designed first?

The cutover is the final step of a migration. Writes to the source system stop. You check that the target has all the data, connect the applications to the new database and reopen the service. It is the visible part, and the only one in which people using the ERP system or the website notice anything.

So the first question is not “which tool shall we use?” but “how much downtime can the business bear, and when?”. The answer comes from the people who use the system, not just from IT. That means sales, logistics and finance. If acceptable downtime is a few hours at night, a traditional copy may be enough. If it is a few minutes, you need continuous replication, with everything that entails.

Two parameters help to put the decision in writing.

• RTO (Recovery Time Objective) is the maximum time the service can stay down.
• RPO (Recovery Point Objective) is how much data, measured in time, can be lost if something goes wrong during the switchover.

Which techniques reduce downtime, and with which licences?

There are five main techniques. They differ in how long the downtime lasts, in their technical constraints and in licence costs.

The choice depends on the edition, the source and target versions, the platform and the volumes. For example, Data Guard is not available with Standard Edition 2, so the options for reducing downtime change. Logical replication, on the other hand, lets you change version and operating system in a single move. But it needs more preparation and a licence that has to be budgeted for.

If the migration coincides with a version upgrade, what we wrote about Oracle versions and support deadlines also applies. You start from the certification of your ERP system.

What needs checking before you start?

Before anyone touches a configuration, you need a technical snapshot, taken methodically. These are the items that most often push a migration off schedule.

• Hidden dependencies. Scheduled jobs, links between databases, applications that write directly to tables, and integrations with suppliers and customers.
• Workloads. Write peaks, overnight batch jobs and month-end closes that must not overlap with the synchronisation.
• Compatibility. The target version must be certified for the ERP system. Some features change from one version to the next, or between an on-premises server and a cloud service.
• Licences. In the cloud, the way licences are counted changes. Options and tools used during the migration must be covered.
• Performance. The most important queries must be measured before and after, on the target, with real data.
• Network and security. Check the bandwidth available for replication and the encryption of data in transit. Migration accounts should be dedicated, and closed at the end.

Skipping this phase saves a few days at the start and often loses more at the end, when problems surface after the switchover is done.

How do you rehearse the switchover before the day itself?

A cutover goes better if it has already been rehearsed. The dress rehearsal is done on a copy, stopwatch in hand, and it produces three documents.

1. The cutover runbook. It lists every step, who performs it, in what order and how long it takes.
2. The validation checks. These are row counts on the main tables, application checks by key users and the timings of critical queries.
3. The decision criteria. They state what must be true to go ahead, and what triggers a rollback. They are written beforehand, not during the cutover.

On the day, the runbook is followed exactly as it was rehearsed. The decision to go ahead lies with a person named in advance, who has the checks and criteria in front of them rather than a gut feeling.

Why is the fallback part of the plan?

A migration plan with no way back is a gamble. The source system stays intact and available for an agreed period after the cutover. Where the technique allows, it also stays in step. With Data Guard, the old database can become the standby for the new one. With logical replication, you can switch on replication in the reverse direction.

So if a problem appears in the first hours or days, you can go back to the source system without losing the data written in the meantime. The old environment is decommissioned only once the new one has proved itself on performance, data consistency, the response times of critical functions and the first period-end closes.

When is the in-house team enough, and when do you need outside help?

An in-house team can handle the migration if it has already used the chosen techniques in production. It also needs to be able to dedicate an experienced person to the project for as long as it takes, without leaving day-to-day operations uncovered. When that experience is missing, the most insidious risk is not a switchover that fails visibly. It is the silent problem, such as data that turns out to be out of step weeks later, queries that slow down for no apparent reason, or backups that were never tested on the new environment.

The most effective formula is often a mix. The in-house team brings knowledge of the applications. An outside team brings experience of migration techniques and rehearsals.

In brief

• Downtime in an Oracle migration is reduced and planned. No one should promise a migration with no downtime at all.
• Start from the cutover. The people who use the system decide how much downtime is acceptable, and when.
• Data Guard is included in Enterprise Edition. GoldenGate has its own licence. ZDM automates the workflows towards the targets that Oracle lists.
• Dependencies, compatibility, licences and performance are checked before you begin.
• The switchover is rehearsed on a copy, with a written runbook, checks and criteria.
• The source system stays available, and in step where possible, until the new one has proved it can cope.

Frequently asked questions

Can an Oracle migration happen with no downtime at all?

Not usually. With continuous replication, downtime shrinks to the cutover, which can last a few minutes. But there is still a moment when writes stop and applications change destination. How long it lasts depends on the edition, the platform, the volumes and the applications, and it is measured in the dress rehearsal.

Is GoldenGate included in the database licence?

No. Oracle GoldenGate is a separately licensed product. For some migrations to Oracle’s cloud, the ZDM documentation describes a specific way of using it. Check the terms before you budget for the migration.

Does Data Guard work with Standard Edition 2?

No. According to Oracle’s licensing information, a Data Guard standby database is included in Enterprise Edition and is not available in Standard Edition 2. Users of Standard Edition 2 have to choose other techniques to reduce downtime.

How long does it take to prepare a migration?

It depends on the number of databases, the applications connected to them and the technique chosen. The initial technical snapshot also serves this purpose. It tells you how many rehearsals are needed and when the cutover can be scheduled with reasonable confidence.

Migrations and upgrades with planned downtime are a central part of the work of our Oracle & Database Engineering division. That covers the technical assessment, the choice of technique and licences, the dress rehearsal, the switchover in the agreed window and a planned fallback.

Sources

Consulted on 16 September 2026.

• Oracle, ZDM documentation, introduction and migration methods
• Oracle, Database Licensing Information User Manual 19c, features by edition and GoldenGate licensing
• Oracle, Data Guard Concepts and Administration 19c