top of page
Search

How Long Does a GP to Business Central Migration Take?


This is Part 3 of our 5-part series on migrating from Dynamics GP to Business Central.


Read the full series:

One of the first questions we get from GP users considering a migration is simply: how long is this going to take? It is a fair question, and the honest answer is that it depends - but not in a vague, unhelpful way. There are specific factors that drive the timeline, and understanding them helps you plan realistically.


The Baseline: 3 to 6 Months


For most small and mid-sized businesses migrating from GP to Business Central, a well-managed implementation runs between three and six months from kickoff to go-live. That range covers the majority of straightforward to moderately complex implementations.


This timeline assumes a structured approach: a proper discovery phase, data preparation, configuration and testing, user training, and a planned go-live. It is not a timeline for a rushed or under-resourced project.


What Drives a Migration Toward 3 Months


Implementations on the shorter end of the range tend to share a few characteristics. The company has a relatively clean GP environment - fewer customizations, fewer third-party ISV add-ons, and data that has been reasonably maintained over time. The scope is focused: core financials, basic inventory, standard purchasing and sales. Leadership is aligned and decision-making is fast. And the organization can dedicate internal resources to the project rather than asking the same people to run the business and manage the migration simultaneously.


What Pushes a Migration Toward 6 Months or More


Complexity adds time in predictable ways. Each of the following typically adds weeks to the timeline:


Data complexity. If your GP data has years of accumulated issues - duplicate records, inactive accounts that were never cleaned up, inventory quantities that don't match physical reality - data preparation takes longer. This is not a reason to avoid migration; it is a reason to start earlier.


Customizations. GP implementations that relied heavily on customized reports, modified forms, or third-party ISV solutions require more discovery time upfront and more configuration work in Business Central. Some customizations have direct equivalents in BC; others need to be rethought rather than replicated.


Number of companies or locations. Multi-entity or multi-location implementations take longer because configuration decisions compound - chart of accounts mapping, intercompany transactions, and reporting structures all need to be designed carefully.


Process redesign scope. Migrations that treat the project as an opportunity to rethink business processes - not just move from one system to another - take longer but deliver significantly better outcomes. The time spent on process redesign before configuration begins pays back many times over in user adoption and system performance.


Older GP versions. Companies on GP 2015 or later can use Microsoft's automated Cloud Migration Tool. Companies on older versions require a manual migration path, which is more labor-intensive and adds time. (We cover the automated vs. manual decision in detail in Part 4 of this series.)


The Four Phases and How Long Each Takes


A well-structured GP to BC migration moves through four phases. Here is a realistic breakdown of where the time goes:


Phase 1 - Discovery (2 to 4 weeks). This is the assessment phase: auditing your current GP environment, documenting modules and customizations, evaluating your data, and defining the scope and design of your Business Central implementation. Done properly, this phase prevents surprises later. Skipping or rushing it is one of the most common causes of project delays.


Phase 2 - Data Preparation and Configuration (4 to 10 weeks). This is typically where the most time is spent. Data cleansing, chart of accounts mapping, Business Central configuration, and setting up integrations with other systems all happen here. The range is wide because data complexity varies so much between organizations.


Phase 3 - Testing, Training, and Go-Live (3 to 6 weeks). User Acceptance Testing (UAT) to validate data integrity and system function, user training, cutover planning, and the go-live itself. The go-live should be scheduled during a low-activity period - ideally a weekend or around a period-end - to minimize disruption.


Phase 4 - Post-Go-Live Stabilization (2 to 4 weeks). The first few weeks after go-live always surface things that need adjustment. Budget time and support resources for this phase. It is not a sign that something went wrong; it is a normal part of any ERP implementation.


A Note on Timing Your Start


Given that most implementations take three to six months, and given that GP's support window closes in stages between 2029 and 2031, organizations that want to migrate in a controlled, well-paced way should be starting their planning process in the next one to two years - not in 2030.


The companies that will struggle are those that wait until the timeline forces their hand. By 2029 and 2030, the pool of available BC implementation partners will be stretched thin by the volume of GP customers all trying to migrate simultaneously. Starting now means more partner availability, more time to do it properly, and no pressure to cut corners.

Next in This Series


In Part 4, we get into the technical side: the two migration paths available - automated and manual - and how to decide which one is right for your GP environment.



Evolve Strategy & Capital Inc. is a senior Microsoft Dynamics 365 Business Central consulting firm based in Calgary, specializing in inventory-intensive organizations. We have completed 30+ Business Central implementations and have direct experience with GP to BC migrations. Start a conversation with our team to understand what a realistic timeline looks like for your specific environment.

 
 
 

Comments

bottom of page