The ERP ran on hardware the business could no longer buy spares for. Backups existed but had never been restored end to end. The finance year-end was four months away, which set an immovable deadline for anything risky.
Restore first, migrate second
Before planning any move we restored the most recent backup into an isolated environment. It failed. Two database files were being skipped by a job that had been reporting success for over a year. Finding that was worth more than the migration itself.
Staged, with the old system always available
Lift the read replicas
Reporting and analytics moved first. They were read-only, heavily used, and nobody loses money if a report is late. This validated connectivity, identity and backup in the new environment under genuine load.
Move the application tier, keep the database put
For six weeks the application ran in the cloud against the on-premise database over a private link. Slower than ideal, but it isolated application problems from data problems, which otherwise arrive together and are impossible to tell apart.
Then the database, with a measured cutover
Replication ran for two weeks. The switch took eleven minutes inside a normal working morning, with the old database still live and ready to take traffic back.
What changed afterwards
Environments are now created from code, so a test environment takes minutes rather than a procurement cycle.
Restores are tested automatically every week. The one that mattered had never been tested at all.
Releases moved from monthly to roughly weekly, because the risk of each one fell.
The part worth repeating
The infrastructure spend fell, which was the business case. The thing that actually mattered was discovering a broken backup before it was needed rather than afterwards.
This is typical of our infrastructure and DevOps work alongside integration. If your recovery plan has never been rehearsed, that is worth a conversation.