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.

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)

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 SELECT @@VERSION 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. 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. 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. (learn.microsoft.com)

SQL Server upgrade. GP 18.7 (October 2024 release) requires SQL Server 2017 or later. 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 $50K–$150K on a full GP upgrade — a realistic range for a mid-market company with 10–50 users, ISV products, and customizations — 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 under $30K.
• 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. For one-time data extractions, Microsoft now allows you to restore a GP backup to SQL Server 2022 Developer Edition and run the migration project from there. This reduces production risk but does not remove the functional limits of the standard migration engine. For live 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. Business Central online tenants get a default 80 GB plus per-user storage allowance, and Microsoft recommends keeping individual migration runs under 30 GB. Heavy GP estates with decades of history need design work, not just an adapter. (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)

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.

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.

If your total upgrade cost exceeds $75K, you are almost certainly better off putting that money toward a cloud ERP migration. The upgrade cost is entirely sunk — you cannot recover it when you migrate in 2028 or 2029.

If your customization count is under 10 modified reports and no Dexterity customizations, the upgrade is cheap enough to justify as a bridge.

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.

How ClonePartner Migrates GP 2016 Data Without the Multi-Hop Upgrade

The standard partner playbook for GP 2016 users looks like this: upgrade GP to 18.x → upgrade SQL Server → run the Cloud Migration Tool → deal with whatever the tool does not handle. That is three projects layered on top of each other, each with its own risk surface.

ClonePartner takes a different approach. We extract data directly from the legacy SQL Server database — whether it is SQL 2012, 2014, or 2016 — using custom scripts that query GP's table structure directly. No GP version upgrade required. No SQL Server upgrade as a prerequisite.

What this means in practice:

• Full line-item historical data — not just summary balances. We extract GL detail, AP/AR transaction history, inventory movements, and SOP/POP records at the line-item level and map them into the target ERP's structure.
• Direct chart of accounts translation — GP's segment-based account structure is 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. Custom mapping scripts parse historical GP segments and map them accurately to the new dimensional structure, so a transaction from 2018 can be reported on natively inside the target system with unbroken year-over-year reporting.
• No read-only server left behind — once the data is extracted and validated against source totals, the legacy GP server can be decommissioned. Your auditors get a documented chain-of-custody from old system to new.

If a traditional partner's answer is "upgrade GP first because the standard adapter requires it," that is often a delivery-model limitation, not a technical requirement. 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.

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. Decide: bridge or migrate. If you can upgrade for under $30K and need more time, the bridge is defensible. If the number is higher, redirect that budget toward a cloud ERP evaluation.
4. 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.