SQL Server modernisation and cloud migration

The dates are published, and two of them have already arrived.

Out of support means no security patches. A database server that's reachable from the network and no longer patched is the kind of risk that doesn't announce itself. The server underneath has its own date: Windows Server 2016 support ends in January 2027, and a SQL Server on it goes with the server.

A version chosen when the application was built and never revisited, because it worked. Compatibility level set for a version older than the one installed. Stored procedures that hold business rules nobody has read in years. SQL Server Agent jobs that run overnight and that only one person knows about. Linked servers to something that no longer exists. And three or four applications reading the database that weren't in the original list: a reporting tool such as SSRS, a spreadsheet with a live query, an integration someone set up in 2019.

The database is usually fine. The problem is that nobody has a map of what depends on it, and upgrading a database without that map is how applications break on a Monday.

Upgrade in place, or side by side, to a supported version. SQL Server 2022 or 2025 on a supported Windows Server. The usual answer for a database that stays on your own infrastructure. Side by side (a new server, restore, test, cut over) is safer than in place, because the old server stays as the fallback.

Move to Azure SQL. Azure SQL Managed Instance where the applications need SQL Agent jobs, linked servers and the rest of the full product; Azure SQL Database where they don't. The case is real when the server hardware is due for replacement anyway, when backups and patching are the thing nobody is doing, or when the business is moving other systems to the cloud. It's not automatically cheaper, and the assessment puts the numbers side by side rather than assuming.

Extended Security Updates as a bridge. Paid, per core, and rising each year, but they buy time on 2016 while the applications on top are modernised. Sensible when the application is the real project and the database move is a stage of it, not the point.

Migrate to PostgreSQL. Rarely worth it for an existing system, because every stored procedure and every application query has to change. It comes up when a rebuild is happening anyway and licensing is the driver. The assessment says whether it applies.

The assessment maps what depends on the database and prices each path as a fixed number.

1. Find everything that reads it. Applications, reports, spreadsheets, integrations, Agent jobs, linked servers, replication. This is most of the assessment and most of the risk.
2. Check what the target rejects. Deprecated features, compatibility level, collation, CLR assemblies, old drivers on the application side. SQL Server's own tooling reports most of it; a person reads the rest.
3. Build the new server, or the Azure target, and restore a copy. Run every application against the copy in a test environment.
4. Rehearse the cutover in staging. Restore, re-point each application, run the overnight jobs, run the reports, reconcile counts and totals against the old server.
5. Cut over at a quiet time, with the old server left intact and reachable as the fallback until you're confident.
6. Retire the old server and its Windows licence when the fallback is no longer needed.

Downtime is the length of the final restore and re-pointing, which the rehearsal has measured.

It moves once, by backup and restore or by the Azure migration tooling, and it's reconciled on the other side: row counts, checksums, totals, and a sample of records compared. Nothing switches until the rehearsal in staging has shown the applications work against the new server. The old server stays as the fallback.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a SQL Server move it maps every dependency, checks the target's requirements, and prices the move as a fixed number, alongside the licence and hosting numbers for each path. What drives the price and the payment terms each have a page.

Unpatched, and reachable. That's the whole risk of an out-of-support database server, and it applies to 2016 now. Cyber Essentials and insurance questionnaires ask about it. After that: the Windows Server date in January 2027, the application whose driver won't talk to a newer server, and the overnight job nobody documented, which is found on the day it doesn't run.

Map the dependencies, rehearse the move, keep the old server until the new one has proven itself. Marc Allington has run SQL Server under business systems since SQL Server 2000 and has moved them on-premises and to Azure. Everything we build runs on open, widely used technology, in your own accounts.