Migrating a Mission-Critical SQL Server Platform to Azure SQL Managed Instance

Moving a critical SQL Server database to the cloud is easy to describe. Moving it without losing a transaction, breaking an application dependency, or discovering a missing SQL Server object the morning after cutover is a different project entirely.

A backup and a restore will move a database. What it will not move is the service around it — the scheduled jobs that run the overnight processing, the logins the applications authenticate with, the certificates without which an encrypted database will not open. Those arrive as absences, discovered one at a time, after production is already on the other side.

So the question was never whether a SQL Server database could be restored into Azure. It was whether the complete database service could move and the applications carry on as though nothing had happened.

Azure SQL Managed Instance as the target: a managed Azure SQL service that keeps the broad SQL Server compatibility an established enterprise application estate depends on. Choosing it was the quick decision. Getting production onto it safely was the project.

That started with an assessment of what actually had to move — at the database level and at the instance level. Jobs, logins, permissions, encryption objects and operational configuration were catalogued as migration items in their own right, not as things to tidy up afterwards. It is the step that separates a database that is online from a database service that works, and the one most often skipped because it produces no visible progress.

The target was then placed inside the wider Azure design, with the application tier in front of it and a second Azure region behind it for recovery.

The managed instance did not arrive on a flat network. A payment workload has an awkward set of neighbours: public web and mobile traffic on one side, an existing data centre on another, and partner banks and remittance networks on a third. All three have to reach the platform. None of them should be able to reach each other.

So the Azure environment was built as separate virtual networks rather than one estate. Public traffic enters through a global front-door service and a web application firewall, then an application gateway and firewall decide which backend it reaches — no application server is directly exposed. The existing data centre connects over a private circuit instead of the public internet, which is what allowed the database to move without every related system moving with it. Partner banks and remittance providers come in through VPN gateways into a network of their own, each able to reach the services its integration needs and nothing else.

Collapsing that boundary is easy at build time and very hard to unpick once a dozen partners are connected through it. Subscriptions, resource grouping, naming, tagging and policy were settled before the first workload moved for the same reason: they are the least interesting part of a cloud migration and the most expensive to change afterwards.

The database was then geo-replicated into a second Azure region, giving the operator a geographically separate copy as part of its recovery position rather than everything depending on one location.

The more interesting decision was what to do with it the rest of the time. Most disaster-recovery infrastructure is paid for monthly and used never — a line item defended once a year. Here, eligible read workloads were directed to the secondary region while transactional writes stayed with the primary.

That buys two things from one spend. The recovery replica stays ready, and it absorbs reporting and query traffic that would otherwise compete with production writes. It also makes the read and write paths explicit rather than accidental, which is the groundwork for scaling either of them later. Disaster recovery stops being an insurance policy and becomes part of the production architecture — and a DR environment that is carrying real traffic is one you find out about quickly if it breaks.

The measure of this project was never whether a SQL database existed in Azure at the end of the change window. It was whether the business could keep operating from Azure with its transactions, its security, its scheduled processing, its integrations and its recovery capability all intact.

The databases moved with the service around them. The cutover protected every committed transaction because the writes were stopped before the final synchronisation, not after. The route back existed before the route forward was taken. And the recovery region does real work between the incidents it was bought for.