Data platform · Oracle migration
Oracle database migration, with Oracle and the target kept in sync until you switch
An Oracle database migration usually starts with a date: a licence or support renewal, a hardware refresh, or a decision to move workloads to the cloud. Interkey plans the move with iblync, its own migration and replication platform. Oracle keeps serving production while the data is loaded and every change is copied to the target, so the switch happens when your checks pass, not when a transfer window runs out.
Orientation
At a glance
The whole engagement in one table, before the detail.
- Source
- Oracle Database, version and edition confirmed in the assessment
- Targets
- Oracle on cloud infrastructure, PostgreSQL, or another target agreed in scoping
- Keeping both in step
- Change data capture with iblync: initial load, then continuous replication
- Cutover
- Gated steps with agreed pass conditions and a rehearsed rollback
- Where it runs
- Settled per engagement; the bridge and target can run on in-Kingdom infrastructure
- Commercial model
- Quoted per engagement after the assessment; iblync by source, target and data volume
In short
- Why now: most Oracle moves are driven by licence and support cost, an ageing platform, or a move to the cloud.
- Three honest outcomes: move Oracle as it is to cloud infrastructure, move to another engine such as PostgreSQL, or stay and tune.
- How production stays up: CDC keeps Oracle and the target in sync during a parallel run, so the cutover is a short, planned step.
- Where the work sits: in stored code and application queries more than in copying data.
- How it is bought: an assessment first, then a quotation for the engagement.
Why organisations plan an Oracle database migration
Oracle Database is rarely moved because it stopped working. It is moved because something around it changed:
- Licence and support cost. The renewal is due, and the cost of staying is set against the cost of moving, including the engineering effort a move needs.
- A cloud decision. Workloads are moving to AWS or Google Cloud, and the database has to follow the applications that use it.
- An ageing platform. Hardware or an older database version is near the end of its support.
- Consolidation. Two estates must become one, or a new platform replaces several old ones.
Each driver points to a different route, and the cheapest route on paper is not always the cheapest to run. That is why the work starts with an assessment.
Oracle to cloud, Oracle to PostgreSQL, or stay: the three routes
The route decides where the effort goes. The data copy is similar in all three; the code and the licence position are not.
| Route | What changes | Where the effort is | Licence position |
|---|---|---|---|
| Oracle to cloud, same engine | The servers and the operating model; the database engine stays Oracle | Network path, storage sizing, backup and failover on the new platform | Oracle licences still apply; check how your agreement treats cloud use |
| Oracle to PostgreSQL | The engine: schema, stored code, data types and application queries | Rewriting stored code and testing every service that queries the database | Oracle licences end once the old database is retired |
| Stay and tune | Nothing structural; configuration, indexing and capacity | Performance work and a written case for staying | Unchanged |
Some estates take more than one route: systems with the heaviest stored code stay on Oracle for now, while newer services move first.
Oracle to PostgreSQL: what usually needs rework
Moving from Oracle to PostgreSQL is the route that removes the Oracle licence, and it is the route with the most engineering. The differences below come from the PostgreSQL documentation and, for empty strings, Oracle's documentation:
- Packages. PostgreSQL has no packages. Functions are grouped in schemas, and per-session package state is held another way, for example in temporary tables.
- Data types.
varchar2becomesvarcharortext, andnumberbecomesnumericor a more suitable numeric type. Date and time columns need the same review. - Empty strings. Oracle treats a zero-length character value as
null; PostgreSQL does not. Comparisons and constraints that relied on this behave differently. - Error handling. In PL/pgSQL, catching an exception rolls back the changes made since the start of that block, so error-handling code ported line by line can lose work it used to keep.
Our PostgreSQL migration page covers the full list and the four layers of the work.
Keeping Oracle and the target in sync with CDC
A bulk export and import needs the database to stop while it runs, and on a large Oracle estate that takes longer than the window a business will grant. Change data capture (CDC) avoids the long stop: the existing data is loaded once, then every insert, update and delete made on Oracle is copied to the target shortly after it happens, while Oracle stays in service.
Read more
Interkey runs that bridge with iblync, whose published connector list includes Oracle and PostgreSQL. iblync controls its own rate so replication does not compete with production, and if the target is unavailable, changes queue rather than fail. Where both sides must accept writes for a period, it supports bi-directional synchronisation.
Oracle CDC asks things of the team that owns the source database. Agree them first:
- the account the capture process uses, and what it may read;
- how long change logs are kept, and how that fits with archiving and backups;
- when the initial load may run, and how much load it may place on production;
- who tells the replication team when a table or column changes on Oracle.
Our change data capture guide compares the capture methods, and the Oracle CDC page goes into the Oracle side in more depth.
How Interkey runs an Oracle database migration
-
Assessment.
Schemas, stored code, application queries, data volume, change rate, downtime window and data residency. The output is a recommended route with a costed comparison that includes staying on Oracle.
-
Target build.
The target sized and built, in the cloud or on-premises, with backup and monitoring in place.
-
Schema and code.
For an engine change, the schema translated and stored code rewritten, then tested on production-shaped data.
-
Initial load and replication.
History loaded once, throttled, then continuous replication from Oracle.
-
Parallel run.
Both databases live and in step; counts and checksums compared, reads moved first.
-
Rehearsed cutover.
Writes paused or queued in an agreed window while the last changes drain, validation gates passed, then writes switch.
-
Stabilise and hand over.
Oracle kept warm through a business peak, then retired. Handover to your DBAs, or operation by Interkey with support from Riyadh.
Oracle cloud migration in Saudi Arabia: licences and data residency
An Oracle to cloud migration raises two questions that a move between data centres does not.
Licences. Keeping the Oracle engine on cloud infrastructure keeps the Oracle licence. How your existing licences count in a given cloud is set by your agreement with Oracle, so read it with your Oracle account team before the route is chosen.
Read more
Data residency. Many Saudi organisations must keep certain data inside the Kingdom, under the National Cybersecurity Authority's controls (nca.gov.sa) and the Personal Data Protection Law overseen by SDAIA (sdaia.gov.sa). Google Cloud runs a region in Dammam (me-central2), and the replication bridge, the target database and the tooling can run on in-Kingdom infrastructure. Our data residency guide sets out the questions to settle. Interkey is a Google Cloud partner and an AWS partner, and the target platform is chosen in the assessment, not before it.
When an Oracle migration is the wrong move
The assessment can conclude that you should not migrate, and it says so in writing. A database that serves its load at a cost the business accepts is an asset. If most of the logic lives in PL/SQL that only a few people understand, the rewrite can cost more than several renewals. And if you only change where the Oracle engine runs, Oracle's own native tools for moving between Oracle databases are the first thing to evaluate, and iblync may not be needed.
What drives the cost and the timeline
We do not publish a price or a duration for an Oracle migration, because both are decided by the estate. The drivers are:
- how much stored code the database holds, and how far it is from the target;
- the number of applications and services whose queries change;
- data volume, and how much of it changes while the migration runs;
- the downtime window the business will actually grant;
- the target platform and where it must run;
- who carries the application changes, and who operates the database afterwards.
The assessment turns these into a schedule and a quotation. Our migration decision checklist lists the same questions in order.
Relatedmigration decision checklist
Questions buyers ask
Can we keep Oracle running while the new database is built?
Yes. Oracle stays in service throughout: the data is loaded once, then change data capture copies every change to the target during the parallel run. The final switch is a short, planned step whose window is agreed in the assessment.
Will moving off Oracle reduce our licence cost?
Moving to an engine such as PostgreSQL ends the Oracle licence once the old database is retired. Moving Oracle to cloud infrastructure keeps it. The assessment sets the saving against the engineering effort and the running cost of the target.
Can an Oracle migration keep our data inside Saudi Arabia?
Yes. The replication bridge, the target database and the tooling can run on in-Kingdom infrastructure, including Google Cloud's Dammam region. Which data must stay in the Kingdom, and under which obligations, is settled with you in the assessment.
How long does an Oracle to PostgreSQL migration take?
It depends on the stored code, the number of services whose queries change, the data volume and change rate, and the downtime window. The assessment reads the code and queries first, then gives a schedule.
Which Oracle versions does iblync connect to?
iblync's published connector list includes Oracle. Your exact Oracle version and edition, and the target, are confirmed in the assessment. Where a system is not yet covered, a custom connector is built.
Who supports the database after an Oracle migration in KSA?
Your DBAs after a documented handover, or Interkey under a written managed-services scope, with support from Riyadh in Arabic and English.
Next
Related pages
Next step
Scope an Oracle migration
Tell us the Oracle version and edition, the rough data volume, how much PL/SQL it holds, the target you have in mind and the downtime window the business will grant.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia