Database migration with a plan, a dry run and a short switch-over
Moving a database rarely means just copying data: data types, stored procedures, character sets and the application's queries have to work the same way at the target. Sortia Labs plans migrations in stages, rehearses them with real data volumes and keeps the switch-over as short as possible, drawing on experience from banking IT.
- Database migration
- Oracle to PostgreSQL
- Database move
- Cloud migration
- Version upgrade
- SourceOld version or system
- AnalysisSchema, data, queries
- Test runOn a copy
- TargetNew version or system
- ComparisonCounts and checksums
Migrations we take on
Changing the database system
Oracle or SQL Server to PostgreSQL, MySQL to PostgreSQL or the other way round: schema, data types, procedures and triggers are translated, application queries are adjusted and results are compared with the old system.
Into the cloud or back
From your own server to AWS or Azure, between providers, or from an expensive cloud back to your own hardware in Germany. Before that we compare cost, performance and dependencies.
Large version jumps
Anyone who has skipped several major versions meets changed defaults, removed features and a new optimiser. We collect these changes up front and test the critical queries specifically.
Switch-over through replication
The target runs in parallel and is kept current through replication or change data capture while your application keeps working on the old system. Instead of a maintenance weekend, a short switch-over window is then usually enough.
Verification and a way back
Row counts, checksums and business spot checks show whether everything has arrived at the target. Until sign-off the old system stays ready to run, so the way back remains open.
Four steps to the new database
- 1
Inventory
Which databases, schemas, procedures, jobs and interfaces depend on each other? We also list applications that access tables directly, because those are easily overlooked in a migration.
- 2
Dry run
A full run with a copy of your production data shows duration, conversion errors and deviations. We repeat it until both the results and the timing are right.
- 3
Switch-over
On the agreed date we switch over following a written runbook, with fixed checkpoints and clear responsibilities. Every step is logged, so you can trace afterwards what happened when.
- 4
Aftercare
During the first weeks we watch query times and error logs and adapt indexes and configuration to the new system. At the end your team receives documentation of the new setup.
Questions about Database migration
How long does a database migration take?
That depends on the data volume, the number of procedures and the applications connected to it. Inventory and dry runs take a good deal of the time, the actual switch-over usually only a little. After the inventory you get a schedule with milestones to follow the progress.
Is moving from Oracle to PostgreSQL worth it?
Often, mainly because of licence costs. The effort lies in PL/SQL code, Oracle-specific features and testing the application. Before you decide, we estimate how much code needs translating and which features PostgreSQL solves differently, so you can weigh the savings against the effort.
Can we keep working during the migration?
As a rule, yes. The new database is filled in the background and kept current through replication. Writes are paused only briefly for the switch-over, at a quiet time that we agree with you.
What if something is wrong after the switch-over?
We agree beforehand on the criteria for switching back. If you want, changes flow from the new system back to the old one through reverse replication for a while, so that as little as possible has to be redone when switching back.
Read on.
Planning to move your database?
Describe the source, the target and your time frame. We tell you which questions should be settled before the start and where the risks lie.