Moving Off Oracle or SQL Server Without a Rewrite

You can move off Oracle or SQL Server without rewriting your application: decouple the database migration from the application rewrite, run the legacy and target databases in parallel using replication, and cut traffic over service by service once the new platform is validated under production load. That's the short answer. The longer answer — which patterns to use, how to sequence the work, and how it fits alongside broader application modernisation — is what the rest of this guide covers.

Application modernisation often stalls at the database layer. Teams are comfortable refactoring services, containerising deployments, and rebuilding front ends, but the Oracle or SQL Server instance underneath the application feels immovable — too central, too risky, too expensive to touch. Treating the database migration as a standalone, high-stakes project is usually what causes that stall. Sequencing it alongside application modernisation, rather than separately from it, is what unblocks it.

What does application modernisation mean for a legacy database?

In this context, application modernisation is the practice of incrementally replacing outdated infrastructure and code with maintainable, cost-effective alternatives while the system keeps running in production. For databases specifically, it means moving off commercial licensed platforms like Oracle or SQL Server towards open-source engines (PostgreSQL, MySQL) or cloud-native managed services, without stopping feature delivery for months at a time.

The goal is not simply cost reduction, though licensing costs are usually a genuine driver. It's also about reducing operational risk tied to vendor-specific tooling, easing hiring (open-source database skills are more widely available than niche commercial DBA expertise), and unlocking cloud-native capabilities like managed backups, read replicas, and elastic scaling that legacy licensing models weren't designed for.

Why avoid a full rewrite when migrating off Oracle or SQL Server?

A full rewrite means replacing the application and database together in one release. It's rarely the right choice for a system that's actively generating revenue, because it concentrates months of risk into a single cutover event and freezes feature work for the business in the meantime.

The alternative is to decouple the database migration from the application rewrite entirely. Applications can often be modernised incrementally — service by service, using patterns like the strangler fig approach — while the underlying data platform migrates on its own, parallel track. Our earlier piece on the strangler fig pattern for legacy systems covers this in more depth for application layers; the same incremental philosophy applies to data.

What migration patterns work for legacy database migration?

There is no single correct pattern — the right approach depends on how tightly the application is coupled to vendor-specific SQL dialects, stored procedures, and transaction semantics. Most successful migrations combine two or three of the patterns below rather than relying on one.

Pattern	How it works	Best suited to
Dual-write / shadow write	Application writes to both old and new database during a transition window	Systems with well-understood write paths and moderate schema complexity
Change data capture (CDC) replication	Changes stream from the source database to the target in near real time, keeping both in sync	High-availability systems where downtime for cutover must be minimal
Strangler fig at the data layer	New services read/write from the new database; legacy services continue against the old one until retired	Systems being decomposed from a monolith anyway
Big-bang cutover	Entire migration happens in a single planned outage window	Small, low-traffic systems with simple schemas — rarely appropriate for core production databases

CDC-based replication tools are commonly used to keep a legacy Oracle or SQL Server instance and a target PostgreSQL (or cloud-native) instance in sync during the transition, which is what allows teams to validate the new platform under real production load before switching over.

How do you sequence database migration alongside application modernisation?

Sequencing matters more than tooling. The safest order is usually: stabilise and instrument the legacy system first, decouple application logic from database-specific features second, then migrate data with replication running in parallel, and only cut over once the new platform has been validated under production-equivalent load.

A practical sequence looks like this:

1. Audit vendor-specific dependencies. Stored procedures, proprietary functions, and Oracle- or SQL Server-specific SQL extensions need to be identified and either rewritten in application code or reimplemented in the target platform.
2. Decouple the application from direct schema assumptions. Introducing a data access layer or repository pattern makes it possible to swap the underlying database without touching every calling service — this is often done as part of broader application modernisation work rather than as a database-only exercise.
3. Stand up the target platform and begin replication. Run the new database alongside the old one, validating data integrity and query performance before any production traffic moves.
4. Migrate read traffic first, then write traffic, service by service, rather than switching the entire application at once.
5. Decommission the legacy platform only once every consuming service has been confirmed off it — including reporting, batch jobs, and any integrations that write directly to the database outside the main application.

Why does this matter beyond cost savings?

A modernised data platform is also the foundation that later AI work depends on. Teams that plan to introduce machine learning features, retrieval-augmented generation, or AI-powered platform capabilities down the track typically find that a clean, well-instrumented database is a prerequisite, not an afterthought. If AI is on your roadmap, it's worth factoring that into how you design the target schema and access layer now, rather than migrating the database once and then reworking it again for ai engineering later. Equally, if the business case for modernisation is unclear, it's worth working through ai product strategy questions in parallel — what the data platform needs to support, not just what it needs to replace.

This is also where a lot of migrations run into trouble: teams treat the database swap as purely a technical exercise and miss the organisational dependencies — reporting tools, batch jobs, third-party integrations, and analysts running ad hoc queries directly against production tables. Auditing these dependencies thoroughly before migration starts is what prevents surprises during cutover.

Getting the sequencing right

Migrating off Oracle or SQL Server is achievable without a disruptive rewrite, but it requires discipline: audit dependencies honestly, decouple the application from the database incrementally, run both platforms in parallel long enough to trust the new one, and cut over gradually rather than all at once. None of the patterns above are exotic — CDC replication and the strangler fig approach are well-established — but they require careful sequencing and realistic timelines rather than a single heroic cutover weekend.

For more on related patterns, see more insights from our team on application modernisation and AI adoption.

If you're weighing up a legacy database migration and want a second opinion on sequencing, dependencies, or which pattern fits your system, get in touch — we're happy to talk through what we've seen work.