The Dynamics GP migration checklist

Most GP migration failures are sequencing failures. The company picks software in week one, discovers its own customizations in month four, and learns about the unposted batch problem during cutover weekend. The fix is boring and effective: do the phases in order, and do not let a vendor demo pull phase two ahead of phase one.

Here is the full sequence. Each phase has a purpose and a short list of concrete tasks. Print it, assign names to it, and work it top to bottom.

Why the go-live shape matters before you start

Before the checklist itself, one decision deserves to be made explicitly rather than by default: how you cut over. Independent survey data on ERP implementations gives a clear answer, and it is not the one most teams assume.

The 2024 Panorama Consulting ERP Report surveyed 131 organizations mid-implementation or just past go-live, and the timeline was 15.5 months at the median, with 55.0% finishing on budget and 58.0% on schedule1. Read plainly: nearly half of ERP projects still slip on time, cost, or both, even among organizations that planned carefully enough to be in this survey at all. That is the baseline you are planning against, not a worst case.

The same survey asked how organizations actually went live, and the answer argues strongly against the single flash cutover most executives picture when they hear “go-live weekend.”

Only about 9.2% of organizations used a big bang cutover, the approach where every module, every company, and every user flips to the new system on a single date1. The other 90.8% spread the risk: 36.6% ran a hybrid approach, 22.1% went module by module, and 13.7% went business unit by business unit1. That is not a niche preference, it is the dominant pattern, and it exists because a phased approach lets you prove GL and AP work before you also switch on payroll, or prove one legal entity before you also switch on three.

The ten-phase sequence

1. Inventory what you have. You cannot scope what you have not counted, and every budget blowup traces back to something missed here. Spend two to four weeks producing a written inventory of your actual GP footprint, not the footprint people remember.

   • List every company database, its entity, and whether it is active. Check the DYNAMICS system database for the full company list; GP shops routinely forget an old test company or a dormant subsidiary that is still technically live.
   • Export the module list and identify which you actually use (GL, AP, AR, payroll, inventory, sales order processing, purchasing, project accounting, fixed assets).
   • Inventory customizations: Dexterity mods, modified windows and forms, VBA and Modifier scripts, and every ISV add-on (Nolan, Rockton, Mekorma, Encore and similar vendors show up constantly) with its version and support status.
   • Inventory integrations: Integration Manager jobs, eConnect endpoints, SQL Server Agent jobs, and anything else reading or writing the GP company databases directly, since these are invisible until someone asks why a bank feed stopped.
   • Inventory reports: the SmartLists people rely on daily, any modified Report Writer reports, SSRS reports built against the GP tables, and every Management Reporter or legacy FRx statement the monthly close depends on.
   • Confirm whether you run US payroll (the UPR series of tables) or Canadian payroll (the CPR series) in GP, or both. This single answer sets your deadline, since tax and regulatory updates end December 31, 20292, and it sets your cutover date, since payroll rarely moves mid-year.

2. Decide the destination. Only now, with the inventory in hand, evaluate targets. The inventory turns demos into interrogations: you know exactly which of your workflows to make each vendor demonstrate, instead of watching a generic script.

   • Shortlist against your profile: Dynamics 365 Business Central for most GP shops (Microsoft’s own designated successor, and now past 50,000 cloud customers3), QuickBooks Online for simple single-entity downsizing, NetSuite for multi-entity growth, a custom-plus-packaged hybrid for the rare heavily differentiated case.
   • Score each candidate against your top ten workflows and your report inventory from phase one, not against a generic feature matrix every vendor can check the same boxes on.
   • Check ISV replacement paths for every add-on you kept in phase one: does it have a native equivalent in the new system, a marketplace app, or nothing at all.
   • Get real, itemized quotes for licensing and implementation, and reference-check the implementation partner with a company close to your size and industry, not just their best logo.

3. Scope data and history. Decide what moves, what gets archived, and what dies. This is the largest cost lever in the whole project, so make it a deliberate decision, not a default.

   • Choose the history strategy: migrate opening balances plus open transactions, and keep historical detail in a read-only GP archive. Migrating full posted history (GP splits open and historical GL detail across its 20000-series and 30000-series tables for exactly this reason) is the expensive exception, not the rule.
   • Define “open” precisely: open AR and AP documents, open purchase orders and sales orders, unreconciled bank items, in-flight projects and jobs.
   • Decide the treatment of historical versus open transactions per module, and get your auditors’ agreement on the archive approach in writing before you build anything.
   • Schedule master-data cleanup in GP now: duplicate vendors and customers in the RM and PM master tables, dead GL accounts, inactive items, stale addresses. Cleansing while the data is still in GP, where your team knows the context, is cheaper than cleansing after import.

4. Plan customizations, integrations, and reports. Every item from the phase-one inventory gets one of three verdicts: replace natively, rebuild, or retire. Unverdicted items become cutover-weekend surprises.

   • Walk the customization list with the people who actually use each one; retire aggressively; a Dexterity modification nobody has opened in two years does not need a rebuild budget.
   • Design replacements for load-bearing integrations (bank feeds, ecommerce, warehouse management, CRM) against the new platform’s native APIs, not by trying to re-point the old Integration Manager or eConnect jobs at a system that does not speak their protocol.
   • Map every keeper report to its new home, and prototype the two or three financial statements the CFO actually opens first, before you prototype anything else.
   • Set a hard rule: no new customization requests during the migration itself. Migrate first, improve after go-live, or the scope will never close.

5. Make the payroll plan. Payroll has the least forgiving calendar in the project, so it gets its own phase even when everything else stays flexible.

   • Decide: payroll runs inside the new ERP, or moves to a payroll bureau (often the simpler answer, and one worth pricing before assuming otherwise).
   • Target a January 1 first pay run to avoid mid-year year-to-date balance migration; it is possible mid-year, but materially harder and a common source of the “data issues” that show up disproportionately in overrun statistics (more on that below).
   • Plan the extraction of employee year-to-date figures, tax setups, and benefit elections from GP, and the retention of W-2 and T4 history in the archive.
   • Book at least one full parallel pay run into the timeline before the first live one, and reconcile every employee, every deduction, to the cent.

6. Build and configure. The implementation partner’s home turf, but your team owns the decisions being encoded, not just the sign-off at the end.

   • Design the new chart of accounts and dimensions; do not photocopy the GP account framework into the new system, this is your one clean chance to fix a segment structure you have outgrown.
   • Configure companies, posting setups, approval workflows, and security roles to match how the business actually operates today, not how GP was configured a decade ago.
   • Build the agreed integrations and reports from phase four, and demo each one against a live extract, not a screenshot.
   • Stand up a test environment loaded with a real extract of your data, not sample data. Sample data hides every mapping problem you actually have.

7. Migrate and reconcile data. Practice runs, then the real one. The word that matters is reconcile: a migration is not done when data loads, it is done when it ties.

   • Post or delete every unposted batch in GP before extraction; an unposted batch sitting in a company database is the single most common reason a trial balance will not tie on the first attempt.
   • Run at least two full trial migrations, timing each one so you know exactly how long cutover weekend will actually take, not how long you hope it takes.
   • Reconcile after every run: trial balance to GP, AR and AP aging to GP’s subledgers at the document level (not just in total), inventory quantities and values, bank balances.
   • Have the controller sign off on each reconciliation. A named human, not a status update in a project tracker.

Why data issues deserve their own line item

Every phase above touches data in some way, but it is worth being blunt about why phase seven in particular carries so much risk. In the same Panorama survey, “data issues” were not a vague catch-all; they were a named, ranked cause that respondents specifically checked off when asked why their project went over budget or over schedule.

Among organizations that went over budget, 34.9% named data issues as a contributing cause, behind only unexpected new technology needs and underestimated staffing1. Among organizations that went over schedule, data issues were the third most-cited cause at 46.3%, behind only generic resource constraints and technical issues1. Put those two numbers next to the phased-cutover data above and the pattern is consistent: teams that treat data migration as a discrete, reconciled workstream with its own checkpoints (phases three and seven in this list) are the ones the survey data implicitly rewards, because a phased or hybrid go-live gives you the chance to catch a data problem in one module or one business unit before it contaminates the whole cutover.

8. Parallel run. Prove the system on real work before you depend on it. Keep parallel scope tight; running two full ERPs for months exhausts a finance team and invites shortcuts.

   • Run payroll in parallel at least once and match it to the penny, employee by employee.
   • Process a representative week of transactions in both systems, or at minimum re-perform a month-end close in the new system and compare the resulting statements to GP’s.
   • Compare Management Reporter or FRx output to the new system’s financial statements line by line, not just at the bottom line.
   • Log every discrepancy with a root cause. Cut over on evidence, not optimism.

9. Cutover and go-live. A dated, rehearsed weekend (or, if you took the phased path the data above recommends, a dated rehearsed phase) with an owner for every task and a decided rollback plan.

   • Freeze GP transaction entry for the phase or module going live, post final batches, run the final extraction and load.
   • Complete final reconciliations and get the same named sign-offs as phase seven.
   • Flip integrations to the new system for the phase going live; set the corresponding GP module to read-only for all users.
   • Staff a hypercare period of two to four weeks with fast paths to the partner, and hold daily triage in week one.

10. Decommission GP and archive history. The phase everyone skips and then regrets during the next audit or customer dispute.

    • Preserve read-only access to the GP SQL databases (a maintained VM or an extracted reporting database) with a documented way to answer historical questions using the table conventions from phase one and three.
    • Confirm retention obligations with your auditors: seven years is a common floor, longer in some industries.
    • Keep the archive patched while security updates last; after April 30, 2031 GP is frozen for good2, so plan the archive’s isolation (no general network access) well before then.
    • Cancel GP enhancement or subscription billing, retire ISV contracts, and harvest the licenses budget line.

How long the whole sequence takes

Simple single-entity moves compress these phases into a 2 to 3 month project. A typical Business Central migration spends 3 to 6 months across them. Complex multi-entity environments with payroll and custom integrations run 6 to 12 months, and the payroll calendar (phase five) usually dictates the go-live date more than anything else. All of those ranges sit comfortably inside the 15.5-month median Panorama found across ERP projects generally1, which is reassuring context: a well-scoped GP migration, run in the phased shape most organizations actually use, is not an outlier project by the standards of the wider market.

Work backward from that: a January 1, 2028 go-live means starting phase one in early to mid 2027. Every quarter of delay from here spends your slack against the phased path above, and the last waves before December 31, 2029 will compete for a shrinking pool of migration partners, since new perpetual GP licenses stopped selling April 1, 2025 and subscription sales stop entirely April 1, 20264, which is pulling partner capacity toward migration work and away from new GP implementations.

If you want a head start, our assessment produces the phase-one inventory and the phase-three data decision for you, which are the two deliverables everything else in this list depends on.