Database modernisation
Move databases off costly licences and ageing versions onto PostgreSQL or a supported platform, with schema conversion, continuous sync and a cutover you can reverse.
Your data outlives every application. Move it with care.
Databases are often the hardest part of modernisation: years of data, business logic in stored procedures, and every report and integration depending on the schema. They are also where licence and support costs quietly pile up.
We modernise databases step by step: assess what's inside, convert the schema and code, migrate the data with continuous replication, prove it with reconciliation, and cut over with a way back ready.
When it fits
01
Licence costs keep rising
Enterprise database licences tied to processor cores make every hardware refresh more expensive.
02
Versions are out of support
No more patches, repeated audit findings, and application upgrades blocked by the database underneath.
03
Logic is trapped in the database
Thousands of lines of PL/SQL or T-SQL that only one database product can run.
04
Reporting slows the business
Analytical queries compete with transactions on the same database at the busiest times.
What we do
Database assessment
Size, complexity, stored code, features in use and dependencies, with an estimate of the conversion effort.
Oracle and SQL Server to PostgreSQL
Convert schemas, PL/SQL and T-SQL to PostgreSQL with tools such as ora2pg, then review and fix by hand what tools can't.
Upgrades and replatforming
Upgrade to supported versions, or move to managed or containerised database services run by operators.
Near-zero-downtime migration
Replicate changes continuously with change data capture, so old and new stay in step until the cutover.
Validation and reconciliation
Row counts, checksums and business reports compared between old and new, and signed off by the data owners.
Performance and resilience
Indexing, query tuning, caching with Redis, read replicas, high availability, backups and tested recovery.
The cutover
A switch you can reverse
Continuous replication keeps the new database in step with the old one right up to the cutover, so the switch takes minutes rather than a weekend. Afterwards, changes flow back the other way for a while, so there is always a way back.
- The current database
- Stays live and in step until the business signs off.
- The new database
- Receives every change continuously, then takes over.
- Reconciliation
- Counts, checksums and reports must match before and after.
- The way back
- After the switch, changes flow back to the old database, so you can return to it if you need to.
How we move a database
01
Assess
Inventory databases, features and stored code, and estimate the conversion and testing effort.
02
Convert
Convert the schema and code, fix what tools can't, and test the applications against the new database.
03
Replicate and validate
Load the history, stream changes continuously and reconcile until both sides match.
04
Cut over
Switch applications in a planned window with rollback ready, then tune performance and decommission.
What you get
- A database inventory and conversion assessment
- Converted schema and stored code, with test results
- Migration and replication runbooks
- Reconciliation reports signed off by data owners
- A performance baseline and tuning results
- High-availability, backup and recovery design
Platforms and tools
- PostgreSQL
- Oracle Database
- Microsoft SQL Server
- MySQL and MariaDB
- ora2pg
- Debezium
- Apache Kafka
- AWS Database Migration Service
- Oracle GoldenGate
- CloudNativePG
- Patroni
- pgBackRest
- Redis
Questions about database moves
Is PostgreSQL ready for core transactional systems?
PostgreSQL runs large transactional workloads around the world. We assess your workload, the features you use and your support needs first, and recommend staying put where a move doesn't pay off.
What happens to our PL/SQL?
Much of it converts to PostgreSQL's PL/pgSQL with tools and review. Some is better moved into application services. We estimate both during the assessment.
How long is the downtime?
With continuous replication, the cutover window is usually short and spent on final checks rather than copying data. We rehearse it before the real thing.
Can we keep Oracle or SQL Server?
Yes. Sometimes the right move is an upgrade, consolidation or licence review rather than a migration, and we'll say so.
Plan a database move with a way back
Tell us which databases you run, how big they are and what depends on them. We'll estimate the conversion and propose a cutover plan.