Dynamics GP End of Support 2029: What Happens to Your Data

Dynamics GP won't stop working on January 1, 2030. Your SQL databases will still hold every GL entry, every paid invoice, every payroll run you've ever processed. But the environment those databases depend on — the SQL Server engine, the Windows Server OS, the security patches that keep auditors satisfied — will be decaying underneath them.

That's the real risk. Not a sudden shutdown, but a slow infrastructure collapse that makes your historical financial data progressively harder and more expensive to access.

If you're a CFO or controller running GP today, the question isn't "when do I pick a new ERP." It's "how do I guarantee that 10–20 years of financial history remains accessible, auditable, and compliant — whether or not GP is running."

When you finally transition off GP, the primary challenge won't be configuring your new chart of accounts. It will be extracting 15 to 20 years of historical transactions, open AR/AP, fixed asset records, and payroll history without corrupting the audit trail. This guide breaks down the exact timeline of the GP sunset, the infrastructure decay making your current environment fragile, and the data extraction strategies required to retire your legacy SQL servers permanently.

For a deeper look at the full GP-to-Business-Central migration path, see Dynamics GP to Business Central: Migrating 20 Years of History.

The 2029 Dynamics GP End of Support Timeline

Microsoft is executing a phased retirement for Dynamics GP. The distinction between "no longer selling" and "unsupported" is critical for financial planning.

Dynamics GP product support and updates will end on December 31, 2029. Previously, it was announced that support would end on September 30, 2029, with security patches continuing until April 30, 2031. The end date for security patches remains unchanged.

Here are the dates that matter for data planning:

Date	What happens	Impact on operations
April 1, 2025	End of new perpetual license sales	New customers cannot buy perpetual licenses
April 1, 2026	End of new subscription license sales	GP is restricted to existing licensed users; can't add users
December 31, 2029	End of product enhancements, regulatory/tax updates, technical support	The breaking point. Payroll tax tables freeze; 1099/W-2 forms stop updating
April 30, 2031	End of security patches; service plans end; subscriptions stop renewing; SPLA usage ends	GP SQL databases become unpatched targets; complete end of Microsoft involvement

These dates come from Microsoft's lifecycle page and its product-availability announcements. (learn.microsoft.com)

After December 31, 2029: GP will no longer receive annual payroll updates, state tax table releases, or compliance patches. That's the line that matters most to controllers. Your payroll team can't manually compute every state withholding change. Your AP team can't hand-build updated 1099 forms. The data in GP remains intact, but the system's ability to process compliant transactions ends.

For most businesses, December 31, 2029 is the functional death of the system. You can technically run the software past that date, but it will no longer produce legally compliant financial outputs without manual intervention.

The Silent Decay Problem: Infrastructure Fails Before the ERP Does

Dynamics GP does not exist in a vacuum. It requires a specific stack: Windows Server, SQL Server, and a network architecture designed for on-premise client-server applications. While GP itself has a 2029 deadline, the servers it runs on have earlier deadlines that are already hitting.

SQL Server 2016 is the most common database engine in mid-market GP environments. Microsoft SQL Server 2016 reaches end of extended support on 14 July 2026. After this date, Microsoft will no longer provide security patches, bug fixes, or technical support.

That's not 2029. That's July 2026.

Windows Server 2016 is next. Extended support for Windows Server 2016 will end on January 12, 2027.

Here's the cascade:

Component	End of support	What breaks
SQL Server 2016	July 14, 2026	No security patches; audit findings; cyber insurance gaps
Windows Server 2016	January 12, 2027	Same risks at the OS layer
Dynamics GP	December 31, 2029	No tax/regulatory updates; no Microsoft support
GP security patches	April 30, 2031	Complete end of all Microsoft involvement

GP's own system requirements accelerate this squeeze. Dynamics GP 18.5 no longer supports SQL Server 2014, which means organizations on older GP versions already had to upgrade their SQL Server just to stay current on GP patches. GP 18.7 and later drops SQL Server 2016 entirely. (learn.microsoft.com) If you want to apply the latest GP update to get your year-end tax tables, you're forced to upgrade your underlying database server to SQL Server 2019 or 2022.

Compatibility issues emerge as other systems continue to update. Vendors gradually stop certifying their applications on the old database engine. Auditors start flagging your environment as noncompliant even if you haven't had an incident yet.

The practical result: even if you plan to run GP until 2029, you'll need to upgrade SQL Server and Windows Server before then just to keep the lights on. Each of those upgrades costs money, requires testing, and carries risk — all to maintain a system you're planning to leave.

As network security requirements tighten — especially for companies carrying cyber liability insurance — running older versions of Windows Server or SQL Server becomes an uninsurable risk. The cost of isolating legacy VMs, managing custom firewall rules, and paying for extended security updates often exceeds the cost of a data extraction project.

Microsoft's own Business Central migration FAQ makes the squeeze even clearer: the on-premises source must use SQL Server 2016 SP1 or later and database compatibility level 130 or higher to use the built-in migration tools. A GP shop still parked on SQL 2014 or 2012 has prerequisite work just to reach the official exit ramp, while SQL 2016 itself ages out in July 2026 and GP 18.7 no longer supports it. That is silent decay in action. (learn.microsoft.com)

The 7-to-10-Year Trap: Data Retention Meets Platform Decay

Financial compliance laws don't care about Microsoft's product lifecycle. Depending on your industry, the records you're generating in GP today must remain accessible for years — possibly a decade — after GP loses support.

The specific requirements vary by record type and jurisdiction:

• The IRS requires employment tax records for at least four years. (irs.gov)
• Accounts payable and receivable records need seven years of storage to satisfy IRS audit requirements.
• PCAOB standards require audit documentation to be maintained for at least seven years. (pcaobus.org)
• SOX mandates financial records retention for at least 7 years.
• If invoices include Protected Health Information, HIPAA rules apply — often requiring 6–10 years of secure retention.
• The IRS allows ten years for certain foreign tax credit refund claims. (irs.gov)

Do the math: A transaction posted in GP today — mid-2026 — needs to remain accessible until at least 2033, and potentially 2036 under healthcare or state-level requirements. A transaction posted in December 2029 (GP's last supported month) needs to survive until at least 2036–2039.

By 2036, Dynamics GP will have been entirely unsupported for five years. SQL Server 2016 will have been unsupported for a decade. Attempting to spin up a Windows Server VM in 2036 just to open the GP client and view an old PM30200 (Historical Payables) record is a technical nightmare.

Auditors should be able to retrieve historical records directly without reactivating retired applications or databases. That's the standard your archive strategy needs to meet. "We can spin up the old server if we need to" is not an audit-ready answer. A backup is retention. It is not accessibility. If your team needs a retired GP app server, an old SQL instance, and a former admin to answer an audit question, your archive is not operationally sound.

What GP Data Needs Retention

Your data must survive the death of the application that created it. Here's what sits in a typical GP environment and how each category maps to a retention plan:

• General Ledger. GL detail and summary by period (GL20000 for open years, GL30000 for historical years). This is the backbone of every audit and the first thing an examiner will request.
• Open and historical AR/AP. Microsoft's cloud migration brings over outstanding receivables and payables using the remaining amount on the document, but closed historical transactions need separate extraction. (learn.microsoft.com)
• Fixed assets. Microsoft's published GP-to-Business Central migration scope and GP Historical Snapshot lists do not include Fixed Assets. Depreciation schedules, books, and disposal history need a separate extraction plan. (learn.microsoft.com)
• Payroll history. Payroll is also absent from the documented GP-to-BC migration scope. Employee wage history, tax withholdings, and year-end W-2/T4 files should be treated as their own retention workstream. (learn.microsoft.com)
• Bank reconciliation history. Needed to tie cleared transactions back to GL entries — often requested during audits that span multiple periods.
• Custom report data. Standard migration only moves tables that exist in both source and target. SmartLists, SQL views, SSRS datasets, Extender windows, and third-party ISV tables all need deliberate treatment.
• 1099 data. GP 1099 amounts can migrate to Business Central, but the first supported year for 1099 information is 2024. If your retention requirements go further back, you need a parallel archive plan. (learn.microsoft.com)

The takeaway: your data must be extracted from GP's proprietary database structure into an immutable, application-agnostic format. For a detailed walkthrough of compliance requirements during financial data moves, see Accounting Data Migration Checklist: The 10-Point Plan.

Three Strategies for Dynamics GP Historical Data

Every GP customer will land on one of three approaches. Each has real trade-offs.

Strategy 1: Full Migration to a New ERP

What it means: Move everything — master data, open transactions, and years of historical detail — into Dynamics 365 Business Central, NetSuite, Sage Intacct, or another target ERP.

This is almost always a mistake for organizations with deep history.

Your Dynamics GP history is important for your users, but a good consultant will not recommend moving all your history into your new ERP environment. This is mainly because every transaction you move needs to be brought in unposted and re-posted down to the cent. 20 years of history would require a really expensive effort to map and move the data.

Modern cloud ERPs are optimized transactional engines, not cheap filing cabinets. Moving decades of history requires mapping unposted transactions, reconciling historical subledgers to the general ledger, and forcing old, dirty data into strict new dimension structures. It bloats cloud storage costs and degrades system performance.

The technical gotchas compound quickly. Years marked as historical in GP come into Business Central as open and must be closed there. Undeposited cash receipts are not migrated. GP's Unit of Measure Schedule table has no direct equivalent in Business Central. These are small examples of a bigger truth: a GP-to-cloud move is a structural translation, not a database restore. (learn.microsoft.com)

There's also a scale problem. Microsoft's own implementation guidance recommends keeping Business Central migration runs to less than 30 GB, with a default database capacity of 80 GB plus a per-user allowance. (learn.microsoft.com) Forcing 15 or 20 years of low-value history into the new ERP means paying for it twice: once during migration, and again every time users search, report, or reconcile.

When it makes sense: Companies with 3–5 years of history, a simple chart of accounts, and minimal customization. Also works when the new ERP will genuinely use the historical data for trending, forecasting, or operational reporting.

When it doesn't: 15–20 years of history, multiple GP companies, heavy use of Extender or ISV modules. The cost and risk of mapping every historical dimension, re-posting every closed transaction, and validating every penny outweighs the benefit.

Typical cost range: $50K–$250K+ for the data migration component alone, depending on volume and complexity. This doesn't include ERP implementation.

For common failure patterns in this approach, see Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

Strategy 2: Selective Migration + GP Archive

What it means: Migrate only active/open data (master records, open AR/AP, current-year GL) to the new ERP. Keep GP running on a maintained SQL Server for historical lookups.

This keeps implementation costs low, but it completely ignores the silent decay problem. You're still paying for SQL Server licensing. You're still maintaining a vulnerable Windows Server environment. You're still failing modern IT security audits by keeping deprecated software on your network.

Hidden cost: SQL Server licensing alone can run $3,700+ per two-core pack for Standard Edition. Add Windows Server CALs, backup infrastructure, and the IT labor to maintain an environment nobody actively uses, and you're looking at $10K–$30K/year to keep a read-only archive alive.

When it makes sense: Smaller organizations where the cost of maintaining a SQL Server for a few more years is genuinely cheaper than a full historical extraction, and where the compliance window is short.

When it doesn't: Every year you delay, the cost of maintaining that archive server rises as the infrastructure around it loses support. You haven't retired GP. You've just moved it to a quieter server.

Strategy 3: Data Extraction to a Data Warehouse or Azure Data Lake

What it means: Extract the full GP SQL database — every table, every relationship, every attachment — into Azure Data Lake Storage, a data warehouse, or another cloud-based storage layer. Then retire the on-premises server entirely.

You can create a copy of the Dynamics GP database in Azure Data Lake so that you have it for future reference after the migration to Business Central online. A customer isn't required to copy their database to Azure Data Lake. But there are several benefits to being able to do so, including having access to the historical data that isn't migrated by the migration tool.

This is the strategy that fully decouples your historical data from the dying GP infrastructure. You migrate only active data to your new ERP. Then you extract the entirety of your GP SQL database — every historical GL entry (GL30000), every paid payable (PM30200), every old sales order (SOP30200) — into a secure cloud store.

The benefits:

• Infrastructure retirement. You can permanently decommission the GP application server and SQL server, eliminating licensing and infrastructure maintenance.
• Cost efficiency. With tools like the Popdock Data Upload Tool, you can bring your data storage costs down to an average of $10–$50/month — a fraction of what it costs to run an Enterprise SQL Server VM.
• Accessibility. Using Power BI or Popdock, your finance team can build reports to query historical GP data directly from the data lake, often embedding those views into the interface of your new ERP.
• Immutability. The extracted data is read-only, satisfying strict auditor requirements for chain-of-custody and historical preservation.

When it needs help: The extraction itself is the hard part. GP's SQL schema is not self-documenting. Table names like PM20000, RM20101, and GL20000 don't tell you what they contain without a Dexterity data dictionary. Relational integrity between modules — tying an AP payment to its GL distribution to its bank reconciliation entry — requires deep GP domain knowledge to extract correctly. Raw extracts without that context are not a finance-grade archive. If you can't tie AR/AP documents back to GL impact, preserve apply history, store lookup tables, and show lineage from source table to archive view, auditors won't care that the data technically exists.

Evaluating Dynamics GP Migration and Archival Tools

The tooling landscape for GP data extraction is narrower than you'd expect. The key distinction is between transport (moving data from point A to point B) and retention design (structuring the data so it remains auditable and useful without the original application). Most tools handle transport. Few handle retention design.

GP is built on Dexterity, meaning its SQL tables are highly fragmented. A single sales transaction might span five different tables depending on whether it's unposted, posted, or moved to history. Here's an honest assessment of the available tools.

Microsoft Cloud Migration Tool (Free)

In general, the cloud migration tool migrates the following data: System and company setup, such as payment terms, shipping method, and sites. It also brings over master data (accounts, customers, vendors, items), open transactions, GL summary/detail, and an optional GP Historical Snapshot covering GL detail, receivables, payables, sales order processing, purchase receipts, and inventory. The tool uses Azure Data Factory and a self-hosted integration runtime, keeping the on-prem system operative until migration is complete. (learn.microsoft.com)

Limitations:

• Microsoft's Cloud Migration Tool handles data replication, but it does not fix "dirty data," map complex customizations, or train your staff.
• The migration wizard can only be used with GP versions 2015 or later. If you're using an older version, you'll need to upgrade to GP 2015 first.
• The SQL Server database must use SQL Server 2016 SP1 or later. Compatibility level set to 130 or higher.
• Does not migrate full closed transaction history beyond the Historical Snapshot scope. Not an archival extraction tool.
• Does not handle Extender data, ISV tables, or custom SQL views.
• Fixed assets and payroll are not in the documented migration scope.

eOne Solutions Popdock (Commercial)

Popdock positions as a reporting and data lake management layer. When you are no longer using GP and everything has been migrated, you can archive it and turn off your SQL Server. Popdock can embed historical GP data within Business Central's interface, creating a unified lookup experience for end users. eOne's Data Lake Upload Tool can copy SmartLists, tables, views, and attachments into Azure Data Lake or Amazon S3. (eonesolutions.com)

Limitations: Requires its own licensing. Best suited for organizations already committed to Business Central. The data lake upload is a flat extraction — it moves tables and SmartLists, not a fully normalized relational archive with enforced referential integrity. You still need a reliable mechanism to extract the data from your on-premise SQL server in a way that preserves the financial relationships between modules.

KingswaySoft SSIS Integration Toolkit (Developer Tool)

Provides SSIS components for reading from and writing to GP's SQL database. Gives developers fine-grained control over extraction logic — direct database connectivity, custom queries, source and destination components, bulk inserts, and a no-code SSIS design surface. (kingswaysoft.com)

Limitations: Requires SSIS expertise your team may not have. Building and maintaining custom SSIS packages for a full GP extraction is a significant development effort — typically 80–200 hours for a complex environment. If the engineer who built it leaves the company, you're left with complex, undocumented ETL scripts that become a new legacy system in their own right. For a detailed comparison of SSIS-based approaches, see Migrating Dynamics 365 On-Premise to Cloud: Escaping the SSIS Bottleneck.

Professional Advantage Company Data Archive (Utility)

This ISV tool moves historical data from your live GP company database into an archive GP company database, improving performance on the production instance, backups, and upgrades. (professionaladvantage.com)

Limitations: You're still running GP. You're still running SQL Server. This is a performance optimization tool, not a platform exit strategy. It doesn't solve the 2029 problem — the data remains trapped inside GP, and the infrastructure decay problem moves to a quieter server.

How ClonePartner Handles GP Data Extraction

We treat the Dynamics GP 2029 sunset as a data preservation event, not a software upgrade. Whether you're migrating to Business Central, NetSuite, or moving history to an Azure Data Lake, the integrity of your financial data depends entirely on the extraction process.

Our approach is different from the tools above because we're not a product — we're an engineering team that writes custom extraction scripts tailored to your specific GP schema. Here's what that means in practice:

Direct SQL extraction with relational integrity. We work directly against your GP SQL databases, mapping the Dexterity table structure to extract every module — GL, AR, AP, payroll, fixed assets, bank rec, inventory — with the cross-references intact. When your auditor asks "show me the GL entries for this AP payment," the data lake returns the complete chain. We handle the complex mapping of GP's GL20000 (Open Year) and GL30000 (Historical Year) tables, ensuring they're merged, reconciled, and cleanly extracted. We capture custom fields, third-party ISV data (Binary Stream, Mekorma, and others), and multi-entity configurations that standard adapters ignore.

Preservation of audit trails. Every extraction includes a reconciliation report: source record counts, destination record counts, hash validation on financial totals. We document the chain of custody from GP to the target — exactly what SOX and external auditors require.

Zero downtime. We extract from a backup or read-only replica of your production SQL database. Your finance team keeps processing transactions throughout the extraction. No freeze windows, no weekend cutovers for the archive phase.

Target-agnostic. Whether your new ERP is Business Central, NetSuite, Sage Intacct, or something else — and whether your archive target is Azure Data Lake, Snowflake, Azure SQL, or flat Parquet files — we deliver the extracted data in the format your destination requires.

This matters because your ERP decision and your data preservation decision are separate problems. You shouldn't be forced to choose Business Central just because that's what the Microsoft migration tool supports, and you shouldn't lose historical data access just because your new ERP can't hold 20 years of closed transactions.

Building Your GP Data Exit Timeline

The infrastructure deadlines create a natural sequencing:

1. Now through Q4 2026: Inventory your GP SQL databases. Document every company, every module in use, every ISV/Extender table. Identify which SQL Server and Windows Server versions you're running. If you're on SQL Server 2016, that upgrade deadline is already here.

2. 2027: Begin ERP evaluation if you haven't already. On average, it takes 9–18 months from the decision to move off Microsoft GP to go-live. A 2027 start gives you a 2028–2029 go-live, right on the deadline.

3. 12–18 months before go-live: Execute the historical data extraction. This should happen before your ERP cutover, not after. You want the archive validated and accessible before you turn off GP.

4. At go-live: Selectively migrate active data to the new ERP. Retire GP. Retire the on-prem SQL Server. Historical access comes from the data lake or archive, not from a server you need to keep alive.

What to Do This Quarter

You don't need to pick an ERP today. You don't need to start a migration project today. But you do need to answer three questions:

1. What SQL Server and Windows Server versions is GP running on? If the answer is 2016, you have an infrastructure problem that predates the 2029 GP deadline.

2. How many years of history live in your GP databases? If it's more than 7 years, you have data that needs to be accessible for compliance purposes well past 2029.

3. Who owns the data extraction plan? Not the ERP implementation — the data extraction. These are different workstreams with different skill sets, and conflating them is how organizations lose historical data during transitions.

A good GP exit plan produces five concrete outputs: a module-by-module data inventory, an active-versus-historical scope decision, an extraction that preserves document relationships and audit trails, a reconciliation pack with row counts and control totals, and a read-only delivery layer finance can actually use.

The right question is not "How long can we keep GP running?" It's "What GP data must still be explainable after GP is gone?" Once you answer that, the migration strategy gets much clearer.

For the full ERP data migration framework, start with The Ultimate ERP Data Migration Checklist.