Database Migration Between Platforms
Database migration moves your data from one engine or hosting platform to another. Tables and data types are converted, the move is rehearsed, and the switch happens at a time you choose.
Why businesses move
- A licence renewal that no longer suits the size of the database
- An engine version out of support, so security patches no longer arrive
- A move from a server in the office to hosting, or the other way round
- Queries that have grown slow because the platform has reached its limit
How the move is planned
The schema is converted first, since data types rarely map one to one between engines. Dates, decimals and text fields cause most of the trouble. Data is then loaded into the new platform and compared row by row with the old one, with totals checked on the tables that matter to finance. This rehearsal runs at least once before production is touched. A rollback plan is written in the same sitting.
The cutover itself
Work stops for a defined window, often a weekend or an overnight stretch chosen around your billing cycle. Final changes are copied across, applications are pointed at the new platform, and your staff run a short list of checks before anyone else logs in. The old database stays untouched for a few weeks. Nothing is deleted on the day.
Frequently asked questions
How long is the database unavailable during a migration?
It depends on the size of the database. The window lasts as long as the final sync and the checks take, and the rehearsal gives a measured figure. The window is agreed in advance around your billing cycle.
Does our application code have to change?
Usually some of it does, because engines differ in query syntax and in how they treat dates and text. The extent is known after the rehearsal.
What if something breaks after we have switched?
The old platform is still there, so the fallback is to point back at it while the fault is fixed. This is why nothing is decommissioned for several weeks after a cutover.
Can we migrate in phases instead of all at once?
Sometimes, where an application reads from one group of tables and writes to another. Often a single cutover is safer, because two live copies of the same data can drift apart.
Tell us what you need.
Share your requirements and one of our engineers will come back to you within one business day.
- No obligation
- A reply within one business day
- Your details stay private
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirements