Moving an on-premises SQL Server system to Azure, without a rewrite.

Building on IT · 8 October 2026 · 7 min read

Why people want to move

The reasons are rarely about fashion. The server is old and out of warranty. The backups are a tape, a USB drive or an act of faith. Staff need the system from home, from site, or from another office. The IT person who looked after the server has left. Or the supplier's hosting arrangement is ending and nobody wants to buy another box.

All of these are solved by moving the system to Microsoft Azure. None of them require the system to be rewritten.

What "the system" usually is

A typical on-premises business system built in the last twenty years consists of a SQL Server database, a web application running on IIS (classic ASP, ASP.NET WebForms, MVC, or something more recent) and perhaps a Windows desktop application or a reporting service alongside. Each of these has a direct counterpart in Azure.

• SQL Server database → Azure SQL Database, or Azure SQL Managed Instance where the database relies on features (cross-database queries, SQL Agent jobs, CLR) that the simpler service does not offer.
• IIS web application → Azure App Service, which runs .NET Framework and modern .NET applications without a server to maintain. Classic ASP also runs on App Service.
• Windows desktop application → usually stays on users' PCs and simply connects to the new database, or is published through a remote-desktop arrangement if it must run centrally.
• Reports → Reporting Services has cloud equivalents, and Power BI can often be pointed straight at the migrated database.

What the move actually involves

1. Assessment. Microsoft's free tooling checks a database for anything Azure SQL will not accept. Most line-of-business databases pass with few or no changes; the exceptions are usually old compatibility settings or features that have modern replacements.
2. A trial migration. The database and application are copied to Azure and run there, side by side with the live system, against a copy of the data. This is where the surprises appear, and it is where you want them to.
3. Configuration, not code. Connection strings, file paths, email settings, authentication. Each is changed in configuration. Code changes, where needed at all, tend to be a handful of lines.
4. Cut-over. A final copy of the data, a change of address, and the old server is switched off. For users, the system looks the same; it is simply reached at a new address, from anywhere.

For a typical system this is days of work, not months, and can be quoted at a fixed price once the assessment is done.

The things that catch people out

Every migration we have done has had at least one of these. They are all manageable; the point is to know to look.

• Regional settings. An Azure App Service defaults to US conventions. A system that has always run on a UK server may suddenly read 03/04 as the 4th of March. Display often stays correct, which makes it easy to miss. One configuration setting fixes it; it has to be set.
• Files on disk. Systems that write uploads, exports or logs to a local folder need those folders to exist, or to be redirected to Azure storage.
• Email. On-premises systems often send email through a local Exchange server or an open relay. Azure needs a proper mail service, which is also a chance to make the email more reliable.
• Scheduled jobs. SQL Agent jobs and Windows scheduled tasks have cloud equivalents, but they do not move by themselves.
• Authentication. Applications that relied on Windows logins over the office network need another arrangement. The usual answer is Microsoft Entra, letting staff sign in with the Microsoft accounts they already use; this is often an improvement rather than a compromise.
• Old components. A reporting control or PDF library from 2009 may not install on App Service. There is nearly always a modern replacement; the migration is the moment to find it.

What you get

No server to patch, power or replace. Backups taken automatically and kept for weeks, with point-in-time restore. Access from anywhere, with proper sign-in. Running costs that are visible every month rather than arriving as a capital bill every five years. And a system that is now in a position to be improved gradually, because it is sitting on a platform somebody can work with.

When a rewrite is justified

Occasionally the assessment shows a system that genuinely will not run in the cloud without substantial work, or whose technology is so old that any change is disproportionately expensive. Even then, the right order is the same: get the database into Azure first, because that is where the value is and it is almost always possible, and then rebuild the application around it one area at a time while the original keeps running.

← More articles