GP is Sunsetting: Use Your ERP Migration to Retire Risky Customizations and Modernize AP

The deadline is real, but the bigger decision is hidden 

Plenty of finance teams have lived in Dynamics GP for years. It’s familiar, stable, and deeply customized. For a long time, that was the point.  

Now there’s a clock on the relationship. Microsoft has announced Dynamics GP product support and updates end December 31, 2029, and security updates, if needed, run until April 30, 2031. 

That timeline creates urgency, but it also creates a rare opportunity. Migrations tend to confirm what most teams already feel: the hardest part isn’t the ERP. It’s the layer of customizations and workarounds built around it, especially in AP.  

Here’s the hidden decision inside every migration plan: Will you recreate the same AP workarounds in a new system, or use the move to simplify and strengthen controls? 

The problem: GP customizations age into operational risk 

Customizations are not automatically bad. Many were built for good reasons: a missing report, a unique approval path, a special vendor requirement, or a department that needed faster turnaround. 

The risk builds over time: 

• The original logic becomes tribal knowledge. 
• Documentation falls behind reality. 
• A “temporary” AP workaround becomes the process. 
• The customization layer starts behaving like a second ERP. 

Teams discover that what looks like critical customization often includes workarounds that can be replaced, simplified, or retired. 

And the longer the customization stack grows, the more it costs to change anything. McKinsey reports CIOs estimate tech debt equals 20% to 40% of the value of their technology estate. That’s why ERP projects get expensive fast, even when the new system is “better.” 

During a migration, that drag turns into delays, rework, and the dreaded “we rebuilt it because no one could explain it.” 

Why this hits AP first 

AP is where real-world variability lives. Invoices arrive in every format. Exceptions are common. Approvals happen between meetings. Vendors change banking details. Departments code things differently. 

AP teams often solve friction with: 

• Email approvals 
• Manual status tracking 
• Spreadsheet-based vendor changes 
• One-off reports to compensate for missing visibility 
• Custom logic that manages exceptions instead of preventing them 

Those fixes feel practical in the moment. Over time, they create long-term risk: slower close, weaker audit trails, inconsistent controls, and higher fraud exposure. 

Why now: Migration periods increase fraud and compliance pressure 

ERP transitions create noise. New processes. New roles. New access. New approval paths. That’s the perfect environment for mistakes and social engineering. 

Verizon’s 2024 Data Breach Investigations Report found the “human element” was a component in 68% of breaches. 

Payment fraud isn’t a fringe issue either. AFP’s 2025 Payments Fraud and Control Survey reports 79% of organizations experienced attempted or actual payments fraud activity in 2024, and 63% cite Business Email Compromise (BEC) as the top avenue for fraud attempts. BEC attacks surged 1,760% year-over-year from 2022 to 2023, as threat actors leveraged AI to craft increasingly sophisticated social engineering attacks. 

BEC is especially relevant during system changes because it often targets exactly what migrations disrupt: vendor onboarding, vendor banking updates, and payment routing. 

That should make every finance leader pause during an ERP transition. 

The opportunity: Treat the ERP move as a reset, not a rewrite 

The most expensive migration mistake is simple: rebuilding old workarounds because “that’s how we do it.” 

A better approach starts with the result you’re trying to protect. Instead of asking, “How do we rebuild this customization?” ask, “What was this customization trying to accomplish?” 

Common AP outcomes worth keeping: 

• Faster approvals without losing control 
• Consistent coding and routing across departments or locations 
• Clear invoice status without inbox chasing 
• Vendor changes that are documented and auditable 
• Fewer exceptions slowing close and cash planning 

When the outcome is clear, the design choices get easier. A lot of “must-have” customizations turn out to be “we never had time to fix the process.” 

How to rethink customizations before you migrate 

Here’s a practical framework that teams can use without turning this into a six-month discovery project. 

1) Inventory the reality, not just the code 

Include: 

• Custom fields, reports, integrations, scripts 
• Third-party add-ons 
• Spreadsheets that track invoice status, exceptions, or vendor data 
• Manual steps that exist because the system could not enforce the policy 

For each item, capture: 

• Who uses it 
• What breaks when it disappears 
• What risk it was designed to reduce 

That last bullet is the key. It separates real controls from habits. 

2) Sort everything into four buckets 

Keep this simple and decisive: 

• Replace: The next ERP covers it out of the box. 
• Configure: It can be supported through standard workflow and settings. 
• Rebuild: The business truly needs it, and it deserves governance. 
• Retire: It solved a past limitation and no longer earns its keep. 

Most teams find “retire” is bigger than expected. That’s where your migration ROI lives. 

3) Decide where work should live 

Every modern ERP supports configuration and workflow, but not every workflow belongs inside the ERP. 

Invoice intake and approvals don’t have to live inside the ERP just because the ERP exists. High-volume document capture, approvals, and exception handling often work better when they’re standardized outside the ERP so the core system stays clean and scalable. This also helps prevent “custom code creep” from coming back a year after go-live. 

4) Make change management part of the build 

ERP migrations fail quietly. The system goes live, but adoption drifts. Workarounds return. Controls weaken. 

Research shows projects with effective change management met or exceeded objectives 93% of the time, compared to 15% for projects with poor change management. That difference is why process ownership matters as much as system configuration. 

Practical steps: 

• Assign owners for each AP policy and workflow 
• Define success metrics people can see weekly (approval aging, exception rates, rework volume) 
• Train on the new standard, not the old shortcuts

The AP reset: What “modern controls” look like after GP 

A clean AP workflow after GP isn’t about fancy features. It’s about consistency, visibility, and defensibility. 

Strong vendor change controls 

Vendor onboarding and banking changes deserve a controlled workflow that captures documentation, verifies requests, and leaves a clear audit trail. This reduces the room that BEC scams exploit, especially during periods of change. 

Lower exception volume, faster exception resolution 

Exceptions are normal. Chaos is optional. 
 
A modern approach reduces exceptions upstream through better capture and coding standards, then routes remaining exceptions with clear owners and SLAs. That stops AP from becoming a constant follow-up function. 

Approvals that move quickly and stand up to scrutiny 

Approvals should be fast and trackable. A good workflow answers basic questions instantly: 

• Where is the invoice? 
• Who is blocking it? 
• What changed and why? 
• What documentation supports the decision? 

Once you’ve defined those controls, the ERP choice becomes less scary because you’re not asking it to solve everything. 

Your next ERP may change. The customization trap doesn’t. 

Many GP customers are moving to NetSuite. Others are choosing Business Central, Dynamics 365 Finance, Sage, or another modern ERP. Plenty are still in evaluation mode. 

The destination matters, but the biggest migration risk stays the same across all of them: rebuilding old customizations and AP workarounds without revalidating the outcome. That’s how teams end up with a “new” ERP and the same approval bottlenecks, exception chaos, and control gaps they hoped to leave behind. 

So, treat this as an ERP-agnostic principle: configure where you can, customize only when you must, and design AP controls so they’re consistent and defensible regardless of platform. 

The key is keeping the outcomes and retiring the workarounds, no matter which ERP you choose next. 

What a strong AP migration plan includes 

Don’t let AP become the catch-all where exceptions, vendor changes, and approvals go to disappear. 

Before you finalize your target-state design, pressure test it with a few practical questions: 

• Invoice intake: Where do invoices land, and how do we prevent “invoice sprawl” across inboxes and shared folders? 
• Coding standards: What fields must be consistent every time, and who owns enforcement? 
• Approvals: What are the rules, where do exceptions go, and how do we measure approval aging? 
• Vendor changes: What verification steps exist for new vendors and banking updates, and where is documentation stored? 
• Audit trail: Can we answer “who approved what and why” without digging through email? 
• Exception handling: Do exceptions route to the right owner fast, with clear SLAs and visibility? 
• Governance: Who decides when something becomes a customization, and how is it documented? 

If you can answer those confidently, you’re far less likely to rebuild GP-era workarounds in your next ERP. 

Put the GP deadline to work 

Dynamics GP sunsetting puts a real timeline on your ERP decision, but the bigger risk is what you carry forward. The fastest way to waste a migration is rebuilding years of AP workarounds without questioning what they were actually protecting. Use this moment to keep the outcomes that matter and retire the customizations that quietly added cost, complexity, and exposure. 

A strong “post-GP” AP process is simple to explain and hard to break. Vendor changes run through clear controls. Exceptions get routed to the right owner fast. Approvals move quickly, and the audit trail is there when you need it. 

If you want to protect the AP side of your migration, onPhase can act as the layer of consistency across the transition, so controls don’t depend on tribal knowledge or last-minute workarounds. We help teams design and standardize invoice intake, approvals, exception handling, and vendor change workflows before go-live, so the new ERP launches cleaner and stays easier to maintain. That’s migration insurance against the most common failure mode: workarounds creeping back in when things get busy. 

Before you assume your next ERP will solve AP on its own, this is a helpful follow-up: Why Your ERP Isn’t Solving Your Accounts Payable Problems.