Systems and records
Dynamics GP end of life: what to do with decades of GP history
By SourceX Editorial · Updated
Short answer
Dynamics GP end of life means Microsoft is retiring GP on a published timeline, so every GP company has to decide where its posted history will live. Most finance teams move open items and balances to the new ERP and keep detailed GP history in an archive they control. Make that decision before support and security updates end, not after.
Key takeaways
- Microsoft has published an end-of-life timeline for Dynamics GP; take the support and security update dates from its lifecycle page, not from summaries.
- Migrating open items and balances only is the common default, and it leaves detailed GP history behind unless you archive it.
- A read-only GP instance is a short-term bridge, not a long-term archive, once security updates stop.
- Reconcile the archive to GP trial balances and subledger totals before the old server is switched off.
- Old order, purchasing and inventory history keeps supporting audits, disputes, pricing analysis and, after review, data licensing.
What has Microsoft announced for Dynamics GP?#
Microsoft has announced an end-of-life path for Dynamics GP that steps down in stages: an end to new customer sales, an end to regular support and product updates, and a final date after which security updates stop. Microsoft steers GP customers toward Dynamics 365 Business Central and provides migration tooling for that move.
The exact dates drive your project plan, so take them from Microsoft's product lifecycle page and your partner rather than from secondhand summaries. Ask specifically how long payroll tax and year-end updates continue, because many US GP companies depend on them to close their final years on the old system.
| Milestone | What it means for a GP company | Finance action |
|---|---|---|
| End of new sales | No new GP customers; existing customers keep using and renewing | Start the replacement decision and the budget cycle |
| End of regular support | No new features or routine fixes; tax and year-end updates wind down | Confirm payroll and year-end coverage for the final GP years |
| End of security updates | No further security patches for GP | Have history archived and GP retired or isolated before this date |
| After end of life | GP runs only as an unsupported system | Rely on the archive, not on the old server |
Your options for decades of GP history#
The options for GP history come down to four patterns, and many companies combine two of them. The right mix depends on how often staff need old detail, who needs it, and how long you must keep it.
A common combination is to migrate open items, bring a history snapshot for the recent fiscal years staff look up most, and archive everything older to a database the company controls.
| Option | What moves or stays | Strength | Weakness |
|---|---|---|---|
| Migrate open items only | Master records, open receivables and payables, open orders, opening balances | Clean start in the new ERP | Detailed GP history is lost unless archived separately |
| Migrate with a history snapshot | Open items plus selected historical transactions in read-only form | Old detail visible inside the new system | Scope and storage limits; not every module or add-on comes across |
| Archive history to a database you own | Full GP history extracted to SQL tables or files with reporting views | Independent of GP and of any vendor | Needs documentation and an owner to keep access working |
| Keep GP read-only | The old GP system stays available for lookups | Familiar inquiry screens and reports | Licensing, server upkeep and security risk once updates end |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Where GP history actually sits#
GP history sits in separate open, work and history tables for each module, inside one SQL Server database per company plus a shared system database. Year-end closing moves general ledger detail from open-year tables into history tables, and the sales, purchasing, inventory, payables and receivables modules each keep their own tables of posted documents.
Distribution companies usually hold their deepest history in sales order processing, purchase order processing and inventory. Those tables record which orders were backordered, partially shipped, returned or repriced, and which receipts did not match their purchase orders. Third-party add-ons for warehouse management, EDI or commissions often keep their own tables that migration tooling does not touch.
- Every company database and the shared system database
- Module history: general ledger, sales order processing, purchase order processing, inventory, payables, receivables, fixed assets
- Record notes and document attachments linked to transactions
- Add-on tables from warehouse, EDI, commission and reporting products
- Custom reports, SmartList objects and financial report definitions
- User and security settings that explain who posted what
Read-only GP is a bridge, not an archive#
A read-only GP system is useful for a transition period because staff keep familiar inquiry screens and reports. It still needs a supported Windows server, a SQL Server instance, valid GP licensing and someone who knows how to run it, and each of those has its own support timeline.
Once GP security updates stop, the server becomes a growing risk on the network. Isolate it, restrict logins, and treat it as temporary while an independent archive is built and verified. Auditors and acquirers generally care that history is complete, accessible and reconciled, not that it sits behind the original screens.
Illustrative: a distributor's controller plans the GP exit#
Illustrative: a fictional industrial fastener distributor has run Dynamics GP since its early growth, with three company databases, an EDI add-on for its largest customers and a warehouse picking add-on. The controller learns the company will move to Business Central at the start of the next fiscal year.
The partner's plan migrates master data, open receivables and payables, open sales and purchase orders, and opening balances. The controller adds two workstreams: a history snapshot for recent fiscal years, and a full extraction of every GP and add-on table into a company-owned SQL database with simple reporting views and a data dictionary.
Before cutover, the team reconciles archived general ledger and subledger totals to GP for each closed year and keeps a full GP backup offline. The old server is shut down soon after go-live. Later, the archive answers an audit request and a pricing dispute, and a review finds years of backorder and return notes tied to orders worth assessing for licensing.
Checklist before the GP server goes dark#
The checklist below protects what a migration plan usually leaves out. Give each line a named owner, and mark it complete only after someone outside the project team has opened and read the result.
- Take and verify full backups of every company database and the system database.
- Extract each module's open, work and history tables to the archive, including add-on tables.
- Keep original document numbers, customer IDs, vendor IDs and item numbers unchanged.
- Reconcile archived balances to GP trial balances and subledger reports for each closed year.
- Write a data dictionary that explains tables, key fields and status codes.
- Export record notes and attachments with the transaction each belongs to.
- Set a retention period for the archive with your tax advisor and auditor.
- Assign an owner and access controls for the archive after the project team disbands.
How SourceX looks at archived ERP history#
SourceX looks at archived ERP history through the SourceX Enterprise Data Value Framework, which ranks records higher when they connect a request to a decision and an outcome. An order that was backordered, expedited, partially shipped and credited, with notes explaining why, says far more than a ledger line.
A distributor's GP archive stays in its own storage throughout. The opening assessment asks only which modules, years and add-ons exist. Any package that proceeds follows the SourceX five-step transaction, with customer names and pricing details handled in Preparation and every release approved by the company.
Frequently asked questions
Can Business Central hold all of our GP history?
Possibly, but it is rarely the best home for all of it. Bringing large volumes of detailed history into a new ERP adds storage cost and migration effort, and some modules and add-ons do not map cleanly. Many companies move recent history and archive the rest in a database they control.
How long should we keep GP history after the move?
Set retention with your tax advisor and auditor, based on tax, contract, warranty and dispute requirements in the states where you operate. This is general information, not tax or accounting advice. Many companies keep the archive beyond the minimum because detailed history keeps answering audit, dispute and pricing questions.
Do we still need GP licenses to keep a read-only system?
You may. Running GP for lookups generally requires valid licensing, and terms for limited use vary. Ask your partner and Microsoft what applies to your agreement, and weigh the cost of licenses and server upkeep against the one-time effort of a full archive extraction.
What happens to data in GP add-ons?
Add-on products usually keep data in their own SQL tables, and tooling built for core GP may skip them. List every add-on, ask each vendor how to export its data and whether a version exists for the new ERP, and include those tables in the archive with their own documentation.
Can old GP history be licensed to AI developers?
Some of it may be, after a rights review. Order, purchasing, inventory and exception history with notes can show how a distributor handles real operating problems. Customer names, prices and personal details are removed in preparation, and customer contracts and vendor terms are checked first.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.