A Dynamics GP to Business Central migration typically takes 12 weeks across four phases: Initiate, Build, Deploy, and Support. This timeline is based on smaller, less complex GP environments, and it's designed that way intentionally. Larger or more complex migrations follow the same phases and steps, they just take longer. For the purposes of this post, we're talking about a streamlined path forward for organizations that are ready to move without a lot of baggage. Here's what to expect, week by week, no surprises.
I've had conversations with finance teams who are staring down a migration to Business Central and wondering what they've gotten themselves into.
Here's what I tell them: the process is more structured than you think, and the anxiety is almost always worse than the actual experience, especially when you know what's coming. So, let's walk through it. Phase by phase, week by week, so you can stop dreading it and start planning for it.
|
Phase |
Weeks |
Focus |
|
Phase 1: Initiate |
Weeks 1-2 |
Discovery & Planning |
|
|
Weeks 3-4 |
Data Prep & Cleanup |
|
Phase 2: Build |
Week 5 |
Migration |
|
|
Week 6 |
Tailoring |
|
|
Weeks 7-8 |
Testing & Validation |
|
Phase 3: Deploy |
Week 9 |
Cutover Planning |
|
|
Weeks 10-11 |
Training & Alignment |
|
|
Week 12 |
Go-Live |
|
Phase 4: Support |
Days 1-30 |
Post-Launch Support |
This is the phase that quietly determines how the rest of the project goes. I've seen migrations that skipped this work and paid for it later. Don't be that company.
Before anything moves, we take a hard look at your current GP environment, integrations, customizations, chart of accounts, modules, workflows, to figure out what's working, what needs to change, and what should follow you into BC.
In my experience, this step is where we find the surprises. Not the bad kind (usually), just the "oh, I forgot we still had that integration running" kind. Better to find it here than on go-live day.
There's a saying in this business: good data in, good data out. I would add another, bad data in, bad day at go-live. I wrote a blog about data cleanup before migrating, you can check it out here. Migration Starts with a Mop: Preparing for a Move to Business Central
Weeks three and four are about cleaning up your existing data before it moves, out-of-date vendors, inactive accounts, duplicate master data records. The goal isn't just to migrate your data. It's to make sure you're not recreating the same mess in your new system that you've been living with in the old one. This is your chance to start fresh. Take it.
This is where the migration actually happens. By this point the hard thinking is done, and the work shifts to building, moving, and testing.
Your data officially moves into Business Central. The prep work from Phase One earns its keep here. Cleaned, validated, properly structured data means fewer headaches, less rework, and a much smoother transition than you'd get going in cold.
No two businesses run exactly the same way, something I've learned over the years. This week is about configuring your BC environment to match how your business actually operates: integrations, customizations, workflows, and system functionality. The discovery work from Phase One is what makes this feel purposeful rather than improvisational.
This is where your team gets hands-on time with the new system before anyone depends on it. Key users test real business processes, verify permissions and reporting, and work through scenarios in a sandbox environment.
The sandbox is important. I cannot tell you how many times I've watched a team find a critical "that's not right" moment during testing and breathe a collective sigh of relief that it wasn't go-live day. That's exactly what this phase is for.
The final stretch. The system is built and tested, now it's about making sure every user is ready to actually use it.
A cutover plan maps out exactly how and when each workflow transitions from GP to BC. Think of it as the project's game plan for go-live: who does what, in what order, and when. In my experience, the teams that take this seriously have dramatically smoother launches than the ones who wing it.
Key users get hands-on training based on their specific roles and processes. Workflows, integrations, and customizations get their final review. By the end of week eleven, the system isn't just configured, it's ready for real work, and so is your team.
Here it is. Users begin working in Business Central. After twelve weeks of planning, cleaning, building, and testing, this moment tends to be a lot less dramatic than people feared. Which, frankly, is exactly how you want it.
Go-live isn't the finish line, it's the start of a new phase of the relationship.
For the first 30 days, the migration team stays close. The focus is on transaction support and month-end close guidance, which in my experience are the two areas where teams most reliably need a hand after switching systems. Month-end close in a new platform has a way of surfacing questions that might have been overlooked during training.
After that first close cycle, the engagement transitions into Enavate's long-term customer care program, ongoing support as Business Central continues to evolve and your business grows into it.
Want to talk through what a migration would look like for your business? Let's start the conversation.
How long does a GP to Business Central migration take?
Most GP to BC migrations follow a 12-week timeline across four phases: Initiate, Build, Deploy, and Support. The exact timeline depends on data complexity, the number of integrations, and your team's availability for testing and training.
What is the biggest risk in a GP to BC migration?
In my experience, it’s overlooked customizations. This one can catch teams more off guard than almost anything else. GP is incredibly flexible, which means most businesses have accumulated years of customizations, integrations, and workarounds that nobody fully documented and everyone quietly depends on. Discovery in Phase One exists specifically to surface these before they become go-live surprises. Data quality matters too, but bad data announces itself. Undocumented customizations tend to hide until the worst possible moment.
Do users need to be involved during the migration?
Yes, and the earlier the better. Key users are critical during testing and validation in weeks seven and eight, and again during training in weeks ten and eleven. Teams that engage early almost always have smoother go-lives.
What happens after go-live?
The migration team provides 30 days of post-launch support, with a particular focus on transaction help and month-end close guidance. After that, clients move into Enavate's ongoing customer care program.
Can we migrate from GP even if we have heavy customizations?
Yes, but customizations need careful attention during the discovery phase to determine what carries forward, what needs to be rebuilt in BC's native tools, and what may no longer be necessary. That conversation shapes the whole project.
Is Business Central hard to learn if you've been on GP for years?
Honestly? There's a little bit of a learning curve, and I won't pretend otherwise. GP and BC think about things differently, and muscle memory from years on GP doesn't always transfer. But in my experience, most users find their way faster than they expected, especially when training is built into the process the right way. The first month-end close is usually the real test, and once that's behind them, most teams don't look back.