What it takes to move off Oracle, SQL Server 2008 or DB2 — the two migration types, where projects overrun, and what the work actually costs.
Disclosure. legacymodernizationhub.com is operated by Chudovo OÜ. Cost and timeline figures in this guide are the ranges Chudovo publishes from its own delivered projects, based on Eastern European engineering rates. They are one vendor’s reference points, not industry averages. Frameworks and technical guidance cited inline come from AWS and Microsoft.
The distinction that decides everything
Most guides describe database modernization with the vocabulary of application migration — rehost, replatform, refactor. That taxonomy is borrowed and it obscures the one question that actually determines cost, duration and risk:
Are you staying on the same database engine, or changing it?
- Homogeneous migration — Oracle 11g to Oracle 19c, SQL Server 2008 to Azure SQL Database, self-managed PostgreSQL to Amazon RDS. The SQL dialect, data types and procedural language stay the same.
- Heterogeneous migration — Oracle to PostgreSQL, SQL Server to MySQL, DB2 to anything. The engine changes, and with it the dialect, the type system and every line of procedural code.
The difference is not incremental. A homogeneous move of a mid-sized database is a scheduling and validation exercise. A heterogeneous move of the same database is a code conversion project with a data migration attached. AWS documents the split in its guidance on heterogeneous database migration; Microsoft’s SQL Server migration guidance covers the homogeneous path to Azure.
Everything below is organized around that split.
What you are likely migrating from
Legacy database estates in practice are some combination of:
| Engine | Typical legacy versions still in production |
|---|---|
| Oracle Database | 8i through 19c |
| Microsoft SQL Server | 2000 through 2019 |
| IBM DB2 | mainframe and LUW |
| MySQL | 4.x–5.x |
| PostgreSQL | pre-10 releases |
| Teradata | on-premise data warehouses |
| SAP HANA | on-premise |
| Microsoft Access | departmental systems that became critical |
The Access row is not a joke. Departmental Access databases that quietly became business-critical are among the most common modernization triggers, and among the most under-scoped — the data is small, the undocumented business logic is not.
The real cost driver: stored procedures
A database migration is usually scoped by data volume. Data volume is rarely what makes it expensive.
What makes it expensive is procedural code: stored procedures, triggers, functions, packages. In a long-lived system, a significant share of the business logic lives there rather than in the application, and it was written in a dialect that does not port.
- Oracle PL/SQL to PostgreSQL PL/pgSQL: similar in shape, different in detail — cursors, exception handling, package structure and autonomous transactions all need rework
- T-SQL to PL/pgSQL: different enough that conversion is rewriting, not translating
- Anything to a document store: the procedural layer has no equivalent at all and must move into the application
A practical test before scoping: count the stored procedures and total lines of procedural code in the source database. A schema with 40 tables and no procedures is a different project from a schema with 40 tables and 300 procedures, even though the data volume is identical. Most overruns trace to this number being unknown at proposal time.
Where you are likely migrating to
Open-source engines: PostgreSQL, MySQL, MariaDB — the usual heterogeneous targets, chosen to exit licence costs.
Managed cloud services: Amazon RDS, Amazon Aurora, Azure SQL Database, Azure Database for PostgreSQL, Google Cloud SQL, Cloud Spanner — the usual homogeneous targets, chosen to exit operational burden.
Analytical platforms: Amazon Redshift, Google BigQuery, Azure Synapse Analytics — the destination when the legacy system was a warehouse (Teradata, older SQL Server estates).
Non-relational: MongoDB, DynamoDB, Cosmos DB, Cassandra, Redis, Elasticsearch — correct when the access pattern genuinely does not fit relational, wrong when chosen because the relational schema was poorly designed. Migrating a bad schema to a document store preserves the bad schema and removes the constraints that were catching errors.
The five approaches, ordered by what they cost
1. Version upgrade in place
Same engine, newer version, same infrastructure. The cheapest path and often sufficient when the driver is support lifecycle rather than capability.
Watch for: deprecated features between major versions, and the fact that an unsupported version is usually unsupported for a reason that also affects the upgrade path.
2. Lift to a managed service
Same engine, moved to RDS / Azure SQL / Cloud SQL. The schema and procedural code survive intact; what changes is who runs backups, patching and failover.
Watch for: managed services restrict some administrative operations. Legacy systems that rely on server-level access, linked servers, or filesystem operations from inside the database need those paths redesigned.
3. Schema refactoring
Keep the engine, fix the design: normalize what should be normalized, add the indexes the query plans have been asking for, retire the columns nobody has written to since 2014.
Watch for: every schema change is an application change. This path is only cheap if the application code is accessible and tested.
4. Heterogeneous engine migration
Oracle to PostgreSQL being the canonical case. Schema conversion, data type mapping, procedural code rewriting, application data-access layer changes, and a validation programme.
This is where the project costs sit, and where the stored-procedure count determines the number.
5. Replacement
Retire the database with the application it belongs to. Correct when the system is being replaced anyway; the data migration remains and is usually the harder half.
Zero-downtime cutover: how it actually works
“No downtime” is achievable for most systems, and the mechanism is worth understanding because it determines the schedule.
- Initial bulk load. Copy the data as of a point in time. This can take hours or days and happens while the source stays live.
- Change data capture. Replicate ongoing changes from source to target continuously, so the target converges on the source.
- Validation while both run. Row counts, checksums, business-rule reconciliation — against a moving target, which is why this step needs automation rather than spot checks.
- Cutover. Stop writes to the source for the length of the final replication lag, redirect the application, resume. Measured in minutes rather than hours.
- Rollback path kept warm. Reverse replication for a defined period, so a decision made under pressure is reversible.
The constraint is almost always step 3. Teams budget for the copy and not for proving the copy is correct.
Cost and timeline
Published ranges from Chudovo, which delivers database migration projects across Oracle, SQL Server, DB2 and PostgreSQL:
| Scope | Duration | Cost |
|---|---|---|
| Small database, simple schema | 1–3 weeks | $5,000–$20,000 |
| Mid-size, with stored procedures and application dependencies | 1–3 months | $20,000–$80,000 |
| Large warehouse or regulated data requiring validation | 3–6+ months | $80,000+ |
Note what defines the tiers. It is not gigabytes — it is stored procedures, application dependencies and regulatory validation. That is the correct way to scope this work, and a proposal that prices by data volume alone has not been assessed.
Few vendors publish figures at all, so treat these as one reference point. Their practical use is sanity-checking: a quote of $12,000 for an Oracle-to-PostgreSQL migration with 200 stored procedures describes a different scope than the one you asked for.
Planning sequence
1. Dependency mapping, before anything else. Which applications, reports, ETL jobs, integrations and scheduled tasks read this database? The list is always longer than the one the team produces from memory. A forgotten nightly report that breaks three weeks after cutover is the characteristic failure of this phase.
2. Procedural code inventory. Count and classify. This produces the estimate.
3. Data classification. What is regulated, what is retained for compliance, what can be archived rather than migrated. Archiving before migrating is frequently the cheapest single decision in the project.
4. Target selection. Driven by the access pattern and the team’s operating capability, not by the platform the architect read about most recently.
5. Pilot on a real subset. Not a sample schema — a genuine slice with real procedures and real data shapes.
6. Validation programme. Defined before migration, automated, run continuously. Row counts are the floor, not the test.
Where database modernizations go wrong
Scoped by data volume. The expensive part is procedural code and validation. See above.
Validation treated as a final checkbox. Discovering a type-conversion error three weeks after cutover, in data that has since been written to, is how a migration becomes a data recovery project.
The reporting layer was forgotten. Dashboards, BI extracts and regulatory reports read the database directly far more often than anyone documents. They break silently.
Character encoding and collation. Legacy databases carry accumulated encoding decisions. A collation mismatch surfaces as sorting that is subtly wrong, which is worse than an error, because nobody notices for months.
Timezone and date handling. Dates stored without timezone in a system that spanned regions is a class of bug that only appears after cutover and is painful to unwind.
NULL and empty-string semantics. Oracle treats an empty string as NULL; most other engines do not. In a heterogeneous migration this changes query results silently, across the whole application.
FAQ
How long does a legacy database migration take? One to three weeks for a small database with a simple schema; one to three months for a mid-size database with stored procedures and application dependencies; three to six months or more for large warehouses or data requiring regulatory validation.
What does it cost? Published ranges run $5,000–$20,000 for small databases, $20,000–$80,000 for mid-size, and $80,000+ for large. The tier is set by procedural code and validation requirements rather than data volume.
Can we migrate without downtime? For most systems, yes — via bulk load plus change data capture, with a cutover window measured in minutes. The practical constraint is validating a moving dataset, not the copy itself.
Oracle to PostgreSQL: how hard is it really? The data moves straightforwardly. The difficulty is PL/SQL to PL/pgSQL conversion, Oracle-specific behaviours such as empty-string-as-NULL, and the application’s data access layer. Count your stored procedures before accepting any estimate.
Should we move to NoSQL? Only if the access pattern genuinely does not fit relational. A poorly designed relational schema migrated to a document store is still poorly designed, with fewer safeguards.
What is the single most underestimated part? Data validation, followed by the reporting and integration layer nobody inventoried.
Sources and further reading
- AWS Prescriptive Guidance — Migrate the data (database migration strategy)
- AWS Prescriptive Guidance — Heterogeneous database migration
- AWS Prescriptive Guidance — SQL Server migration strategies
- Microsoft — SQL Server data migration overview
- Refactoring Databases: Evolutionary Database Design — Ambler & Sadalage
- Cost and timeline figures: Chudovo — database migration