
Quick Answer
A Microsoft Dynamics GP migration to Business Central starts with assessing your GP environment, cleaning and mapping data, configuring Business Central, running a test migration, validating business processes, training users, and completing a controlled cutover before Dynamics GP support ends.
Key Takeaways
- Dynamics GP support ends December 31, 2029, with security updates potentially continuing through April 30, 2031.
- A successful migration starts with process and data assessment before technical migration work begins.
- Customizations, integrations, reports, and historical data all need individual decisions.
- At least one test migration and full user acceptance testing should happen before cutover.
- The project is a good opportunity to retire obsolete GP processes instead of rebuilding everything.
Dynamics GP has been around long enough that many companies have built years of habits around it. Reports, integrations, workarounds, and custom processes all accumulate.
That is why a Dynamics GP migration to Business Central is not simply a matter of copying tables into a new ERP.
Microsoft plans to end Dynamics GP product enhancements, regulatory updates, and technical support on December 31, 2029. Security updates and patches, if needed, remain available through April 30, 2031.
Follow the steps in this guide to make sure your migration to Business Central goes smoothly.
Step 1: Document What You Have Today
Start with an inventory of the current Dynamics GP environment. This means recording your GP version, SQL environment, companies, active modules, third-party products, integrations, reports, SmartLists, customizations, workflows, and scheduled jobs, and more.
Then, talk to the people you put in charge of using them. A technical inventory may show that an integration with GP exists, but only a user can tell you that nobody has trusted it since 2022 and they export the data to Excel instead. Important context like this prevents the new system from being designed around outdated assumptions.
Step 2: Decide What Should Move
ERP databases collect history… but they also collect clutter. Before migrating, review:
- Customers and vendors
- Items and inventory data
- Chart of accounts and account segments
- Open and historical transactions
- Reports and custom fields
- Old companies that may only need archival access
The goal should be to bring forward the data the business needs. You don’t need to preserve every artifact because it exists.
Think Carefully About History
Finance may need prior-year reporting, auditors may require access to old transactions, and operations may need customer or item history. Decide early what belongs in the live Business Central environment and what can remain available through another reporting or archival approach.
Step 3: Design the Business Central Environment
Business Central should not be treated as Dynamics GP with a new interface. Map the processes your teams perform today and decide how they should work after migration. Common areas of necessity that can help businesses like yours include quote-to-cash, procure-to-pay, financial close, banking, inventory, fixed assets, and reporting.
This is also where you review old customizations. A GP customization you previously used may be essential. It may also exist because GP could not handle a process that Business Central now supports through standard functionality, an extension, or Power Platform.
Rebuilding custom code should be a conscious decision your team makes, rather than an automatic reflex because it’s how you did it before.
Step 4: Clean and Map the Data
Do the cleanup before final migration whenever possible.
Merge duplicate records. Standardize naming. Mark inactive records. Fix obvious errors. Confirm which customers, vendors, and items are still relevant. Financial mapping deserves special attention. GP account structures and segments do not always translate directly into the way you want to use Business Central accounts and dimensions. Get finance involved early and validate the mapping before production cutover.
A technically successful migration can still cause problems if balances or reporting structures land in the wrong place.
Step 5: Configure Business Central
With the future state defined, configure the target environment. That can include posting groups, dimensions, number series, taxes, bank accounts, users, permissions, workflows, inventory settings, and required extensions.
Note: Do this in a sandbox or migration environment. Microsoft warns against running cloud migration into a production environment already being used for business because migration processes can overwrite data.
Step 6: Run a Test Migration
Microsoft provides cloud migration tooling for moving supported Dynamics GP environments into Business Central online. Use it before the real cutover date gets close. A test migration gives your team room to find mapping issues, missing records, data-quality problems, and integration surprises while GP remains the production system. After replication and data upgrade, validate the migrated data against the source.
Do Not Stop at Record Counts
A matching customer count is encouraging, but it does not, on its own, prove the business is ready to operate.
As part of your testing process, run real scenarios such as:
- Entering and posting a sales order
- Receiving a purchase order
- Applying customer and vendor payments
- Reconciling a bank account
- Running month-end reports
Include unusual cases as well as the happy path.
Step 7: Train Users and Fix What Testing Finds

Business Central is more modern than GP, but users still need time to learn where their work moved.
Train by role – accounts payable should practice AP, warehouse users should work through inventory activity, and managers should know how approvals and reporting work. Track issues from user acceptance testing, assign owners to address them, and retest fixes.
Step 8: Plan the Cutover
Choose the point when Dynamics GP stops being the system of record and document what is going to happen as part of this process. Your cutover plan should cover final transactions, migration timing, reconciliation, integration switching, user access, go/no-go criteria, and post-launch support.
After the final migration, reconcile critical balances before normal activity gets too far ahead. Many companies also retain GP in a read-only capacity based on reporting, audit, and retention needs.
Start Before the Deadline Starts Driving the Project
December 2029 may sound far away, but ERP projects have to compete with budgeting, year-end, staffing, audits, and other business priorities. IES helps organizations assess Dynamics GP environments, plan and execute Business Central migrations, configure integrations, and support the new system after go-live.
Starting early gives you the freedom to make good decisions instead of deadline-driven ones. Contact IES today to start the process for your business before the deadline gets too close.
GP to BC Migration: FAQs


