Your Next 90 Days: Where to Start Before the Deadline

ModernLift · ·9 min read
Part 10 of 10

Build your modernization roadmap in three moves. Inventory every system against the Microsoft deadline calendar. Prioritize each by deadline proximity, security and business risk, and how tightly its apps are pinned to the platform. Then pick the single highest-priority slice and prove a modern equivalent in production — the first real step off legacy.

Nine parts in, the argument is settled. The Microsoft stack is hitting a coordinated end-of-life wave; buying time with paid updates only rents a runway; upgrading the operating system doesn’t move the apps pinned to it; and those apps move one proven slice at a time, not in a single rewrite. Knowing the path, the only question left is where to start. This part answers it — a modernization roadmap you can begin this quarter, in three concrete moves.

None of this requires a year of planning before anything happens. It requires an honest inventory, a clear-eyed sort, and the discipline to prove one thing before scaling it.

Step 1 — Inventory the estate against the deadline calendar

You cannot prioritize what you haven’t listed. The first move is a complete inventory of the estate mapped against Microsoft’s actual dates — not a rough sense of “we’re on some old stuff,” but a real register: which system runs which workload, on which version, with which end-of-support date, and whether a paid update bridge even exists.

Here is the calendar to inventory against. These are the verified Microsoft lifecycle dates from across this series (all per the Microsoft Product Lifecycle), current as of mid-2026:

PlatformEnd of supportPaid update bridge?
Windows 10 (Home/Pro/Enterprise/Education)Oct 14, 2025 (past)ESU — consumer to Oct 13, 2026; commercial up to 3 yrs
Windows 10 LTSB 2016 / LTSC 2021 / LTSC 2019Oct 13, 2026 / Jan 12, 2027 / Jan 9, 2029Separate fixed dates; no ESU needed until then
Windows Server 2012 / 2012 R2Oct 10, 2023 (past)ESU final year ends Oct 13, 2026
Windows Server 2016Jan 12, 2027ESU available after
Windows Server 2019Jan 9, 2029ESU historically offered
Windows Server 2022Oct 14, 2031Common landing spot; years of runway
SQL Server 2014Jul 9, 2024 (past)ESU to Jul 8, 2027
SQL Server 2016Jul 14, 2026ESU up to 3 yrs after
SQL Server 2017Oct 12, 2027ESU up to 3 yrs after
SQL Server 2019Jan 8, 2030ESU up to 3 yrs after
Office 2016 / 2019Oct 14, 2025 (past)No ESU — hard cliff
Exchange Server 2016 / 2019Oct 14, 2025 (past)No ESU — hard cliff
SharePoint Server 2016 / 2019Jul 14, 2026No ESU; only Subscription Edition stays supported

Two things jump out of that table the moment it’s real. First, several deadlines have already passed — anything on mainstream Windows 10, Server 2012, SQL 2014, Office 2016, or Exchange 2019 is running unpatched today. Second, the platforms with no bridge at all — Office and Exchange — aren’t a future problem you can defer with a purchase order; they’re already unpatchable in place. The inventory isn’t paperwork. It’s the map that tells you which fires are already burning.

For each system, record one more column the calendar can’t give you: what’s pinned to it. Which line-of-business apps depend on this box, this database, this Office install? That’s the column that turns a platform list into a modernization plan, because it’s where the real work lives — exactly as the desktop, server, SQL, and Office and Exchange chapters each showed.

Filling that column by hand across a large estate is slow, which is where AI-accelerated discovery earns its place: reading the codebase, data, and integrations to map dependencies and the undocumented domain rules in weeks rather than months, so the inventory is grounded in what the code actually does rather than what a spreadsheet remembers.

Step 2 — Prioritize by deadline × risk × app-pinning

An inventory tells you what you have. It doesn’t tell you what to touch first. Sort every entry by three factors together, because any one of them alone will point you wrong:

  • Deadline proximity. How close is the date — or how far past? A lapsed deadline is more urgent than an upcoming one, not less.
  • Risk. What’s the blast radius if this stays unpatched? An internet-facing mail server or a database holding regulated data carries far more exposure than an isolated internal tool on the same lifecycle date. This is where the generic end-of-life risk picture matters, and we treat it in full in the security and compliance series — the Microsoft specifics feed straight into this ranking.
  • App-pinning. Can the workload carry forward with a clean in-place upgrade, or is it genuinely entangled with the platform? A system that upgrades cleanly is a quick win to clear off the board. A deeply pinned one is where incremental modernization goes — and where you want to start early, because it’s measured in slices, not a weekend.

The product of the three is your order of operations. An unpatchable, internet-facing, deeply-pinned system beats everything. A cleanly-upgradeable internal app with a 2029 date waits. Most estates sort into three buckets fast: upgrade now (clean carry-forward, take the cheap win), modernize (pinned apps that need the slice-by-slice path), and watch (supported long enough to plan deliberately). The big-bang-versus-incremental decision from Part 9 is what tells you which bucket each one lands in.

Be honest in the sort. The temptation is to file everything as “just upgrade the OS” because it’s cheaper this quarter. But an in-place upgrade moves the box and leaves the entanglement — you clear the finding and keep the problem. The prioritization only works if the app-pinning column is truthful.

Step 3 — Pick the first slice and prove it

Here’s the move that separates a plan from a binder that gathers dust: don’t try to boil the estate. Take the single highest-priority pinned system and carve off one slice — one vertical thread of real business behavior — and prove a modern equivalent for it, in production, behind a routing facade, with the legacy version still serving traffic and rollback ready.

That first slice does disproportionate work. It converts the whole approach from a slide into a fact: it proves the seam holds, proves the parity gates catch what they should, proves the team can ship a validated equivalent without a service interruption. It de-risks every slice after it, because now the pattern isn’t a promise — it’s something the business has watched work. Value in production every four to eight weeks starts here, with one slice, not with a grand cutover you can’t rehearse.

This is the shape of a real engagement, too. A structured discovery pass — typically three to four weeks, fixed price — produces the inventory, the dependency map, the domain model, and a prioritized roadmap. The first accelerator slice puts a modern equivalent in production with the test harness and strangler facade live. From there, slices ship at a steady cadence and the legacy estate is decommissioned piece by piece as it empties. Based on engineering modeling, with early engagements underway, the aim is to compress two to three years of work into a matter of months — not by cutting corners, but by proving each one before moving on.

Your modernization roadmap, in one page

If you do nothing else this quarter, do this:

  1. Inventory the estate against the deadline calendar above — every system, version, date, bridge, and what’s pinned to it.
  2. Prioritize by deadline × risk × app-pinning; sort into upgrade-now, modernize, and watch.
  3. Prove one slice on the top pinned system — a modern equivalent in production, live throughout.

That’s the entire modernization roadmap for the Microsoft wave, and it fits on an index card because the hard part was never the plan. It was having the honest inventory to build it on and the discipline to start with one proven slice instead of one enormous bet. For the roadmap discipline beyond the Microsoft deadlines, How to Build a Modernization Roadmap and the Legacy Modernization Checklist go deeper.

Start the inventory with us

The whole series lands here: the cliff is real, the easy fixes don’t move the apps, and the apps move slice by slice. What’s left is to run it on your estate.

That’s a conversation, not a commitment. Book a 30-minute discovery call — no deck required. We’ll walk your Microsoft deadline exposure, talk through which systems are cleanly upgradeable versus genuinely pinned, and identify the first slice worth proving. You leave with a clearer picture of where you stand and where to start, whether or not we go further together.

The deadlines don’t move. The next 90 days are the ones you still control.

Frequently asked questions

Where do we start if several Microsoft deadlines have already passed?
Triage by exposure, not by date. An internet-facing unpatched system — an end-of-life Exchange or a SQL Server holding regulated data — outranks a desktop deadline even if both lapsed on the same day. Rank what's already past by blast radius, put the nearest upcoming deadline next, and start proving the first slice while you plan the rest.
What is the fastest way to know what's actually pinned to a dying platform?
A structured discovery pass over the codebase, data, and integrations. AI-accelerated analysis maps dependencies and the domain rules nobody wrote down in weeks rather than months — turning "we think these apps are entangled" into a documented inventory you can prioritize against the deadline calendar.
Do we have to modernize everything before the deadline?
No. Where a workload carries forward cleanly, an in-place upgrade to a supported platform clears the deadline cheaply and buys years. Reserve incremental modernization for the apps genuinely pinned to the platform — and even there, you start with one slice, not the whole estate.
All 10 parts of The Microsoft Platform End-of-Life Playbook →