The process involves assessing your existing GP environment, deciding what data and functionality should move, preparing Business Central, migrating and validating the data, testing business processes, and completing the final cutover. Microsoft provides cloud migration tools specifically for supported Dynamics GP environments moving to Business Central online.
But a successful migration is not simply a matter of transferring data from one ERP to another. It is an opportunity to remove outdated customizations, rethink reporting and dimensions, replace legacy integrations, and give users a more modern way to manage finance and operations.
For organizations still running Dynamics GP, planning ahead is particularly important. Microsoft currently lists Dynamics GP as retiring on January 1, 2030, with product enhancements, regulatory/tax updates, and technical support ending December 31, 2029. Security updates may continue through April 30, 2031.
Table of Contents
What Is a Dynamics GP to Business Central Migration?
A Dynamics GP to Business Central migration moves supported data from an on-premises Dynamics GP environment into Business Central online.
Microsoft's cloud migration process establishes a connection between the on-premises SQL Server environment and Business Central online. Data is replicated to the online environment, upgraded into the Business Central data structure, validated against the source data, and then finalized for production use.
However, the technical migration is only one part of the project. A business may also need to decide what happens to GP customizations, third-party applications, integrations, historical information, reports, workflows, and processes that have developed around GP over the years.
In our experience with Dynamics implementations, those decisions often have a greater impact on the project than the data transfer itself.
Why Are Businesses Moving from Dynamics GP to Business Central?
Business Central gives organizations a cloud-based ERP platform that Microsoft continues to develop across financial management, sales, purchasing, inventory, projects, services, manufacturing, reporting, and integrations.
For a GP customer, the move can also reduce dependence on older customizations and infrastructure while providing access to Microsoft's broader cloud ecosystem.
The timing matters, too. With GP's support lifecycle approaching its end, organizations have an opportunity to migrate on their own schedule rather than waiting until support deadlines create unnecessary pressure.
Make the Move to Business Central With Dynamics Square USA
Prepare your Dynamics GP data, integrations, and business processes for a smooth transition to Business Central.
8 Steps to Migrate from GP to Business Central
A GP-to-Business Central migration typically follows eight connected stages: assessment, data planning, solution mapping, customization and integration review, environment preparation, test migration, validation, and production cutover.
1. Assess Your Dynamics GP Environment
Before moving anything, establish exactly what your GP environment contains.
Microsoft provides a Dynamics GP migration assessment tool to help identify potential migration issues and evaluate readiness.
The assessment should look beyond the database. Review the GP version, companies, modules, SQL environment, customizations, ISV solutions, integrations, reports, workflows, dimensions, historical data, and critical processes.
This is often where hidden migration complexity appears. A company may discover, for example, that a supposedly standard purchasing process actually depends on a third-party GP application or a custom integration.
Finding those dependencies before the migration is far easier than discovering them after go-live.
2. Decide What Data Should Move
One of the biggest mistakes in an ERP migration is assuming that every record in GP must be transferred.
Instead, classify information according to how the business will use it in Business Central. Active customers, vendors, inventory, open receivables, open payables, and other operational information may need to be available immediately. Older records may be better handled as historical information or retained in an accessible archive.
Microsoft's migration tools support a range of GP information, including master data, open transactions, inventory information, bank/checkbook information, purchase orders, vendor 1099 information, and selected historical data.
The key distinction is between operational data and historical data.
For example, an organization may need its current customer balances and open invoices in Business Central, while older transactions may only need to remain available for audit, reporting, or reference.
3. Map GP Data to Business Central
The next step is deciding how GP's structure will translate into Business Central.
This is especially important for the chart of accounts and dimensions. GP commonly uses account segments, while Business Central uses the G/L account structure together with dimensions. Microsoft documents mapping the GP main account segment to the Business Central account number and using other GP segments as dimensions where appropriate.
The objective should not be to reproduce every GP configuration exactly.
Instead, ask whether the existing structure still supports the organization's reporting and financial-management requirements.
Migration may therefore be the right time to simplify an unnecessarily complex chart of accounts, rationalize dimensions, or redesign reporting.
4. Review Customizations and Integrations
This is one of the most important stages because many long-running GP environments contain functionality that users consider "part of GP" even though it actually comes from custom development, an ISV application, SQL processes, or an external integration.
Create an inventory of the systems that depend on GP and determine whether each one should be retired, replaced, integrated with Business Central, or rebuilt.
Typical areas include:
Payroll and banking
E-commerce and CRM
EDI and warehouse systems
Tax applications
Reporting and BI
Third-party GP applications
Custom reports and workflows
Do not automatically recreate every GP customization. Business Central may already provide the required capability, or an existing Business Central extension may provide a better solution.
5. Prepare GP and Business Central
Once the target design is agreed, the source and destination environments can be prepared.
Microsoft's cloud migration architecture connects the GP environment with Business Central online and uses Azure-based services to transfer the data.
Preparation should include the required GP prerequisites, Business Central configuration, company selection, user access, backups, and a controlled migration environment.
Avoid treating the production migration as an experiment. Establish a test environment first, document the configuration, and control changes to the GP source while migration testing is underway.
6. Run a Test Migration
The first migration should be a rehearsal.
A test run shows whether the data structure, mappings, customizations, integrations, and business processes work as expected before the production cutover.
The project team should reconcile areas such as:
General Ledger balances
Customer and vendor balances
Inventory quantities
Bank information
Open purchase orders
Dimensions
Historical information
Financial reports
Users should also perform their normal daily tasks in Business Central. A migration can be technically successful while still failing from a user's perspective if employees cannot complete the processes they rely on.
7. Replicate, Upgrade, and Validate
The technical migration consists of several distinct activities.
First, the GP data is replicated into Business Central. Microsoft provides migration-management tools for monitoring migration runs and identifying successful or failed tables.
The replicated data then goes through the Business Central data-upgrade process. Microsoft specifically cautions against simply rerunning replication after a successful data upgrade because mixing upgraded and non-upgraded records can result in data problems.
Finally, validation checks help compare the source GP information with the migrated Business Central data. Microsoft provides validation tests for areas including G/L accounts, bank accounts, customers, items, purchase orders, vendors, and 1099 information.
This distinction is important: a completed migration is not the same thing as a validated migration.
8. Complete the Cutover
Once testing and reconciliation are complete, the organization can plan the production cutover.
The final stage normally involves freezing or controlling transactions in GP, completing the final migration, validating the results, configuring users and permissions, confirming integrations, and moving employees onto Business Central.
The organization should also retain appropriate GP backups and historical access according to its accounting, legal, audit, and internal requirements.
The goal is a controlled transition rather than simply switching systems on a particular date.
What GP Data Can Be Migrated to Business Central?
Microsoft's current documentation identifies several GP data categories that can be migrated through cloud migration tools, including fiscal periods, chart of accounts master records, customers and outstanding receivables, vendors and outstanding payables, inventory items, units of measure, and checkbook master and transaction data.
Business Central can also use the GP Historical Snapshot capability for selected historical GP information. This gives organizations another way to make relevant historical information available after moving to Business Central rather than treating every old transaction as current operational data.
The exact migration scope should be determined during the assessment because data requirements vary by company, reporting needs, compliance obligations, and the structure of the GP environment.
What Are the Biggest Challenges When Migrating GP to Business Central?
The biggest challenges are usually not limited to the technical transfer.
Data quality can make a migration unnecessarily complex if obsolete records are carried forward without a business reason.
Financial mapping requires care because GP account segments and Business Central dimensions are structured differently.
Customizations and integrations need individual assessment because they may not have a direct one-to-one replacement.
Historical data needs a deliberate strategy so that the organization retains what it needs for reporting, audit, and reference.
User adoption is equally important. Business Central is a different application, so users need to understand how their actual GP processes translate into the new system.
For organizations in the USA, these decisions should be made well before the final cutover. The additional planning time can help avoid treating Microsoft's GP support deadline as an emergency migration deadline.
Why Choose Dynamics Square USA for Your GP-to-Business-Central Migration?
GP migration can look straightforward from the outside. Inside the project, however, the details quickly become more complicated. Finance may depend on a particular report, operations may rely on a third-party application, and years of historical information may need to remain accessible. This is where implementation experience becomes valuable.
Dynamics Square is a Microsoft Solutions Partner, founded in 2011, with 14+ years of experience, 500+ implementations, and 150+ Microsoft-certified consultants, with a presence in the USA, UK, and Canada.
For a USA-based organization, that means the migration conversation can start with the existing GP environment and the business processes that actually need to continue, rather than beginning with a generic Business Central configuration.
Dynamics Square USA can support the broader migration journey, including assessment, Business Central design, data migration, integrations, customization, testing, training, and post-go-live support.
Frequently Asked Questions
Yes. Microsoft provides cloud migration capabilities for supported Dynamics GP on-premises environments moving to Business Central online. The process includes migration setup, data replication, data upgrade, validation, and completion.
There is no single timeline that applies to every organization. Microsoft notes that migration duration depends on factors such as the number of companies, data volume, and migration approach. The best way to estimate a project is to complete the assessment and planning stages first.
Yes. Microsoft supports a GP Historical Snapshot for selected historical GP information. The appropriate historical-data strategy depends on the organization's reporting and business requirements.
No. Customizations and third-party applications need to be assessed individually. Some may be replaced with standard Business Central functionality, while others may require extensions, integrations, or redevelopment.
Microsoft states that Dynamics GP support for product enhancements, regulatory and tax updates, and technical support ends on December 31, 2029. Security updates and patches, if needed, are available until April 30, 2031. Microsoft's lifecycle page lists January 1, 2030 as the retirement date.
Also read: Dynamics GP End Of Life
Start with a GP migration assessment. Identify the companies, data, customizations, integrations, historical requirements, and critical processes before deciding what the Business Central environment should contain. Microsoft's assessment tool is specifically designed to help determine migration readiness and identify potential issues.
