«Migrate the whole history»
Often half the history is never read again. Splitting archive from operational data cuts time, risk and cost — but must be decided up front.
Migrating a business system database without stopping the company.
A live business system does not shut down for a weekend. The migration must be designed as a gradual transition with a way back, not as a jump: that is the difference between a project you control and one you endure.
What actually moves
The database is the visible part. There is more underneath.
- The data: the part everyone estimates, and usually the least problematic.
- The logic inside the database: stored procedures, functions, triggers, views. This is where the risk concentrates.
- Scheduled jobs: nightly runs, exports, reconciliations. They live outside the application and nobody remembers them until they break.
- Integrations: reports, analytics tools and third-party applications reading straight from the database, often unknown to IT.
- Permissions: users, roles and views created over the years for one-off needs, discovered only when someone loses access.
Cutting over without stopping
A sequence that always keeps the way back open.
- Initial replication with the system running, so the new database catches up while the old one works.
- Dual write or continuous sync for as long as validation needs, with the old system still authoritative.
- Systematic comparison between the two: not sampled, but on the totals the company uses to close the month.
- Move the source of truth in a short window, with rollback criteria decided and written beforehand.
- Keep the old system read-only for an agreed period: it costs little and is worth a great deal on the day you need it.
The mistakes that cost most
«IT will do the testing»
Real defects are found by daily users, who know the cases nobody documented. Without them in testing, you find out in production.
«We will look at performance later»
A different execution plan on a different engine can cripple the company’s most-used query. Measure during, on real volumes.
«We will roll back if it goes wrong»
Rollback only exists if it was designed. After a few hours of writes on the new system, without a plan, there is no way back.
What to have ready before starting
- An inventory of everything that reads from the database, third-party applications included.
- The list of reports and totals that will be used for comparison.
- A cutover window agreed with the people who work there, not only with IT.
- Rollback criteria in writing: who decides, by when, and on what basis.
If you have a migration to plan, let us look at the inventory and the cutover window together.
Book an assessmentPage updated 10 August 2026.