GP to Business Central: What the Migration Actually Involves

The most common reason GP businesses delay starting their Business Central migration is a combination of two things: the assumption that it will be more disruptive than it needs to be, and the absence of a clear picture of what it actually involves. This guide is an attempt to provide that picture honestly, without either minimising the work involved or overstating the disruption.

Advantage has managed GP to Business Central migrations for UK SMEs across a range of sectors and sizes. The projects that go well are the ones that invested properly in preparation. The projects that encounter problems are almost always the ones that skipped or compressed the Discovery phase. That pattern holds consistently enough to treat it as the single most reliable predictor of migration outcomes.

Why GP to Business Central Is More Straightforward Than Most Migrations

A GP to Business Central migration sits within the Microsoft ecosystem. The underlying data structures, the financial model, and the way transactions are recorded share common heritage. This is not just a theoretical advantage: it means the data mapping from GP to Business Central is well-understood, the migration tools are mature, and implementation partners have done it many times.

Compare this to a migration from a non-Microsoft ERP, where the source and target systems may have fundamentally different approaches to how a transaction is structured, or where there is no established mapping between the two data models. GP to Business Central avoids most of that complexity because both systems come from the same lineage.

The other structural advantage is the Microsoft 365 environment. If your business already uses Outlook, Teams, and SharePoint, Business Central integrates natively with all of them. The user interface patterns are consistent with applications your team already uses. The shift to Business Central is a change of ERP, not a change of technology culture.

Phase One: Discovery

Discovery is the phase that determines the quality of everything that follows. A thorough Discovery covers six areas.

Current GP configuration

The implementation consultant maps your GP setup: which modules are in use, how the chart of accounts is structured, what company structures and inter-company relationships exist, which workflows are active, and how the system has been configured since the original implementation. GP environments typically carry configuration decisions from years ago that were made for reasons nobody currently remembers. Discovery surfaces those and establishes what needs to be carried forward and what can be simplified.

Integrations

Every integration your GP environment has with external systems needs to be documented and assessed. Bank feeds, e-commerce platforms, carrier systems, payroll providers, reporting tools, and ISV add-ons all need individual evaluation. Some will have Business Central equivalents that are better than the GP integration they replace. Others will need to be rebuilt. A small number may require decisions about whether the integration is still needed at all.

Data quality

Data quality in GP environments is often lower than people expect when they look at it systematically. Inactive customers and suppliers with incomplete records. Duplicate item codes from years of growth. Chart of accounts entries that made sense in a previous ownership structure but no longer reflect how the business is managed. Discovery establishes what data quality work is needed before migration. This is not a criticism of how GP has been run; it reflects the reality of any live system that has been in use for a number of years.

Process redesign opportunities

The GP migration is the right moment to redesign processes that have accumulated workarounds over time. Business Central's functionality often makes a process that required manual steps in GP genuinely automatic. Taking the migration as an opportunity to redesign rather than simply replicate typically produces a better outcome and a higher return on the migration investment. Discovery identifies the most significant process improvement opportunities.

Go-live constraints

Every business has periods that make a poor go-live window: year-end, peak season, major contract renewals, key staff absences. Discovery maps those constraints so the project timeline is built around them rather than discovering the conflict mid-project.

Scope agreement

Discovery produces a project scope document that defines what is included in the migration, what the timeline is, and what the project costs. Without this document, a migration has no agreed basis for managing change and no mechanism for keeping the project on track. Any implementation partner who skips Discovery or compresses it significantly is transferring risk to you.

Phase Two: Data Cleansing and Preparation

Data cleansing is the most unglamorous part of a migration and the one most often underestimated. The principle is straightforward: migrating dirty data to Business Central does not solve the data quality problem. It moves it to a new system where it is harder to manage and more expensive to fix.

The data sets that require the most attention in a typical GP migration are the chart of accounts, customer and supplier records, and inventory items. Chart of accounts cleansing typically involves removing codes that are no longer used, consolidating duplicate structures, and mapping GP account codes to Business Central's dimensional analysis framework. Customer and supplier cleansing involves resolving duplicates, completing missing required fields, and removing records that are genuinely inactive.

Inventory item cleansing is the most variable component. A business with a well-maintained item master in GP will have a relatively straightforward migration. A business that has never had a structured approach to item management may need significant work before the data can migrate cleanly.

The cleansing work is done in GP before migration, not in Business Central after go-live. This distinction matters: post-migration data fixes are significantly more expensive and disruptive than pre-migration cleansing.

Phase Three: Business Central Configuration and Testing

With the GP environment mapped and the data prepared, Business Central is configured to match the structure and processes of the business. This phase covers company setup, chart of accounts mapping, workflow configuration, user roles and permissions, approval hierarchies, reporting structures, and integration setup.

Testing runs in parallel with configuration. Each functional area of the business tests its workflows against real data in a Business Central test environment before go-live. Finance tests the purchase and sales ledger processes. The warehouse tests goods receipt and despatch. The commercial team tests order entry and customer management. Issues identified in testing are resolved before go-live, not after.

The migration of historical data runs as part of this phase. A test migration using a sample of real GP data establishes that the mapping works correctly before the final go-live migration is committed.

Phase Four: Go-Live and Stabilisation

The final data migration from GP runs as close to the go-live date as possible, typically over a weekend. This minimises the period between the last data cut from GP and the first live transactions in Business Central. Business Central is live for Monday morning.

Go-live date selection is not arbitrary. The implementation partner works with the business to identify a window with low operational risk: not immediately before month-end, not during peak season, not coinciding with a major customer event. Getting this right is one of the most practically important decisions in the project.

The weeks immediately after go-live are the stabilisation period. Users are working in Business Central for the first time on live data. Questions arise that were not covered in training. Edge cases appear that the testing phase did not encounter. Having the implementation consultant available and responsive during this period is not optional; it is the difference between a smooth landing and a difficult first month.

What GP Data Migrates to Business Central

The data sets that migrate in a standard GP to Business Central project are the chart of accounts with opening balances, customer and supplier master records, item and inventory records, open transactions including outstanding sales orders, purchase orders, and invoices, and a defined period of historical transaction data agreed during Discovery.

Historical data volume is a commercial decision. Business Central can store years of historical GP data, but migrating large volumes of very old transactions adds time and cost to the project. Most businesses choose a practical cut-off, typically two to five years of historical transactions, and archive older GP data in the GP system which is retained in read-only mode for a defined period after go-live.

What Does Not Migrate Automatically

GP customisations do not carry across. Each customisation needs to be assessed against Business Central's standard functionality during Discovery. Many GP customisations address gaps that Business Central handles as standard, making them redundant. Where a genuine business requirement exists that Business Central does not cover natively, it can be rebuilt as a Business Central extension using the AL development framework. The Discovery phase establishes the full customisation picture and the associated scope and cost before any development work begins.

Realistic Timelines

A GP to Business Central migration for a UK SME with a straightforward environment, limited customisations, and clean data typically takes 9 to 12 months from the start of Discovery to go-live. A more complex environment, with significant integrations, data quality work, or process redesign, typically takes 12 to 18 months.

These timelines assume a properly resourced project on both sides: the implementation partner provides the consulting hours the project needs, and the client provides the internal availability for Discovery workshops, data cleansing, testing, and decision-making. Projects that run long almost always do so because one or both of those conditions was not met.

QuickStart Solutions for GP Customers

For GP businesses with a well-defined, lower-complexity environment that want a faster and more predictable path to Business Central, Advantage's QuickStart Solutions provide a structured, fixed-scope route to go-live. QuickStart defines the project scope, timeline, and cost at the outset, removing the open-ended project risk that most businesses are concerned about when they think about migration.

QuickStart is appropriate where the GP environment is relatively standard, customisations are limited, and the business wants to be on Business Central rather than engineering a highly bespoke implementation. It is not appropriate for environments with significant complexity that require a full discovery-led approach. The Discovery conversation establishes which route is right for your specific situation.

The Right Starting Point

If you are considering a GP migration and want to understand what your specific environment would require, the Advantage Transformation Sprint is a free, no-obligation session that maps your current GP setup, identifies the key migration considerations, and produces a clear view of what the project would involve for your business. It is the practical starting point before any commercial commitment to a project timeline or budget.

Contact our GP migration team or call 020 3004 4600.

Related Resources

Frequently Asked Questions — GP to Business Central Migration

Practical questions about what a Dynamics GP to Business Central migration involves, how long it takes, and how to manage the transition.

How long does a GP to Business Central migration take?

A GP to Business Central migration typically takes 9 to 18 months from first conversation to go-live for a UK SME. The range reflects the complexity of the GP environment: the number of integrations, the volume of historical data being migrated, whether customisations are involved, and the extent of process redesign required. Simpler environments using Advantage QuickStart Solutions can achieve go-live in a shorter timeframe with a fixed scope and defined timeline agreed at the outset.

What GP data migrates to Business Central?

The core data sets that migrate from GP to Business Central include the chart of accounts, customer and supplier master records, item and inventory records, open transactions including outstanding invoices and purchase orders, and a defined period of historical transaction data agreed during Discovery. Older historical data is typically retained in GP in read-only mode for a period after go-live so users can reference it without it needing to move.

What happens to GP customisations during a migration to Business Central?

Dynamics GP customisations cannot be carried across directly. Each customisation is assessed during the Discovery phase against Business Central's standard functionality. Many GP customisations address gaps that Business Central handles natively, making them redundant. Where a genuine business requirement exists that Business Central does not cover out of the box, it is rebuilt as a Business Central extension. The Discovery phase establishes the full picture and associated scope and cost before any development work begins.

Will our business be disrupted during a GP to Business Central go-live?

A well-planned go-live is designed to be operationally invisible to customers and suppliers. The final data migration typically runs over a weekend with Business Central live for Monday morning. The go-live date is chosen to avoid month-end, year-end and peak operational periods. For businesses with very low tolerance for go-live risk, a parallel running period on both systems for a defined number of weeks is available, though this adds cost and operational complexity.

GP to Business Central: What the Migration Actually Involves (Honest Guide for UK SMEs)