SQL Server End of Life: The Data Is Easy, the Logic Is the Work

Part 6 followed the server estate down its version ladder and ended by pointing one layer deeper. Behind the servers sit the databases — and inside the databases is where the logic actually lives. A Windows Server can be re-imaged in an afternoon. The SQL Server it hosts is a different kind of object: not just a store of rows, but the system of record under an application, wrapped in a decade of stored procedures, T-SQL, and jobs the business has quietly come to depend on. That is why SQL Server is the platform where “just upgrade it” breaks down hardest — and where the gap between moving the data and moving the system is widest.

The SQL Server end-of-life ladder

SQL Server follows Microsoft’s Fixed Lifecycle Policy — five years of mainstream support, then five of extended support — so its versions retire on a staggered schedule. Several of the versions still running production workloads are already past the line or close to it.

Version	Mainstream support ends	Extended support ends	Status
SQL Server 2014	July 9, 2019	July 9, 2024	Already end of life
SQL Server 2016	July 13, 2021	July 14, 2026	Ends this year
SQL Server 2017	October 11, 2022	October 12, 2027	Near
SQL Server 2019	February 28, 2025	January 8, 2030	On the clock

All dates are Microsoft’s Product Lifecycle figures. Two of them deserve a second look. SQL Server 2014 passed end of life on July 9, 2024 — an engine still common in production has been receiving no security updates for over a year. And SQL Server 2019, the version most teams think of as “current,” left mainstream support on February 28, 2025: it is already in its security-patches-only phase, receiving no functional fixes, with the hard cliff waiting on January 8, 2030. The version that feels safe is further along than it looks.

What SQL Server end of life actually changes

End of life is not a switch that disables the software, and running an out-of-support database is not illegal. What ends is the security patch pipeline — and on a database, that pipeline guards the most sensitive asset most organizations own. The consequences are concrete:

• New vulnerabilities stay open forever. A flaw disclosed the day after the deadline will never be patched on that version — the fix simply never ships. Endpoint controls and network segmentation reduce the blast radius; they do not close the hole in the engine that holds your data.
• It collides with compliance. PCI DSS, SOC 2, and HIPAA all expect in-scope systems to be patchable on a clock. An unsupported SQL Server in the cardholder-data or ePHI path becomes a recurring finding, and the usual answer — documented compensating controls — gets harder to defend at every assessment.
• The cost compounds quietly. Standing still is rarely one line item. It is the rising Extended Security Updates bill, the compensating controls, the cyber-insurance scrutiny, and the growing risk that the one person who understands the integration jobs leaves before the migration does.

SQL Server does have an ESU bridge — with a rising toll

Here is a genuine difference worth naming, because it sets up the next part: SQL Server has a paid Extended Security Updates program. Windows and SQL Server both get one; as the next chapter shows, Office and Exchange do not. For SQL Server, ESUs carry MSRC-Critical security updates only — no new features, no functional fixes, no technical support — for up to three years past the deadline, billed through Azure Arc on a pay-as-you-go basis. That gives SQL Server 2016 a paid runway to July 2029, 2017 to roughly October 2030, and 2019 to roughly January 2033.

The catch is in the pricing. ESU cost rises year over year, by design: the program is built to make standing still progressively more expensive than moving. It rents time; it is not a place to settle. We take apart the economics of that bridge — and why treating it as a destination is a trap — in Part 3, The Extended Security Updates Trap. For SQL Server the useful way to hold it: ESU buys you a planned migration window, not permission to skip the migration.

The data is easy. The logic is the work.

Now the part that actually determines the timeline. Ask most teams to scope a SQL Server migration and they estimate the data move — how many terabytes, how long to copy, how to cut over the tables. That is the easy part, and it is well-tooled. Copying rows onto a supported version, or lifting a database to a managed cloud service, is a solved problem measured in a maintenance window.

What is not easy — what turns a database migration into a multi-year program — is everything the application has pushed into the database over the years:

• Stored procedures and functions that stopped being data access a long time ago and became business logic. Pricing rules, eligibility checks, month-end calculations, state machines — thousands of lines of T-SQL that the application calls and trusts, often the only place a given rule is written down.
• Triggers and constraints enforcing invariants nobody has re-documented, firing on writes in ways the application layer assumes but never states.
• T-SQL dialect and version-specific behavior — query hints, isolation quirks, deprecated syntax, features tuned to one release. Move engines, or even jump several versions, and behavior that “just worked” shifts in ways only a live comparison catches.
• ETL and integration jobs — SSIS packages, SQL Agent jobs, scheduled loads and extracts — wired to this instance, this schema, these procedures, frequently authored by someone who has since left.

Consider the ordinary case. A finance system’s month-end close runs through a chain of forty stored procedures, calling each other in an order nobody has diagrammed, with two of them relying on a DATETIME rounding quirk and one on a deprecated hint that a newer engine silently ignores. Copy the tables to a supported version and every row arrives intact — and the close produces a subtly different number, discovered three weeks later by an accountant, not a test. The data moved perfectly. The behavior didn’t. That gap is the whole risk, and it is invisible until something reconciles the new output against the old.

This is the core of the argument. A SQL Server instance is rarely just a database; it is the system of record with a decade of application logic bound to this specific version. Untangling that entanglement is what consumes years, and it does not care that the deadline reads 2030. “We have runway” mistakes the size of the data for the size of the job. The data is a copy operation. The logic is an excavation.

How the logic moves — slice by slice, proven before cutover

The reason this matters is that the logic can’t be moved in one leap without betting the business on a single cutover — and the more logic lives in the database, the worse that bet gets. The durable path is the same one every part of this series lands on: move it incrementally, prove each piece before it carries load, keep the legacy database serving the whole time.

In practice, a strangler facade sits in front of the data access. Behavior crosses over in slices — a stored-procedure cluster, a set of queries, a bounded region of the schema, one integration job — and before any slice carries live writes, you prove it behaves identically to the legacy: same results, reconciled record by record against the original. AI-accelerated discovery reads the schema, the procedures, and the jobs end to end and captures what they actually do, including the undocumented rules nobody wrote down, under senior-engineer review. Traffic shifts only on green. The legacy SQL Server is decommissioned only once nothing routes to it.

Not every instance needs this, and that’s worth being plain about here too. A stable database under no compliance pressure, whose application carries forward cleanly, is often best served by a straightforward in-place upgrade to a supported version — the lowest-cost way to clear the deadline. The slice-by-slice approach earns its place when the migration is genuinely entangled: when the logic lives deep in the database, when the system can’t take downtime, or when you’re changing engines. Matching the effort to the actual coupling is part of the assessment, not an afterthought.

Where this leads

SQL Server at least gives you a lever to buy time — the ESU bridge is real, even if the toll rises. That makes it the last platform in this series that does. The next one takes the bridge away entirely: Part 8, Office & Exchange End of Life: The No-ESU Cliff, covers the productivity and mail tier that hit end of support on October 14, 2025 — and unlike Windows and SQL Server, they have no paid ESU program at all. There is nothing to buy. One more Microsoft cliff, and this one has no bridge.