Dynamics GP 2016 End of Support: July 2026 Risks & Migration Paths

Dynamics GP 2016 and GP 2016 R2 reach the end of extended support on July 14, 2026. After that date, Microsoft will not release security patches, hotfixes, or provide any form of technical support — even on a paid basis. (learn.microsoft.com)

If you are still running GP 2016, you have two options: upgrade to GP 18.x (which buys time until 2029/2031) or skip the intermediate upgrade and migrate directly to a cloud ERP. The practical question is not whether GP 2016 can keep running after July 14 — it can. The software will still launch, users can still post, and SQL will still answer queries. The real question is whether it makes sense to spend money on a multi-hop upgrade to hit another hard support wall in 2029, or to invest that budget in a direct migration to a new ERP.

This post breaks down the technical risks of staying, the real costs of each path, and why the "do nothing" strategy is far more dangerous than it appears.

For a broader view of Microsoft's on-premise sunset strategy, see The Ultimate 2026 Guide to Dynamics 365 On-Premise End of Life.

What Happens on July 14, 2026?

End of extended support means GP 2016 becomes a frozen, unsupported codebase. Under Microsoft's Fixed Lifecycle Policy, GP 2016 received a defined 10-year support window that closes permanently on this date. (learn.microsoft.com)

Here is what stops:

• Security patches — no fixes for newly discovered vulnerabilities, including SQL injection or privilege escalation bugs in GP's Dexterity runtime.
• Hotfixes — no break-fix support. If a stored procedure fails after a Windows update, Microsoft will not provide a fix.
• Paid support incidents — you cannot open a support ticket for GP 2016. Microsoft will tell you to upgrade.
• Third-party ISV support — Independent Software Vendors (ISVs) like Mekorma, eOne Solutions, and Greenshades align their support matrices with Microsoft's lifecycle. When Microsoft drops GP 2016, ISVs follow suit — refusing to troubleshoot issues or provide updates for their integrations on the platform. Mekorma's release notes confirm their active builds center on GP 18.6–18.8. (userguide.mekorma.com) Check your ISV vendor's support lifecycle page directly before assuming they will continue covering GP 2016 after July 14.

End of support is not retirement. Microsoft is not turning GP off. The risk is that when something breaks, exposes data, or falls out of compliance, you are no longer operating inside a vendor-supported remediation path. (learn.microsoft.com)

GP 2016 vs. GP 2016 R2

The title of this post covers both releases. In practice, GP 2016 and GP 2016 R2 share the same end-of-support date (July 14, 2026) and the same upgrade path. Microsoft's lifecycle page (learn.microsoft.com) lists them together under a single product entry. The R2 designation refers to a cumulative update release, not a distinct product version with a separate support timeline or upgrade chain. For upgrade and migration planning purposes, treat them identically. If you are uncertain which build you are on, check Help > About Microsoft Dynamics GP for the exact version string.

The Infrastructure Trap: SQL Server and Windows Server Compatibility

The risk with GP 2016 is not just the application layer. It is the entire infrastructure stack underneath it.

GP 2016 supports only three SQL Server versions and a limited set of Windows Server versions. You cannot install GP 2016 on newer platforms — GP Utilities performs a version compatibility check at startup and will refuse to run on unsupported SQL versions. There is no workaround. (learn.microsoft.com)

On the Windows side: Windows Server 2012/R2 ended support on October 10, 2023. Windows Server 2016 ends support on January 12, 2027. GP 2016 is only supported on Windows Server 2012, 2012 R2, and 2016 — not Windows Server 2019 or 2022. (learn.microsoft.com)

The practical impact: most GP 2016 installations are sitting on SQL Server 2012 or 2014 databases that are already beyond standard support. Running an unpatched SQL Server is not an abstract risk. Ransomware operators specifically target known SQL Server vulnerabilities in unpatched instances. Cyber insurance carriers are increasingly excluding coverage for organizations running end-of-life database software. If your GP 2016 instance is on SQL 2012 and you get hit, you may find your insurer will not pay the claim.

Start by inventorying what you actually run:

SELECT @@VERSION AS sql_version;
 
SELECT name, compatibility_level
FROM sys.databases
WHERE name IN ('DYNAMICS', '<companydb>');

If your source database sits below compatibility level 130, the standard Business Central cloud migration tooling will reject it. (learn.microsoft.com)

Some teams try to answer the infrastructure problem with Extended Security Updates (ESU) for Windows or SQL. Microsoft explicitly describes ESU as a last-resort bridge, not a long-term strategy, and it does not restore normal troubleshooting, bug-fix work, or broad technical support. Even if you buy ESUs for the OS or database, you still have not put GP 2016 itself back into support. (learn.microsoft.com)

Option 1: Upgrade to GP 18.x (The Band-Aid)

Upgrading to the current GP 18.x line moves you from the Fixed Lifecycle to Microsoft's Modern Lifecycle Policy. Under Modern Lifecycle, you receive continuous support — including tax updates, hotfixes, and security patches — as long as you install at least one of the three annual updates released each year. (learn.microsoft.com)

The timeline under Modern Lifecycle:

This buys you roughly 3.5 years of full support from mid-2026, plus another 16 months of security-only patches. That is real runway — but it comes with costs that most partners do not surface upfront.

The hidden costs of the GP upgrade path

Multi-hop upgrades. A multi-hop upgrade is an upgrade path that requires passing through one or more intermediate versions because no direct path exists from the source to the target. You cannot jump directly from GP 2016 to GP 18.x. Microsoft's own upgrade guide confirms there is no direct upgrade path from GP 2016 to the current release. (learn.microsoft.com) The typical route is GP 2016 → GP 2018 → GP 18.5+, with each hop requiring a GP Utilities pass, full SQL backups, module-by-module testing, Dexterity dictionary version checks, and ISV compatibility verification. This is not a weekend project; it requires weeks of billable consulting hours and significant system downtime.

SQL Server upgrade. GP 18.7 (October 2024 release) requires SQL Server 2017 or later (learn.microsoft.com). Your SQL 2012 or 2014 database must be migrated to SQL 2019 or 2022 before the GP upgrade can proceed. This is a separate project with its own backup, restore, compatibility-level, and testing requirements.

ISV and customization rework. Dexterity customizations, modified reports, and third-party ISV products that worked on GP 2016 may not be compatible with GP 18.x. ISV vendors like Mekorma center their active builds on GP 18.6–18.8. (userguide.mekorma.com) Some ISVs have already dropped support for older GP versions entirely, shifting to Business Central. That is what vendor attrition looks like in practice: the system may still launch, but the ecosystem stops meeting you where you are.

The 2029 wall. Even after spending on a full GP upgrade — and costs vary significantly based on user count, ISV product count, and customization depth — you hit the same end-of-life wall in December 2029. Microsoft has also ended new GP subscription license sales as of April 1, 2026. GP support ends on December 31, 2029, with security patches ending April 30, 2031. There is no further extension. GP is a terminal product.

When the upgrade makes sense

Despite the costs, upgrading to GP 18.x can be the right short-term move when:

• You need to stay on GP for regulatory or contractual reasons and cannot start an ERP migration before July 2026.
• Your customization depth is low — fewer than 10 modified reports, no Dexterity customizations, minimal ISV products — keeping upgrade costs manageable.
• You are already planning a cloud ERP migration for 2027–2028 and need GP to remain supported during the transition.

If you fit any of these, the upgrade is not wasted — it is a bridge. Just make sure the bridge leads somewhere, not to another dead end. Ask the uncomfortable question early: does funding two projects — GP modernization now, ERP migration later — actually cost less than one well-scoped exit? In many cases, it does not.

Option 2: Skip the Upgrade — Migrate Directly to a Cloud ERP

For organizations willing to commit to a longer project, the financially sound strategy is often to skip the GP 18.x upgrade entirely and migrate directly to a modern ERP. The most common targets for GP shops:

• Dynamics 365 Business Central — Microsoft's designated successor. Dimension-based architecture replaces GP's segment-based chart of accounts. Cloud-native, evergreen updates, no more version upgrades.
• Dynamics 365 Finance & Operations — for larger organizations (100+ users) with complex manufacturing, multi-entity, or supply chain requirements.
• NetSuite, Sage Intacct, or Acumatica — non-Microsoft alternatives that may be a better fit depending on industry vertical and functional requirements.

The SQL Server 2016 SP1 problem

GP 2016 users hit a technical wall that most migration guides gloss over.

Microsoft's official Cloud Migration Tool — the built-in wizard for moving GP data into Business Central — has a hard prerequisite: the source database must be running on SQL Server 2016 SP1 or later with a compatibility level of 130 or higher. The tool supports Dynamics GP 2015 and later at the application layer, but the SQL Server requirement is the real gate. (learn.microsoft.com)

If your GP 2016 database is on SQL Server 2012 or 2014, the Cloud Migration Tool will not connect. This creates a catch-22:

1. You cannot use the standard migration tool without upgrading SQL Server.
2. Upgrading SQL Server to 2016+ means GP 2016 may stop working — GP Utilities blocks unsupported SQL versions.
3. To make a newer SQL version work with GP, you would need to upgrade GP first — which is the exact multi-hop upgrade you were trying to avoid.

The backup-based workaround. Microsoft now allows you to restore a GP backup to SQL Server 2022 Developer Edition and run the migration project from there. In this approach, you restore the production GP database backup to a Developer Edition instance (which has no runtime licensing cost), set the compatibility level to 130, and run the Cloud Migration Tool against that restored copy rather than the live production server. This eliminates production risk during the migration run, but it does not remove the functional limits of the standard migration engine — it only resolves the SQL version prerequisite. For live, ongoing migrations, Microsoft is explicit: if your production GP database is on SQL Server 2014 or earlier, you need a database upgrade before you start. (learn.microsoft.com)

Regional and storage limits. The GP cloud migration assisted setup is currently supported only for the United States, Canada, the United Kingdom, and Australia. Microsoft recommends keeping individual migration runs under 30 GB. Business Central online tenants receive a default storage allowance, but heavy GP estates — typically those with more than 15–20 years of unarchived transaction history across multiple companies — frequently exceed this threshold and require data tiering decisions before migration begins. (learn.microsoft.com)

Microsoft's Business Central 2026 wave 1 plan added a generic framework for reusable custom migrations from any SQL database, delivered through the same cloud migration infrastructure. Even Microsoft is acknowledging that legacy ERP exits do not always fit the standard GP adapter. (learn.microsoft.com)

The Historical Data Dilemma: Avoiding the Read-Only Server

Even when you solve the SQL version problem, the Cloud Migration Tool has an architectural limitation that matters for audit and compliance: it does not migrate detailed historical GL transactions into the live Business Central ledger.

The tool migrates summary GL balances by fiscal period for open and historical years. Historical fiscal years come into Business Central as open years that must be closed in BC. Detailed transaction history — the individual journal entries, invoice line items, and payment apply records from tables like GL30000 (Account Transaction History) — is pushed to extension tables accessible through "GP Detail Snapshot" list pages. These extension tables are not part of the live GL. They can be surfaced through Power BI, Power Apps, or third-party reporting tools, but they cannot be queried natively within standard Business Central reports. (learn.microsoft.com)

What the Cloud Migration Tool covers by GP module

The coverage gap varies by GP module. The table below summarizes what the standard tool migrates, what goes to extension tables, and what requires custom extraction:

Payroll history is not migrated by the Cloud Migration Tool at all. If your organization needs payroll history for compliance, tax audit, or reference purposes, plan a custom extraction path before decommissioning GP.

For a detailed breakdown of how to tier GP historical data during a Business Central migration, see Dynamics GP to Business Central: Migrating 20 Years of History.

The read-only server anti-pattern

The common workaround is to keep a legacy GP instance running in read-only mode for historical lookups. On paper, this sounds reasonable. In practice, you are maintaining a vulnerable, unpatched SQL Server 2012 or 2014 instance on your network purely to serve as an archive. That instance:

• Needs to be patched, backed up, and monitored — but cannot receive security updates from Microsoft.
• Must remain network-accessible for finance to query, expanding your attack surface.
• Requires GP client licenses and Dexterity runtime support that becomes harder to source every year.
• Creates audit complexity — auditors now need to verify data across two systems.
• Violates PCI-DSS, HIPAA, and standard SOC 2 compliance requirements by keeping unpatched infrastructure on the network.

For regulated industries — healthcare (HIPAA), financial services (SOC 2 Type II), and government contractors (FedRAMP) — the compliance exposure is not theoretical. Each of these frameworks requires that systems storing or processing covered data operate within vendor-supported configurations. A GP read-only server on SQL Server 2012 is not a vendor-supported configuration after July 14, 2026. Whether that constitutes a control failure depends on your specific audit scope, but it is a defensible finding for any assessor reviewing your infrastructure.

Every year the read-only server stays alive, it gets more expensive and more dangerous. A better approach:

• Migrate the history that finance and auditors actually query into the target ERP at the line-item level.
• Extract long-tail legacy history into an immutable archive or reporting store with documented lineage.
• Decommission the GP application and keep only the minimum evidence set required for audit and reference.

Leaving data behind in silos is one of the primary reasons system transitions fail. For the full failure taxonomy, see Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

Decision Framework: Upgrade vs. Migrate

The right path depends on three variables: timeline pressure, customization depth, and how much GP lifespan you are willing to pay for.

The decision branches as follows:

• If your customization count is under 10 modified reports and no Dexterity customizations — the upgrade is likely cheap enough to justify as a bridge, especially if you need to stay on GP for regulatory or contractual reasons and cannot start an ERP migration before July 2026.
• If your customization count is high, or your ISV stack includes products that have already shifted to Business Central — the cost of the multi-hop upgrade plus ISV rework will erode the financial case for the upgrade quickly. Model the full cost of the upgrade path (including SQL Server upgrade and post-upgrade ISV licensing) against the cost of starting a cloud ERP evaluation now.
• If you are on subscription or SPLA licensing — Microsoft will terminate subscription billing and SPLA usage on April 30, 2031. You will be forced off GP regardless.
• Company size matters less than customization depth. A smaller company with 18 years of custom GP logic can be harder to move than a larger company using core finance.

If the upgrade cost approaches or exceeds the cost of starting a cloud ERP migration, redirect that budget. The upgrade cost is entirely sunk — you cannot recover it when you migrate in 2028 or 2029.

What to Do Before July 14

If you have not started planning, here is the minimum viable action list:

1. Inventory your SQL Server version. Run SELECT @@VERSION on your GP database server. If it returns SQL 2012 or 2014, you have a security problem today, independent of GP.
2. Audit your ISV and customization footprint. List every Dexterity customization, modified report, and third-party product running against your GP database. This list determines your upgrade cost and migration complexity.
3. Check your ISV support status directly. Do not assume your ISV will support GP 2016 after July 14. Visit each vendor's lifecycle or release notes page and confirm their stated GP version support window.
4. Decide: bridge or migrate. Model the full cost of the upgrade path — including SQL Server upgrade, GP upgrade, ISV rework, and post-upgrade licensing — against the cost of starting a cloud ERP evaluation now. If the numbers are close, the cloud path has more strategic value.
5. Get your data out. Regardless of which path you choose, your GP data needs to be extractable. Start with a clean, tested backup of your GP SQL databases stored somewhere you control.

The hard part is rarely the installer. It is the data model, the history, and the cutover plan. The worst action you can take is a reactive upgrade that treats data migration as an afterthought.

How ClonePartner Approaches GP 2016 Data Extraction

Organizations that extract directly from the GP SQL schema — without requiring a version upgrade as an intermediate step — can avoid the multi-hop cost structure entirely. Instead of layering three projects (SQL upgrade → GP upgrade → migration tool), the data is extracted at the source, mapped to the target ERP's structure, and validated against source totals before cutover.

This approach covers:

• Full line-item historical data — not just summary balances. GL detail, AP/AR transaction history, inventory movements, and SOP/POP records at the line-item level, mapped into the target ERP's structure.
• Direct chart of accounts translation — GP's segment-based account structure mapped to Business Central's dimension-based model (or NetSuite's subsidiary/class/department model, or Sage Intacct's dimension hierarchy) before data lands in the target. Historical GP segments map accurately to the new dimensional structure, so a transaction from 2018 reports natively inside the target system with unbroken year-over-year reporting.
• Documented data lineage — the legacy GP server can be decommissioned once data is extracted and validated against source totals, with a documented chain-of-custody from old system to new for audit purposes.

Microsoft's own 2026 Business Central roadmap now supports reusable custom SQL migration engines — which is exactly the direction serious legacy exits require.

For a deeper look at how execution-focused migration differs from advisory-heavy approaches, see Why "Standard" Partners Fail at Data Integrity.