Microsoft Dynamics GP end of life: your 2025 to 2031 timeline

Microsoft Dynamics GP, the product many finance teams still call Great Plains, is being retired. Not abruptly, and not with a kill switch, but on a published lifecycle schedule that Microsoft has confirmed in its own documentation and is unlikely to extend.1 If your general ledger, payables, or payroll runs on GP, the dates below are now part of your planning calendar whether you have looked at them or not. This page is the full story: what each date means, why the 2029 date landed where it did, how big the remaining GP install base actually is, and what to do next.

The four dates that define GP’s end of life

Two of these dates matter far more than the others. The license-sales dates mostly affect resellers and companies trying to spin up new GP entities. The 2029 and 2031 dates affect everyone still running the product, which, as the next section shows, is still a meaningful number of companies.

Why December 31, 2029 is the real deadline

GP will not shut down on January 1, 2030. Your databases will open, batches will post, SmartLists will run. What changes is everything around the software: no more product enhancements, no more regulatory or tax updates, no more service packs, and no more technical support from Microsoft.1

The most concrete problem is payroll and tax. Microsoft ships US and Canadian payroll tax updates for GP every year: federal and state or provincial tax tables, updated forms, year-end changes. Those updates stop after December 31, 2029. If you run payroll from GP, your first 2030 pay run would use 2029 tax tables. If you file 1099s, T4s, or sales tax from GP, the forms and rates freeze too.

That date is not arbitrary, and it is not the date Microsoft originally announced. Microsoft pushed the mainstream-support cutoff later than its earlier planned date specifically so customers would have room to complete a full year-end payroll and tax cycle before losing tax-table support.1 Read plainly, that is Microsoft telling you what the deadline is actually for: finishing your last clean year-end on GP, not starting your migration after the fact. The honest way to read the timeline is this. If GP touches payroll or statutory filings, you need to be live on a replacement before the end of 2029, not merely migrating by then. Year-end close and the first payroll of the new year are the worst possible moments to be mid-cutover, so realistic go-live targets cluster in early-to-mid 2029 or sooner.

Technical support ends the same day. Today, when a GP service pack breaks Management Reporter or an eConnect integration starts throwing errors, there is a support path. After 2029 there is not. Your partner channel will also thin out: GP consultants are retiring or retraining, and the pool of people who can debug a Dexterity customization shrinks every year.

What the 2031 date adds

Between January 2030 and April 2031, GP receives security updates only. That window exists so that companies mid-migration are not running unpatched software, not so that anyone can settle in for the long haul.1

After April 30, 2031, security updates stop, subscription billing stops, and the product is frozen. No patches for newly discovered vulnerabilities in GP itself, and GP’s dependencies age around it: newer versions of SQL Server, Windows Server, and Microsoft 365 were never tested against it. This is not a hypothetical risk category. In one widely cited independent study, 60% of organizations that suffered a data breach said the breach exploited a known vulnerability for which a patch already existed but had not been applied, and 62% of those breached did not know they were vulnerable before the breach happened.3 After April 2031, GP customers are not choosing whether to apply a patch late. There is no patch to apply, ever, for anything discovered from that date forward. Auditors and cyber-insurance underwriters increasingly treat unsupported ERP software as a finding. If your insurer asks whether critical systems receive security patches, the honest answer after April 2031 is no.

Who is actually still running GP

It is easy to treat an end-of-life notice as background noise if you assume everyone else already left. That is not what the data shows. Independent technology-usage analytics currently put the number of companies still running Dynamics GP at roughly 18,663, holding about 2.31% of the accounting-software category.4 That figure is a continuously updated estimate rather than a fixed census, so treat it as order-of-magnitude: tens of thousands of GP shops are still out there today, not a handful of stragglers.

The typical profile of those companies is consistent: 50 to 200 employees and $10 million to $50 million in annual revenue.4 That is squarely the lower-middle market, which matters for how the end of life actually plays out. These are not enterprises with a 40-person IT department that can absorb a forced re-platforming as a rounding error. They are controllers and finance leads who chose GP years ago because it fit a mid-market company well, and who now need to run a real ERP selection and migration with a lean team.

That shrinkage did not happen because GP failed. It happened because the product has been slowly wound down for two decades while its peer set moved on. Great Plains Dynamics, the first Windows version of the accounting software that became GP, shipped in 1993 out of Great Plains Software’s Fargo, North Dakota headquarters.5 Microsoft acquired Great Plains Software in 2001 for approximately $1.1 billion in stock. At the time of that deal, Great Plains served more than 140,000 businesses across 132 countries, a scale that made it one of the larger mid-market accounting software vendors of its era.5 The roughly 18,663 companies still on GP today are what remains of that base after 25 years of natural attrition, acquisitions, and customers moving to newer platforms, first internally within the Dynamics family and increasingly to cloud-native competitors.

The scale of that original base is worth sitting with for a different reason too. Many of today’s GP customers inherited the system rather than choosing it fresh. Some organizations have been on this codebase and lineage for 25 to 40-plus years, carrying forward chart-of-accounts decisions, customizations, and integrations made under completely different business conditions. That history is an asset in one sense (deep institutional knowledge of how the numbers tie out) and a liability in another (it usually means more Dexterity code, more modified Report Writer output, and more undocumented integrations than a newer system would have accumulated).

Where Microsoft is pointing customers

Microsoft is not neutral about where GP customers should land. Its own lifecycle documentation states plainly that it is encouraging customers to transition to Dynamics 365 Business Central.1 That is a meaningful data point on its own: this is not a competitor’s marketing claim about what GP customers “should” do, it is Microsoft’s designated successor product, stated in the same documentation that sets the retirement dates.

That does not make Business Central the automatic right answer for every GP shop, and Microsoft’s own framing does not require it to be. Business Central is a strong fit for GP customers who want to stay close to Microsoft’s ecosystem (Microsoft 365, Power Platform, Azure) and whose processes map reasonably well onto its model. It is a weaker fit for companies with heavy manufacturing complexity, highly bespoke workflows that GP’s Dexterity customizations were built to support, or a preference for open-source, extensible platforms with no per-user licensing ceiling. NetSuite, Sage Intacct, QuickBooks Online, Odoo, and custom-built alternatives all serve real segments of the departing GP base well. The point of the lifecycle dates is not “go to Business Central.” It is “stop running GP past 2029 for anything that touches compliance,” and separately, “choose your real destination based on your business, not on which option Microsoft mentions first.”

The cost of waiting

There is a version of waiting that looks rational: GP works, the team knows it, and 2029 sounds far away. Three things erode that logic.

Migration capacity is finite. Every one of the roughly 18,663 remaining GP customers faces the same deadline.4 Partners who do GP-to-anything migrations are already booking out, and the crunch gets worse as 2029 approaches. Companies that start in 2028 will pay more, choose from fewer available teams, and have no slack for a delayed go-live.

Your data problem grows. Every month on GP adds transactions to migrate, reconcile, and validate. Multi-company databases, years of historical versus open transactions, and unposted batches all take real work to bring across cleanly. That work is cheaper and calmer when there is no deadline pressure. It is also worth sizing correctly: broad industry data on ERP migrations specifically (as opposed to GP alone) suggests data problems are a leading cause of both budget and schedule overruns, not a footnote. In one independent 2024 survey of 131 organizations running ERP projects, data issues were named by 34.9% of projects that went over budget and by 46.3% of projects that went over schedule, the single largest named cause of schedule slippage apart from generic resource constraints.6

Rushed selections go badly. The most expensive ERP mistake is not paying too much. It is choosing the wrong system under time pressure and living with it for a decade. A team that starts in 2026 or 2027 can run a proper selection. A team that starts in mid-2029 takes whatever it can get live in time. The same 2024 survey found the median ERP implementation across all respondents took 15.5 months and cost $450,000, with only 55% of projects finishing on budget and 58% finishing on schedule.6 That sample skews larger than a typical GP shop, so treat the absolute dollar figure as a scale reference rather than a GP-specific quote, but the timeline and overrun rates are the more transferable lesson: budget more time and more contingency than feels comfortable, because even well-resourced organizations routinely need it.

None of this requires panic. It requires a calendar.

How to think about your own timeline

Work backwards from December 31, 2029, and adjust for your situation.

If GP runs your payroll or tax filings: target go-live no later than mid-2029, which means starting implementation by early 2028 for a complex environment, or early 2029 for a simple one. Selection comes before that. Remember the year-end logic above: your last GP payroll cycle needs to close cleanly and your first 2030 payroll needs to run on a system with current tax tables.

If GP is your GL but payroll lives elsewhere: you have slightly more room, but support still ends in 2029 and the 2031 security cliff still applies. Treat 2029 as the deadline anyway. The extra window is contingency, not schedule.

If your GP install is heavily customized: Dexterity customizations, Integration Manager jobs, eConnect integrations, and ISV add-ons do not migrate. Each must be replaced, rebuilt, or retired in the new system, and cataloguing them is the first honest step. This inventory usually takes days, changes the whole plan, and costs almost nothing, so do it first.

If you are a simple, single-company GP shop: your migration may take only 3 to 6 months, which is exactly why waiting is tempting and unnecessary. Moving early gets you better pricing, better partner availability, and years of a supported system instead of years of countdown.

A reasonable plan for most GP customers in 2026 looks like this: inventory your GP footprint this quarter, run destination selection over the next two, and go live with a full year of buffer before the 2029 deadline. That pace is unhurried. The same project started in 2028 will not be.