---
title: "Dynamics GP End of Life: 2025–2031 Timeline & Migration Plan"
slug: dynamics-gp-end-of-life-20252031-timeline-migration-plan
date: 2026-06-22
author: Raaj
categories: [General]
excerpt: "Microsoft Dynamics GP support ends December 31, 2029. Here's the full timeline, what breaks operationally, and when to start your migration."
tldr: "Dynamics GP product support ends Dec 31, 2029; security patches stop Apr 30, 2031. With migrations taking 9–18 months, planning should start no later than early 2028."
canonical: https://clonepartner.com/blog/dynamics-gp-end-of-life-20252031-timeline-migration-plan/
---

# Dynamics GP End of Life: 2025–2031 Timeline & Migration Plan


Microsoft Dynamics GP reaches end of support on **December 31, 2029**. After that date: no product enhancements, no regulatory or tax table updates, no service packs, no technical support. Security patches continue on a limited, discretionary basis until **April 30, 2031** — then GP becomes a static codebase with zero official support of any kind.

GP will not stop working on January 1, 2030. But the operational reality — no year-end payroll updates, no SQL compatibility hotfixes, no compliance patches, a shrinking ISV ecosystem — makes running unsupported GP a compounding liability. This is not just a licensing change. It is a structural shift that will break your compliance, security, and third-party integrations on a timeline that is already accelerating.

This guide covers every date that matters, explains what each deadline actually breaks, and gives you a concrete framework for planning your migration before you lose access to tax tables, security patches, and ISV support.

For broader context on Microsoft's on-premise sunset strategy, see [The Ultimate 2026 Guide to Dynamics 365 On-Premise End of Life](https://clonepartner.com/blog/blog/dynamics-365-on-premise-end-of-life-2026-guide/).

## The Complete Dynamics GP End of Life Timeline (2025–2031)

Microsoft is phasing GP out over a defined series of milestones. Each date removes a different layer of product viability. Here is the official timeline, sourced from [Microsoft's lifecycle documentation](https://learn.microsoft.com/nl-nl/dynamics-gp/terms/lifecycle):

| Date | What happens | Operational impact |
|---|---|---|
| **April 1, 2025** | End of new perpetual license sales to new customers | No new GP implementations via perpetual licensing. Existing customers can still add seats under current agreements. |
| **April 1, 2026** | End of new subscription license sales to new customers | GP is closed to the market entirely. Existing customers can still add users and modules under current agreements. |
| **December 31, 2029** | End of product enhancements, regulatory (tax) updates, service packs, and technical support | No more year-end tax tables, W-2/1099 schema updates, ACA code changes, hotfixes, or Microsoft support tickets. |
| **April 30, 2031** | End of security updates; end of subscription billing and SPLA usage | Zero patches. Subscription and SPLA customers must stop using GP entirely. Perpetual license holders can no longer add users. |

The **December 31, 2029** date is a revision — it replaced the previously announced September 30, 2029 deadline. Microsoft extended it specifically to cover the final tax year-end, ensuring GP customers receive 2029 year-end payroll and regulatory updates before support ends.

The sharpest distinction is **2029 vs. 2031**. From January 1, 2030 through April 30, 2031, Microsoft may still issue security patches at its discretion, but the broader product is already out of product-enhancement, tax-update, and technical-support life. That is a narrow security-only runway, not a comfortable operating model.

> [!WARNING]
> **Subscription and SPLA users face a hard cutoff.** After April 30, 2031, Microsoft will terminate subscription billing and SPLA usage rights. You cannot legally operate GP under these licensing models past that date. Perpetual license holders may technically continue running the software, but with no patches, no support tickets, and no ability to add users. ([microsoft.com](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2025/06/05/explore-migration-options-for-microsoft-dynamics-gp-and-microsoft-dynamics-sl-customers/))

## Modern Lifecycle vs. Fixed Lifecycle: What It Means for Your Version

Not every GP installation shares the same deadline. Microsoft governs GP under two distinct policies, and which one applies depends on your version number.

### Modern Lifecycle Policy (GP 18.2 and later)

The **Modern Lifecycle Policy** applies to GP version 18.2 and above — any installation updated since October 2019. Under this policy, Microsoft releases three all-inclusive updates per year (typically June, October, and December) containing hotfixes, tax table updates, and regulatory changes. ([learn.microsoft.com](https://learn.microsoft.com/en-us/lifecycle/policies/modern))

The catch: **you must install at least one of these three updates annually to remain eligible for support.** If you skip an entire calendar year of updates, Microsoft can refuse support requests and direct you to upgrade first. The 2029/2031 deadlines apply to Modern Lifecycle customers.

### Fixed Lifecycle Policy (GP 2018 R2 and earlier)

Older GP versions follow the **Fixed Lifecycle Policy** — a rigid 5-year mainstream + 5-year extended support structure. These versions have their own, earlier end dates that are **not extended** by the 2029 announcement:

| Version | Extended support end date | Current status |
|---|---|---|
| GP 2013 / R2 | April 11, 2023 | **Expired** |
| GP 2015 / R2 | April 8, 2025 | **Expired** |
| GP 2016 / R2 | **July 14, 2026** | Active — ends soon |
| GP 2018 / R2 | January 11, 2028 | Active |

If you are running **Dynamics GP 2016**, your extended support ends on **July 14, 2026**. ([learn.microsoft.com](https://learn.microsoft.com/en-us/lifecycle/products/dynamics-gp-2016-r2)) After that date, no security updates, no hotfixes, no support tickets — full stop. Continuing to run GP 2016 on a local SQL Server after July 2026 exposes your financial data to unpatched vulnerabilities and compliance risk.

> [!NOTE]
> **Upgrade escape hatch:** Installing any compatible tax release or hotfix on GP 2018 or GP 2018 R2 will bring your installation to version 18.5 or later, which automatically enacts the Modern Lifecycle Policy. This buys you time until 2029. This path is not available for GP 2016 or older — those versions have no hotfix path to Modern Lifecycle.

## What "End of Support" Actually Looks Like in Operations

GP does not stop booting on January 1, 2030. Your SQL Server keeps running. Your GL still opens. The phrase "end of support" undersells what actually breaks. Here is what concretely stops working after December 31, 2029:

**No more year-end tax tables.** Microsoft will no longer publish the files that update federal and state tax tables, W-2/1099 schemas, FICA limits, state-specific withholding rules, and ACA reporting codes. Your year-end close freezes at the 2029 ruleset. If Congress changes withholding brackets or your state updates unemployment rates, GP will not reflect those changes. Organizations using GP for payroll will be forced to either calculate taxes manually or migrate to an external payroll provider.

**No more regulatory compliance patches.** GP currently receives updates tied to regulatory changes — 1099-NEC reporting, ACA affordability thresholds, Canadian payroll deduction changes. After 2029, these stop. For multi-state or multi-jurisdiction organizations, this creates direct compliance exposure. If your organization operates in a regulated industry (healthcare, finance, government contracting), running unsupported software can violate compliance frameworks like SOC 2, HIPAA, and SOX. Auditors will flag the absence of security patches as a critical finding.

**No more hotfixes or bug fixes.** If a posting error in Payables or a reconciliation bug surfaces, Microsoft will not troubleshoot it. Non-security bug fixes move to "out of scope." Your only option is a paid workaround from a third-party partner — and the pool of Dexterity experts is shrinking fast.

**No Microsoft support tickets.** You cannot open a case with Microsoft. No escalation path exists for any issue, whether it is a crashed module, a corrupt database, or a failed batch post.

**Security patches are limited and discretionary (2030–2031 only).** Between January 1, 2030 and April 30, 2031, Microsoft may publish critical CVE fixes — but only at their discretion and only for critical vulnerabilities. There is no guaranteed frequency or coverage. After April 30, 2031, even this minimal safety net disappears.

**SQL Server and OS compatibility becomes your problem.** GP relies on Microsoft SQL Server and historically requires hotfixes to maintain compatibility with new SQL Server versions. Without those hotfixes, upgrading your database server could break GP. You effectively lock yourself into whatever SQL version you are on — and that SQL version has its own end-of-life timeline. Unsupported software rarely fails all at once; it fails one incompatibility, one compliance gap, and one abandoned integration at a time.

For a detailed look at how these failure modes compound during ERP transitions, see [Why ERP Migrations Fail at the Data Layer: 9 Core Patterns](https://clonepartner.com/blog/blog/why-erp-migrations-fail-at-the-data-layer-9-core-patterns/).

## The Hidden Risk: Third-Party ISVs Are Already Dropping GP

Microsoft's sunset date is 2029, but the GP ecosystem is contracting faster than the official timeline suggests. The most immediate threat to your Dynamics GP environment is not Microsoft — it is the network of Independent Software Vendors (ISVs).

Dynamics GP is rarely used standalone. Most deployments rely on third-party integrations for AP automation, multi-entity management, advanced reporting, and document management. Because GP is built on **Dexterity** — an antiquated programming architecture from the 1990s — ISVs are actively shifting their engineering resources away from GP and toward modern platforms like Business Central, NetSuite, and Sage Intacct.

The clearest example: **BILL (formerly Bill.com) ended its direct sync with Dynamics GP effective December 1, 2023.** ([erpsoftwareblog.com](https://erpsoftwareblog.com/2024/03/bill-com-to-end-sync-support-for-dynamics-gp-dec-2023/)) BILL cited Microsoft's roadmap directly, noting that GP version 18.5 would be the last release with major new features. GP customers were downgraded to a flat-file batch integration — a significant step backward from the real-time sync they relied on for AP automation.

BILL's departure is a leading indicator, not an outlier. The pattern is predictable:

1. **ISV sees the Microsoft roadmap** and recognizes diminishing returns on GP integration maintenance.
2. **ISV shifts development resources** to Business Central, NetSuite, or Sage Intacct.
3. **GP integration enters maintenance mode**, then gets deprecated.
4. **GP customers discover the break** when an integration silently stops working or a critical update does not arrive.

Every GP customer should audit their ISV dependencies now. If you rely on third-party tools for AP automation, expense management, CRM sync, EDI, or warehouse management, check whether those vendors have published GP commitment timelines. If they have not, assume they are planning their exit.

## The 2029 Hard Deadline: Working Backward on Your Migration Timeline

The December 2029 deadline feels distant. It is not.

Most mid-market GP migrations take **9 to 18 months** from initial planning to go-live. That timeline breaks down roughly as follows:

| Phase | Duration |
|---|---|
| Evaluation, demos, vendor selection | 3–6 months |
| Data architecture, cleanup, implementation, and integration | 6–12 months |
| Parallel run, training, and post-go-live stabilization | 1–3 months |

For companies with complex operations — manufacturing, distribution, multi-entity structures, heavy customizations, or large ISV footprints — the total can stretch to **24 months or more** once data cleanup, ISV replacement, and process redesign are factored in.

Work backward from December 31, 2029:

- **If your migration will take 18 months**, you need to be in active implementation by **July 2028** — which means starting vendor evaluation by **early 2028**.
- **If your migration is complex (24+ months)**, active implementation must begin by **January 2028**, with planning starting in **mid-2027**.
- **If you have not started planning by Q1 2028**, you are at serious risk of missing the deadline or compressing your timeline into a dangerous rush.

The ideal scenario is going live on your new ERP at the start of a clean fiscal year — January 1, 2029 — to avoid migrating mid-year financial data. That means starting evaluation no later than mid-2027.

> [!TIP]
> **The real constraint is not just your timeline — it is partner availability.** As 2027 and 2028 approach, the best migration partners will fill their pipelines. Thousands of GP customers will be competing for the same implementation resources. Organizations that wait will face fewer options, higher costs, and less experienced teams. Starting evaluation now gives you the most flexibility.

For a structured pre-migration framework, see [The Ultimate ERP Data Migration Checklist (10-Point Plan)](https://clonepartner.com/blog/blog/the-ultimate-erp-data-migration-checklist-10-point-plan/).

## Why Standard GP Migration Tools Fail on Historical Data

Microsoft offers a **Cloud Migration Tool** built directly into Business Central. It connects to your GP SQL database, replicates data table by table, and handles standard master data and open transactions. The tool supports GP 2015 and later, requires SQL Server 2016 or later with database compatibility level 130+, and can migrate company data, master data, transactional data, vendor 1099 data, and historical data. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/faq-migrate-data))

For straightforward GP installations, it works. But most GP installations are not straightforward. Here is where the tool breaks down:

**Historical data lands in snapshot tables, not live BC tables.** GP historical transactions — paid invoices, closed POs, reconciled bank lines — are migrated into separate extension tables within Business Central. These tables are accessible through **GP Detail Snapshot** pages and reporting tools like Power BI, but they are not native BC transactions. You cannot drill into them from a customer card. You cannot use them in standard BC aging reports. For finance teams accustomed to pulling 10-year AP history from within GP, this is a significant workflow change.

**ISV and custom tables are not migrated.** The Cloud Migration Tool handles standard GP tables. Microsoft explicitly documents custom migration from any SQL source as a separate track and notes that the standard GP migration tools do not cover those custom migrations. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/cloud-migration-custom-migration)) If you run third-party modules — and most GP customers do — those ISV-specific tables (custom `.dic` files, extended pricing tables, undocumented SQL tables) are simply skipped. You need a separate extraction and mapping strategy for each ISV dataset.

**Account segment translation is lossy.** GP uses segmented account numbers (e.g., `100-200-300`). Business Central maps the main account segment and converts remaining segments into dimensions. Organizations with complex segment structures — intercompany codes, department trees, project segments — often find that the automatic mapping produces misaligned dimension values or pollutes the new chart of accounts with redundant entries requiring manual correction.

**Schema mismatches cause silent table failures.** The migration tool moves on to the next table if a schema mismatch is detected. Unless you actively monitor the migration log, you may not realize that a critical table was skipped until post-go-live reconciliation.

**Specific edge cases that catch teams off guard:**

- **GP Unit of Measure Schedules have no direct Business Central equivalent.** BC stores units of measure, not GP's schedule construct. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-dynamics-gp))
- **Undeposited cash receipts are not migrated.** They must be deposited in GP before migration.
- **Open purchase orders migrate by remaining quantity only.** Fully received and invoiced lines do not come over as open POs.
- **1099 amount migration starts with calendar year 2024.** If you need older 1099 reporting detail, plan for that explicitly.

**No support for data cleanup or deduplication.** The tool replicates what is in your GP database. If you have 20 years of accumulated vendor duplicates, orphaned transactions, or inconsistent coding, all of that lands in Business Central unchanged.

For a deep dive into migrating decades of GP financial history while preserving subledger integrity, see [Dynamics GP to Business Central: Migrating 20 Years of History](https://clonepartner.com/blog/blog/dynamics-gp-to-business-central-migrating-20-years-of-history/).

## How ClonePartner Handles the Hardest Part of Any GP Transition

The implementation partner configures Business Central. The change management team trains your users. But the part that keeps controllers and IT directors up at night is the **data** — decades of GL detail, paid vendor invoices, subledger links, custom ISV tables, and check images sitting in GP's SQL database.

That is where ClonePartner operates. We are not an implementation partner. We are a **data migration specialist** — an engineering team that builds custom scripts to extract, transform, and load your GP data into whatever target system you choose, whether that is Business Central, NetSuite, Sage Intacct, or Dynamics 365 Finance.

If your GP move is mostly standard setup and light master data, Microsoft's native tooling plus a good implementation partner may be enough. We are not interested in pretending every project needs custom engineering. Where teams need specialist help is the data layer: decades of history, custom SQL tables, ISV-owned entities, and a cutover plan that does not blow up month-end.

What that looks like in practice:

- **Custom ISV table extraction.** We reverse-engineer the schema of third-party modules your Cloud Migration Tool cannot touch — extended pricing, vertical-specific datasets, custom field stores — and map them into the target system's data model.
- **Historical data with relational integrity.** We do not dump history into snapshot tables and call it done. We preserve the links between GL entries, subledger transactions, and source documents so your auditors can trace any transaction from the new system back to its GP origin.
- **Zero-downtime cutover.** Your team keeps processing invoices, running payroll, and posting journal entries while we sync historical data in the background. A final delta sync over the cutover weekend ensures no transactions are lost.
- **Fixed-scope, fixed-fee execution.** We scope the work upfront and deliver at that price. No time-and-materials billing surprises.

With 1,500+ completed migrations, we have seen every edge case GP can throw — from 25-year-old Dexterity customizations to multi-entity configurations with intercompany eliminations spanning a dozen legal entities.

## Making the Call: Stay, Migrate, or Start Planning

Not every organization needs to migrate tomorrow. But every organization needs a plan.

**Migrate now (2026–2027)** if you are on GP 2016 (extended support ending July 2026), rely heavily on ISV integrations that may be deprecated, or have complex multi-entity structures that will take 18+ months to migrate.

**Plan now, migrate in 2028** if you are on Modern Lifecycle, have a relatively standard GP configuration, and want to align your migration with a natural business cycle — fiscal year-end or a post-busy-season window.

**What you should not do** is wait until 2029 and assume the migration can be compressed into a few months. ERP migrations routinely take longer than expected. Data cleanup alone can consume a quarter. And the partner market will be crowded with every other GP customer who also waited.

The 2029 deadline is not a suggestion. It is the date your tax tables freeze, your support tickets stop, and your compliance posture starts degrading. The organizations that come through cleanly will be the ones who started planning two to three years before the deadline — not two to three months.

> Planning a GP migration and worried about historical data, custom ISV tables, or zero-downtime cutover? Talk to our engineering team. We will scope your data migration, identify the hard problems, and give you a realistic timeline — no sales pitch, just technical guidance.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### When does Microsoft Dynamics GP end of life actually happen?

Dynamics GP product support — including enhancements, tax and regulatory updates, and technical support — ends December 31, 2029. Security patches continue on a limited, discretionary basis until April 30, 2031. After that, GP receives no updates of any kind. If you are on GP 2016, extended support ends earlier, on July 14, 2026.

### Will Dynamics GP stop working after 2029?

No, GP will not stop running. The software continues to function, but you lose all tax table updates, regulatory compliance patches, hotfixes, and Microsoft support tickets. Subscription and SPLA users must stop using GP entirely by April 30, 2031. Perpetual license holders can keep running the software at their own risk.

### What is the difference between Modern Lifecycle and Fixed Lifecycle for Dynamics GP?

Modern Lifecycle applies to GP 18.2 and later, offering continuous updates until December 2029 if you install at least one of three annual updates. Fixed Lifecycle applies to GP 2018 R2 and earlier, with hard end dates per version — for example, GP 2016 extended support ends July 14, 2026, and GP 2018 extended support ends January 11, 2028.

### How long does a Dynamics GP to Business Central migration take?

Most mid-market GP to Business Central migrations take 9 to 18 months from initial planning to go-live. Complex environments with heavy customizations, multi-entity structures, or large ISV footprints can take 24 months or more.

### Can the Microsoft Cloud Migration Tool move all my GP data to Business Central?

No. The Cloud Migration Tool handles standard GP tables and open transactions, but it places historical data in separate snapshot tables (not live BC records), does not migrate ISV or custom tables, and some GP structures like Unit of Measure Schedules have no direct BC equivalent. Organizations with third-party modules need a separate data extraction and mapping strategy.