The GP Migration Checklist for Finance Teams: What to Fix Before You Move to a New ERP

Summary: What should finance teams fix before migrating from Microsoft Dynamics GP to a new ERP? This checklist helps you assess the data, reports, integrations, customizations, and AP workflows built around GP before you move. Use it to decide what to clean up, keep, redesign, or retire, so old approval bottlenecks and control gaps don’t follow you into the new system.

Every conversation about migrating off Dynamics GP tends to start with the same question: which system comes next. That's the wrong place to start, or at least an incomplete one.

The timeline is public at this point. Microsoft stopped selling GP to new customers in April 2026, mainstream support closes at the end of 2029, and security patches stop in April 2031. Microsoft pushed that support cutoff out three months, from September 30 to December 31, so GP customers could get through a full tax year-end close on a supported system. Small detail, but it tells you Microsoft expects finance, not just IT, to be driving this timeline.

Mid-market finance teams are already evaluating what's next, and much of that decision locks in over the next few months, as 2027 budgets close. Almost everything written about this transition is aimed at IT: data mapping, integration testing, cutover sequencing. Useful, but it skips the part finance lives with every day. The system underneath can change completely while the manual habits built around it survive the move untouched, and nobody notices until it's too expensive to fix.

The System Changes. The Habits Don't.

Approvals still move through Outlook threads, invoices still get filed in a folder named something like AP_Invoices_2019, and the workflow configuration screen hasn't been touched in years. Meanwhile, GP has had a native Workflow module since the 2013 R2 release, along with a Document Attach feature that lets a scanned invoice travel with the transaction instead of sitting on a shared drive. Plenty of shops never fully adopted either one.

That gap matters more than it looks. A new ERP gets configured around whatever process the implementation team can observe, not the process that should exist on paper. If your real approval routing is "email Sarah and wait for her to get back from lunch," that's what tends to get rebuilt, just with a different login screen wrapped around it.

IT is focused on getting data to move correctly and the new platform to function. Nobody on that team is positioned to ask whether a $50,000 invoice really needs three signatures, or whether that threshold was set in 2014 and never revisited since. That's a finance question, and finance needs to answer it before configuration gets finalized, not after.

That's also why this migration belongs on the CFO's desk, not just the controller's or IT's. IT owns the technical cutover. Finance owns the decision about what gets carried forward. Hand that call entirely to IT and the new system inherits every workaround finance has complained about for years, just with a bigger budget behind it.

GP shops tend to hit this in three places.

• Reporting comes first. Microsoft stopped making major investments in Management Reporter in 2016, so plenty of GP shops already moved their consolidated and multi-entity reporting to Jet Reports, Solver, or a homegrown Excel process. That layer rarely makes it onto the migration plan, even though it's just as tied to GP's chart of accounts as everything else.
• Intercompany is next for multi-entity organizations. GP handles it through due-to and due-from accounts that finance teams typically reconcile by hand at month-end. The logic behind those reconciliations lives in whoever has been closing the books long enough to remember which entities net against which, and it doesn't migrate just because the data does.
• Vendor tax data works the same way. GP tracks 1099 flags at the vendor level, but the W-9 chasing, TIN matching, and mid-year threshold checks usually happen in a spreadsheet nobody thought to include in migration scope. Leave it out and someone finds out the hard way in January.

What the Research Says

Many organizations are mid-transition right now. Only about a quarter of finance teams have fully moved off on-premises systems, with most running hybrid environments or planning a move within the next year or two.

AP hasn't caught up either. 63% of AP professionals spend more than 10 hours a week on invoice processing alone, up from the year before. Swapping the ERP underneath that process doesn't shrink that number on its own. It just relocates where the manual work happens.

Fraud deserves a direct callout, given what a migration touches. 79% of organizations experienced attempted or actual payment fraud in 2024, and vendor banking changes remain one of the most common entry points. A migration is one of the few moments every vendor record in the system gets opened, reviewed, and re-entered, which is precisely when a bad actor wants access.

The short version of what determines whether a GP replacement succeeds is that picking the new platform matters less than deciding what to fix before you get there.

The GP Migration Checklist

This is the part finance teams can control, regardless of which ERP is next. Before IT finalizes configuration, work through these three areas. For every item below, decide whether to carry it over, rebuild it on purpose, or retire it.

Timing matters here too. Fixing an approval chain before it's rebuilt in a new system takes a working session and a decision. Fixing it after go-live means reconfiguring something that's already live, already trained on, and already tangled up with other settings. Whoever champions this internally, whether that's the controller, a finance director, or the CFO, gets a much easier win by doing it now.

Workflow and approvals

• Map every approval chain as it actually works today, not as the org chart says it works.
• Check whether GP's Workflow module was ever fully configured, or whether approvals still happen over email even though the tool has existed in the system for over a decade.
• Flag any approval step that exists because of a specific person rather than an actual policy.
• Decide which dollar thresholds, sign-offs, and routing rules still make sense at current invoice volume.
• If you run multiple entities, document how intercompany reconciliation works today, including which entities net against which.

Documents and records

• Separate what needs to migrate with full history from what's fine to archive and leave behind, covering vendor records, contracts, and supporting documentation.
• If invoices already live in GP's Document Attach, confirm those files export cleanly. If they live on a shared drive instead, decide who's responsible for reconciling that folder against the new system.
• Confirm compliance and retention requirements, especially in regulated industries, and figure out how many years of AP history genuinely need to move versus just get archived.
• Assign document governance ownership in the new system early, since that tends to fall through the cracks mid-migration.
• Decide how approval history and audit trails will be preserved. Auditors will still ask who approved pre-cutover invoices after GP is gone.

Accounts Payable

• Assess how much invoice capture and GL coding still depend on manual keying
• Re-verify vendor banking and payment details before they carry over.
• Check who can both create vendors and approve payments. A migration is a natural moment to catch those overlaps before they get copied into the new system.
• Pull the 1099 tracking and W-9 collection process out of whatever spreadsheet it's living in and confirm it has an actual home in the new system before your first year-end close.
• Note where AP is leaning on SmartList or a custom report to cover a visibility gap GP itself doesn't handle, and check whether the new system actually closes that gap or just recreates it under a different name.
• If Management Reporter or a homegrown replacement for it is still doing your consolidated reporting, map how dependent it is on GP's account structure before that reporting layer gets rebuilt somewhere else.
• Plan to run at least one AP cycle and one month-end close in parallel, and name who signs off that the numbers tie.

This is where an ERP-agnostic layer earns its keep. When approval routing, document management, and AP processing live in a platform like onPhase that connects to any ERP, you make these decisions once, and they survive this migration and the next one.

Approval bottlenecks that get pushed to "phase two" tend to stall after go-live and never get fixed. The checklist above is how you keep that from happening to your team.

Fix the Habits Before You Fix the System

GP's sunset timeline is the forcing function here, but it's not really the point. The real opportunity is fixing workflow and documentation habits that have been costing your team time and control, in some cases since before the current finance staff even joined.

IT will get the technical cutover done. What decides whether the new system works any better than GP did is whether finance made these calls first, instead of letting IT infer them from six months of transaction history.

onPhase helps finance teams get ahead of exactly this by sitting above the ERP rather than inside it, so the approval logic and document trail don't have to get torn down and reconfigured every time the underlying platform does. If your team is still sorting out which GP customizations are worth carrying into the new system and which ones just need to be retired, GP is Sunsetting: Use Your ERP Migration to Retire Risky Customizations and Modernize AP walks through how to make that call.