Keep the Platform Current: The Deadlines GP’s Calendar Doesn’t Show
Microsoft has put two dates on Dynamics GP and, by now, most of the GP world can recite them: December 31, 2029, and April 30, 2031. What almost nobody recites is a third fact, which matters more day-to-day than either date: Those two dates belong to the Dynamics GP application. They say nothing about what GP runs on. And what GP runs on doesn’t wait for 2029. It’s already running out, one layer at a time, on a schedule GP had no part in setting.
One Clock On Top, a Fistful Underneath
Think of GP as two things stacked together. On top is the application itself: the forms, the ledger, the customizations, years of institutional memory. For a shop that’s settled into GP, this layer has effectively stopped moving, and that’s a feature: It’s why staying is viable at all. It carries one clock, the one everyone already knows.
Underneath is the platform: SQL Server, Windows Server, the .NET runtimes, the host, every ISV add-on hanging off the application. This layer isn’t settled at all, and it doesn’t share GP’s clock; it carries as many clocks as it has parts, each set by a different vendor, several running out well before 2029.
That’s not a hypothetical risk. SQL Server 2016, still sitting under plenty of GP installs, reached the end of its support on July 14, 2026 — three and a half years before GP’s own cutoff of December 31, 2029. Windows Server 2016 follows in January 2027, and it’s already causing trouble in a visible way: GP’s own October 2025 update moved to TLS 1.3, which Microsoft flags as a source of Web Client problems on that older Windows Server. Neither of those dates shows up on a “supported until 2029” slide. Both are already a shop’s nearest deadline, not GP’s.
Currency Compounds: The Build You’re On Decides What You Can Move To
Here’s the part that catches people out even after they’ve absorbed the first idea: Staying current on GP isn’t only about Microsoft’s support clock for the application. It’s also what unlocks — or blocks — every move on the platform underneath.
Every GP build ships with its own compatibility matrix: which SQL Server versions it supports, which Windows Server versions, which .NET runtimes. A shop can be perfectly eligible for Microsoft support and still be unable to move to the SQL Server version it needs, because the GP build it’s running predates that support. The newest, longest-supported database engine and operating system are only reachable from a current-enough GP build — which means the order is fixed: When the platform needs to move, GP updates first, not after.
That compatibility matrix doesn’t just expand as new builds ship; it also narrows behind you. A later release can drop support for an older SQL Server version at the same time it adds a newer one, which means updating GP can force a platform decision as easily as it enables one. A shop that lets its GP build slide isn’t just missing new features it probably didn’t want. It’s quietly shrinking the range of platform moves still available to it, and the shrinking is invisible until the day it tries to make one.
This matters more, not less, as GP approaches its own end. GP’s build releases stop entirely once the product reaches end of life — whatever compatibility matrix a shop is on when the last build ships is the one it keeps permanently. A shop that stays current all the way to that point lands with a decade or more of supported platform underneath a frozen application. A shop that let its updates lapse years earlier freezes its options at whatever build it stopped on — for good, with no later release ever coming to widen it again.
Turning a Fistful of Clocks Into a Manageable Practice
None of this requires panic or a project plan measured in months. It requires two habits, both small.
The first is writing it down: one document, one row per layer — GP’s build number, SQL Server’s version, Windows Server’s, the .NET runtimes, every ISV component — each with its own end-of-support date and an owner. That single artifact is what turns “We’re fine until 2029” from an assumption into something you can actually check. Most shops that do this for the first time are surprised by what they find: The most urgent item on the list is rarely GP.
The second is revisiting it on a schedule, not when something breaks. A short review, a few times a year, that asks what’s moved closer to its date, what’s shipped that’s new, and what needs to become scheduled work rather than a line on a spreadsheet.
Once you know your dates, the two highest-leverage moves are almost always the database engine and the operating system underneath it, and both can be done as a rehost that leaves GP itself untouched.
The Bottom Line
The real risk in staying on GP was never really about GP. Both of Microsoft’s dates are true, and neither one is the deadline that will catch a shop off guard — the deadline that does that belongs to whichever platform layer expires first, and for a lot of shops that layer already has. Keeping GP itself current isn’t a nice-to-have alongside that work; it’s what keeps the door to the newest, longest-supported platform open at all, on every layer beneath it.
This is the part of staying deliberately that’s entirely within your control, on your own schedule, regardless of whether you’ve decided to stay for years or are still weighing a move. Write down what you’re running and when each piece expires. That’s the whole first step, and it’s the one that turns every date after it from a surprise into a plan.
Read part 1 of the series here.
