What to do with years of GP historical data

The instinct to keep GP alive is a trap

The most common plan we hear is also the worst one: migrate current data to the new system, then “just keep GP around for lookups.” It sounds free. It is not.

Keeping GP running means keeping a supported SQL Server underneath it, a Windows server to host both, backups, and someone who still remembers how to administer it. It means GP licensing questions too. Microsoft ended new perpetual license sales on April 1, 2025 and ends new subscription sales on April 1, 2026, so past those dates you cannot add users or easily transfer what you have1. And the clock does not stop there: enhancements, tax updates, and support end on December 31, 2029, and security updates end on April 30, 20312. After that date, a running GP environment is an unpatched application on an aging SQL Server, reachable by anyone who needs “just a lookup.” That is exactly the kind of forgotten system that shows up in breach postmortems.

There is also a human cost. Five years after go-live, the person who knew how to find things in GP has left, the SmartLists nobody documented stop making sense, and the “lookup system” becomes a machine everyone is afraid to touch and afraid to turn off.

So the real question is not “how do we keep GP” but “how do we keep years of history reportable without keeping GP itself.” That question is bigger than most finance teams expect, because GP shops tend to be sitting on far more history than anyone thinks to check before the migration project starts.

Why the archive decision is bigger than it looks

Dynamics GP’s Windows lineage runs back to 1993, when Great Plains Software shipped the first Windows version of the product, Great Plains Dynamics3. Companies that have been on GP, or its direct predecessor, anywhere near that long are not looking at three or four years of transaction history. They are looking at fifteen, twenty, in some cases over thirty years of posted general ledger, receivables, payables, and payroll detail sitting in SQL tables that nobody has opened except to run a SmartList. That long tail is precisely why the “just migrate everything” instinct feels safe: the data already exists in one place, so moving all of it looks like the path of least resistance.

It is the opposite of safe. Data migration is one of the most reliable places for an ERP project to blow its budget and schedule, and moving more data than the new system actually needs only adds exposure. Gartner’s widely cited finding, drawn from a 2009 research note that is still the reference point the data migration industry cites today, is that 83% of data migration projects either fail outright or exceed their planned budget and schedule4. That figure is close to two decades old and Gartner has not republished a fresh version of it since, so treat it as a widely cited legacy benchmark rather than a current study. The mechanism it describes has not gone away though: more source tables, more transformation logic, and more historical exceptions all multiply the ways a migration can go sideways.

More recent, independently collected numbers say the same thing. In Panorama Consulting’s 2024 ERP Report, “data issues” were named as a contributing cause by 34.9% of organizations that went over their implementation budget, and by 46.3% of organizations that went over schedule, the single largest named cause of schedule overruns after generic resource constraints5.

Put simply: the more decades of GP data you drag into scope, the more of that risk you are volunteering for, in exchange for moving records that almost nobody will ever query again once the new system is live.

Migrate a slice, or archive the rest: the honest tradeoff

Neither extreme is right. Migrating nothing but a blank opening balance leaves finance without comparatives on day one. Migrating everything drags fifteen or thirty years of exceptions into a system that was never designed to carry them. The honest tradeoff looks like this.

That is the whole strategy in one picture: migrate the thin slice the new system needs to operate, and archive the thick slice it does not.

The four archive options

Once you accept that most of GP’s history is not moving into the new ERP, the question becomes how you keep it reachable. There are four workable approaches, and most companies end up using two or three of them together.

Option 1: bring a limited slice into the new system. Migrate opening balances plus 1 to 3 years of monthly GL summary, and open documents (AR, AP, purchase orders, sales orders) at full detail level. This covers comparative financials and budget-versus-actual without importing a decade of closed transactions. It is what the new system genuinely needs to operate; it is not an archive strategy on its own, and it should not be stretched to try to be one.

Option 2: a read-only reporting archive. Extract the GP tables into a plain SQL database or a small data warehouse, with views that translate GP’s cryptic table names into human-readable ones: postings, invoices, payments, customers, vendors. Point Power BI, Excel, or plain SQL at those views. No GP client, no Dexterity runtime, no GP licensing to maintain, and it survives 2031 indefinitely because at that point it is just data, not an application with a support clock attached. This is the option that actually replaces what people used GP’s own lookups and SmartLists for day to day, and it is usually the piece worth investing the most care into, because it is the one your team will touch again.

Option 3: a document archive. Before decommissioning, render the statutory record to files: monthly trial balances, GL detail by year, AR and AP aging at each year end, financial statements out of Management Reporter (or legacy FRx, if reports still live there), posting journals, and filed tax returns. Store the PDFs and Excel files in your document management system with a sensible, dated folder structure. This is the cheapest insurance and the format auditors accept most readily, because it looks like the paper trail they already know how to review. Its weakness is that you can only look at reports someone thought to run before GP went dark, so treat it as a floor, not the whole plan.

Option 4: a frozen SQL copy. Take final native backups of every company database and the shared DYNAMICS system database, restore them somewhere cheap (an offline SQL instance, or backup files sitting in cold cloud storage), and write down the SQL Server version, edition, and any ISV or Dexterity table customizations someone would need to know about to make sense of it later. This is your last-resort answer: if a question ever comes up that the reporting archive and the document archive cannot settle, the raw data still exists, unaltered, exactly as GP left it. It costs almost nothing and needs no ongoing maintenance as long as it stays offline and someone re-tests the restore once a year.

The pattern that works for most companies: option 1 for the new system’s day-one needs, option 2 for real day-to-day reporting, option 3 for the statutory paper trail your auditor expects, and option 4 as cheap insurance underneath all three. That combination usually costs less in its first year than twelve months of keeping a full GP environment on life support, and it gets cheaper every year after that.

One sizing note worth saying out loud: GP history is smaller than people fear. Fifteen or even thirty years of transactions for a mid-market company is typically tens of gigabytes, not terabytes. The reporting archive in option 2 is a small database by any modern standard. The real work is in building correct views and validating them against GP’s own reports, not in finding somewhere to put the data.

Inside GP’s own history tables

Understanding a little of GP’s own table structure makes option 2 and option 4 far less intimidating, because GP has already done part of the archiving work for you, inside its own schema, for years.

Across most modules, GP keeps a rough three-tier split: setup and master tables (customers, vendors, accounts, items), work or currently open tables holding transactions still in progress or unpaid, and history tables holding transactions that have already posted and closed. The general ledger is the clearest example: GL20000 holds open-year transaction detail, and GL30000 holds transactions once a year is closed, which is exactly why “how many years of GL history do we actually need in the live system” is a real design decision, not a technicality. Receivables mirror the same idea; document-level detail for paid, closed transactions lands in the RM30000-series tables such as RM30101, while open, unpaid documents live elsewhere in the RM series and drive your current aging report. Payables follow the same pattern, with paid transaction history in the PM30000-series tables such as PM30200. Sales order processing and purchasing keep their own posted-history tables too, commonly referred to by names like SOP30200 and POP30100 in GP documentation and by most GP consultants.

That existing split is good news for an archive project. It means the “history” your reporting database needs to expose is already segregated at the source, in tables GP itself uses to answer the question “is this open or closed.” A well-built reporting archive typically keeps that same open-versus-history distinction in its views, even though by the time you are building the archive, everything in it is closed by definition. It also means that before any extraction, you should run GP’s own history-related maintenance routines (reconciling subledgers to GL, and if you use it, GP’s remove-history utility, applied only after you have confirmed you no longer need the detail it purges) so the tables you are copying are internally consistent before they become someone’s permanent archive.

Comparing the options

Multi-company and the messy corners

If you run multiple GP companies, decide the archive structure deliberately rather than by default. GP keeps each company in its own database, with shared setup living in the DYNAMICS system database. A reporting archive can either preserve that same separation, one database per legacy company, or consolidate everything into one store with a company dimension added to every table, which is usually more useful for cross-entity analysis later. Intercompany transactions, historical currency rates and exchange tables, and any ISV add-on tables (fixed assets from a third-party module, field service history, EDI logs) need to be added to the extraction list explicitly, because none of them come along by accident when you are focused on the core financial modules.

Also close out the loose ends before the final extract. Post or delete unposted batches, finish any pending year-end closes, and run your reconcile routines in GP one last time. An archive built from a messy database is a messy archive forever, and unlike a live system, nobody is coming back to fix it after the fact.

Retention and audit: the question your auditor will eventually ask

How long you must keep the history is a legal and contractual question, not a technical one, and the answer varies by jurisdiction and record type. Common anchors that come up repeatedly: seven years for most US federal tax records, six years from the end of the tax year for CRA in Canada, longer retention for payroll records in many jurisdictions, and fixed-asset support for the life of the asset plus whatever retention period applies afterward. Loan covenants, industry regulators, and specific customer contracts can extend any of these further. Get the actual retention schedule from your accountant or counsel, write it down as an explicit policy, and design the archive to meet the longest applicable window, not the one that is easiest to build.

Handled this way, decommissioning GP does not mean losing your history. It means moving that history somewhere cheaper, safer, and honestly easier to search than GP ever was, while turning off a system whose only remaining job was making everyone nervous about the day it finally breaks.