Migrating from Microsoft Dynamics GP to Microsoft Dynamics 365 Business Central is not just a technical upgrade. It is a business transformation. And when projects go sideways, it is rarely because of the software.
The most common Dynamics GP migration mistakes trace back to the same four areas every time:
- Data
- Design
- Scope and integrations
- Change management
Having worked through this transition for over 10 years, here are the seven pitfalls we see GP users make most often and what it actually takes to prevent them.
Mistake 1: Migrating Everything Without Cleaning Your Data
The Problem
The instinct on most migration projects is to bring everything over and sort it out on the other side. It feels safer. But what it actually does is import years of accumulated mess into a brand new system. Duplicate vendors, inactive customers, obsolete GL accounts, and item masters that nobody has looked at in a decade.
That data does not get cleaner on the other side. It gets more expensive to fix.
How to Avoid It
Treat migration as a data quality initiative, not a data transfer exercise. Before a single record moves, audit your master data, archive transaction history you do not actually need, and reconcile your ledgers. The cleanup work is not glamorous but it is the foundation everything else is built on.
The organizations that go live on Business Central with clean data spend their first months optimizing. The ones that do not spend their first months firefighting.
Mistake 2: Not Deciding How Much History to Move Until It Is Too Late
The Problem
The history question sounds straightforward until it is not. Do you move full transactional history? Three years of detail? Opening balances only? Finance wants everything. IT wants to keep it simple. Auditors have their own requirements. And nobody wants to be the one to make the call.
So, the decision gets delayed. And delayed decisions in ERP projects do not stay contained. They push out design timelines, expand scope, and surface as expensive surprises in the back half of the project.
How to Avoid It
Get alignment on this early, ideally during the discovery phase. The questions to answer are practical ones: how many years of detailed transactions do you actually pull up on a regular basis? What can live in an archive database and still be accessible when needed? What do your regulatory requirements actually mandate?
Most organizations land on one to three years of detailed history plus opening balances. That benchmark is worth knowing before the conversation starts.
Mistake 3: Assuming Custom and ISV Data Will Migrate Automatically
The Problem
GP environments accumulate customizations over time. Custom SQL tables, ISV solutions, modified reports, third-party integrations built to fill gaps in the native product. These are often load-bearing parts of how the business actually runs, and none of them migrate automatically.
The teams that discover this during testing are the ones that end up in trouble. Scope expands, timelines shift, and costs climb in ways that could have been avoided with a few weeks of upfront inventory work.
How to Avoid It
Before migration planning begins, document everything that connects to or extends GP. For each item, answer three questions: is there a native Business Central feature that replaces this? If not, what is the plan for the data it holds? And who owns that decision?
Most GP environments have more customization debt than anyone realizes until they start looking. Finding it early is the only way to plan for it honestly.
Mistake 4: Rebuilding the GP Chart of Accounts 1:1 in Business Central
The Problem
This one is more common than most teams expect and more consequential than it looks on the surface. GP is built on segment-based account structures. Business Central is built on dimensions. They solve the same reporting problem in fundamentally different ways.
When teams try to replicate their GP chart of accounts directly in Business Central, they end up with an overly complex account structure, a reporting model that does not take advantage of dimensional flexibility, and a setup that will be painful to maintain as the business evolves.
How to Avoid It
Treat the chart of accounts redesign as a design decision, not a migration task. Map your main accounts to GL accounts and your GP segments to Business Central dimensions. Then use that mapping as an opportunity to simplify and modernize your reporting structure rather than just recreate what you had.
Business Central is not GP in the cloud. The organizations that get the most out of it are the ones that design for what it is, not what they are leaving behind.
Mistake 5: Treating Migration as a Lift and Shift
The Problem
The phrase "we are just moving to the cloud" does more damage to GP migration projects than almost anything else. It sets expectations that do not survive contact with reality.
A GP to Business Central migration touches finance, operations, warehouse, purchasing, sales, and reporting. It changes how people do their jobs every day. That is not a technical upgrade. It is a full ERP implementation, and it needs to be scoped, staffed, and resourced like one.
Teams that go in expecting a quick move spend the back half of the project scrambling to catch up on work they did not plan for. Teams that plan for the full implementation scope from day one move faster, not slower, because they are not constantly resetting expectations.
How to Avoid It
Plan for multiple test migrations, structured user acceptance testing across departments, and dedicated internal project ownership from the start. Cross-functional involvement is not optional. Every department that touches the system needs a seat at the table before go-live, not after.
Mistake 6: Failing to Inventory Integrations Early
The Problem
Most GP environments are more connected than anyone fully maps out on a whiteboard. Banking connections, payroll systems, e-commerce platforms, expense tools, warehouse management systems, custom reporting feeds. Some of these are well documented. Many are not.
The ones that are not documented are the ones that break at go-live. And integration failures at go-live are not minor inconveniences. They stop business processes that the company depends on every day.
How to Avoid It
Build a complete integration inventory before design begins. For everything that connects to GP today, document what it does, how data flows, and what the Business Central equivalent looks like. Then make sure that mapping is complete before testing starts, not after.
Integration work that gets discovered during testing has to be rebuilt under pressure. Integration work that gets planned during design gets built right.
Mistake 7: Underestimating Training and Change Management
The Problem
The most common thing leaders say about this one is some version of "it is Microsoft, our people use Teams and Excel every day, they will figure it out." It is an understandable assumption. It is also wrong often enough to be worth addressing directly.
Business Central introduces role centers, posting groups, dimensions, and navigation that works differently than GP. For users who have been running the same workflows in GP for years, the learning curve is real. Without structured training and a plan for managing the transition, frustration builds quickly and productivity takes longer to recover than it should.
How to Avoid It
Designate internal super users who are trained before go-live and available to support the team after. Build UAT that goes beyond happy path testing and actually stress-tests the workflows people use every day. Deliver role-based training so people are learning what they need, not sitting through content that does not apply to them.
Adoption determines ROI. A well-implemented system that nobody uses confidently delivers a fraction of its potential value.
Bonus Mistake: Trying to Do Everything in Phase 1
Ambition is not a bad thing on an ERP project. But trying to migrate the ERP, redesign core processes, build a new reporting stack, stand up automation, and add new modules all in the same phase is one of the most reliable ways to stall a project that started with real momentum.
A phased approach is not a compromise. It is the smarter path.
- Phase 1: Core migration and stable operations
- Phase 2: Reporting modernization
- Phase 3: Automation and optimization
Business Central is designed for iterative improvement. Organizations that go live with a focused Phase 1 and a clear roadmap for what comes next move faster overall than the ones that try to land everything at once.
What Actually Blows Up GP Migration Projects?
When a GP migration runs over budget, misses its go-live date, or loses the confidence of the business along the way, the cause is almost never the software. It is almost always one of the same five things:
- Scope that was never clearly defined
- Data that was never cleaned
- Design decisions that were made too late or not at all
- Change management that was treated as a training event instead of a program
- Expectations that were set based on best case scenarios instead of realistic ones
Business Central is a capable platform. The organizations that struggle with it are not struggling because of what the software cannot do. They are struggling because of what the project did not plan for.
Final Thoughts: Migration Is a Design Opportunity
A GP to Dynamics 365 migration is not just a system replacement. Done well, it is one of the better opportunities a finance and operations team gets to clean up technical debt, simplify integrations, redesign reporting, and modernize workflows that have not been questioned in years.
The organizations that treat it that way come out ahead. The ones that treat it as a lift and shift, rush the data work, skip the change management, and try to do everything in Phase 1 spend the first year after go-live fixing things that did not need to go wrong.
The mistakes in this post are common. They are also avoidable. The difference is usually how early the right conversations happen
Ready to Avoid These Pitfalls?
Every GP environment is different. Different versions, different customizations, different integration dependencies, different levels of data complexity. The mistakes in this post are common but how they show up in your specific environment is unique to you.
Our team works with GP customers on this transition every day. We know where the complexity tends to hide, what questions to ask before planning begins, and how to build a migration roadmap that accounts for your actual environment rather than an ideal one.
If you are starting to think seriously about your GP migration, that kind of experience is worth having in your corner early.
Schedule a Discovery Call to Discuss Your GP Migration Strategy.
