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.
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.
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.
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.
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.
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.