Database modernization
Database modernization from Oracle and DB2 to PostgreSQL or the cloud
We inventory schemas, stored procedures and dependent jobs, convert and validate the data, and cut over in stages with a way back. Not every database should move.
- Inventory of objects and dependents first
- Row-level validation before cutover
- Retain, replatform or retire, by database
What does database modernization involve?
Database modernization means changing where a database runs, which engine it uses, or how it is structured, without breaking the applications that depend on it. The common cases are moving Oracle or DB2 to PostgreSQL, moving to a managed cloud database, and breaking up a large shared database that many systems write to.
The data is rarely the hard part. The hard part is everything around it: stored procedures, triggers, scheduled jobs, vendor-specific SQL, character encodings, reports that read directly from tables, and batch programs that nobody has opened in years. A move that ignores these will pass its data checks and still fail in production.
We start by listing every object and every consumer, then decide for each database whether to retain it, replatform it, convert it or retire it. This often happens inside a wider cloud migration or mainframe modernization program.
How a database migration is run
Each step produces something you can review. Nothing is switched until the one before it has been checked.
-
Inventory and dependency map
We catalog tables, views, procedures, triggers, jobs, database links and every application, report and batch process that touches the data.
-
Choose the target and the path
We compare a managed service on the same engine, PostgreSQL, or splitting data by domain, and write down the tradeoffs for your case.
-
Convert schema and code
Tools handle the routine mapping. Engineers rewrite what tools cannot, such as procedural code that depends on engine-specific behavior.
-
Load, synchronize and validate
An initial load is followed by change data capture so the target stays current. We compare row counts, checksums and sampled business results between the two.
-
Cut over with a way back
Applications move in stages. Reverse replication or a tested restore plan keeps the old database usable until the new one has proven stable.
Typical problems we plan for
These are the issues that cause most of the schedule surprises in database moves.
-
Procedural code
Large bodies of PL/SQL or SQL PL need careful rewriting and testing. Behavior around nulls, dates, rounding and transactions often differs between engines.
-
Encoding and data types
Mainframe DB2 data may use EBCDIC and packed decimals. Converting to UTF-8 and exact numeric types needs a field-by-field check.
-
Hidden consumers
Spreadsheets, reporting tools and old batch jobs query tables directly. If they are not found early, they break on cutover day.
Convert the engine or keep it?
| Move to PostgreSQL | Keep engine, move host | |
|---|---|---|
| Code change | Schema and procedures rewritten | Little to none |
| Licensing | Open source engine | Same vendor terms remain |
| Effort and risk | Higher, driven by procedures | Lower, mostly infrastructure |
| Vendor-supported apps | May not support it | Usually still supported |
Risks and limits
A database migration can fail quietly. Data can arrive complete and still produce different business results if a rounding rule or a date calculation changed. This is why we validate outputs of real reports and batch runs, not only table counts.
- Running two databases in parallel reduces risk but costs time and money, and dual writes from applications are easy to get wrong. We prefer replication from a single source of truth.
- Downtime during final cutover depends on data volume, change rate and the cutover design. We do not promise an outage-free cutover.
- Compliance duties, such as retention and access control, follow your own policies and your auditors. We align with them and do not replace them.
If a database is stable, well supported and not blocking anything, leaving it alone is a valid result of the assessment.
Database modernization questions
- Can every Oracle database move to PostgreSQL?
No. Many can, especially those that use mostly standard SQL. Databases that rely on engine-specific features or large procedural codebases cost more to convert, and some third-party applications only support their original engine. The inventory step tells you which group each database falls in before you commit budget.
- How do you prove the new database matches the old one?
We compare row counts and checksums at table level, then run the same business reports and batch cycles against both and compare the results. Differences are traced to a cause and either fixed or accepted in writing by the data owner. Validation repeats on every rehearsal and again at cutover.
- What happens to our stored procedures?
They are inventoried and ranked by use. Unused ones are retired. Simple ones are converted with tools and tested. Complex ones are either rewritten in the target dialect or moved into application code, depending on how your teams prefer to maintain business logic.
- Do we have to take the system offline?
Often a short window is still needed for the final switch. With continuous replication and rehearsed cutovers it can be kept small, but its length depends on data volume and change rate. We plan it with your operations team and agree a rollback trigger in advance.
- Is this part of a larger program?
It can be. Databases frequently move alongside the applications that use them, and the plan has to keep both in step. See COBOL modernization for the case where programs and data are migrated together, and where record formats and batch jobs add their own constraints.
Tell us about the database
A short description is enough to start. Message us on WhatsApp at +92 326 5200333 or use the request form, and ask for a mutual NDA if you need one first.
What to send
- Engine, version and approximate size
- Number of schemas and stored procedures
- Applications and reports that depend on it
- Target database or cloud, if chosen
Planning a database move?
Send the request form or message us on WhatsApp with the engine, size and the applications that depend on it.