For business leaders, staying on Dynamics GP increasingly means accepting limitations around reporting, integrations, scalability, and operational visibility. As cloud ERP adoption grows, these constraints can make it harder to respond quickly to changing business needs.
Business Central brings financial reporting, day-to-day processes, and business data together on a modern cloud platform that can grow with your organization. Still, moving from GP is not as simple as switching systems. You also need to decide what data to carry forward, how workflows should change, which financial controls must remain in place, and how to keep operations running during the move.
Did you know, Dynamics GP support is approaching its end?
Microsoft has set December 31, 2029, as the end of mainstream support for Dynamics GP, followed by a limited security update period until April 30, 2031. Businesses can continue using GP, but they should plan for the implications of losing regular product enhancements, tax and regulatory updates, and standard technical support. Read our detailed Dynamics GP end-of-support guide.
The concern shouldn’t be only around moving, “how to move without disrupting operations” must be emphasized instead. The checklist below covers the practical decisions involved in moving to Dynamics 365 Business Central – from reviewing existing data and validating financial records to testing workflows and preparing teams for the move to Business Central.
Migrate from Dynamics GP to Business Central in 15 Steps
1. Define What the Business Needs From the Migration
Don’t start by asking “What data do we move?”. Start with why. Are you migrating because you need cloud infrastructure for remote teams? Because your financial reporting is too slow? Because integrations are costing you engineering time? Because you want to scale without adding more customizations?
The answer determines what you actually build in Business Central.
Leadership question: What business outcome should Business Central deliver that GP cannot?
2. Assess Whether Your GP Environment Is Ready to Move
Before you move, you need know what your are actually carrying into the new platform. For that, you must run Microsoft’s migration assessment. Understand your GP version, database environment, modules in use, customizations, integrations, and data quality. Identify where the technical debt lives. This helps assess risk before you’re committed to a timeline.
Leadership question: Do we know what’s blocking a smooth migration?
3. Confirm the Technical Prerequisites Before Committing to the Timeline
Technical incompatibility discovered late becomes a budget problem, a schedule problem, and a go-live problem.
Your team might be ready to move from Dynamics GP to Business Central, only to find that the existing setup needs an upgrade before migration can begin. An older GP version or an incompatible SQL Server configuration can add work, increase costs, and delay the planned go-live date. Reviewing your current GP version, SQL Server requirements, and target Business Central environment early gives you time to resolve compatibility issues before they disrupt the migration.
Leadership takeaway: Validate technical feasibility before locking in migration dates.
4. Identify What Should Be Retained, Replaced or Redesigned
You have GP modules, customizations, ISV solutions, reports, and integrations built over years. Not all of it should move forward. Classify everything: Retain, Replace, Redesign, or Retire.
Some customizations don’t exist in Business Central natively. Some should be retired because they solved problems that no longer exist. Some need to be redesigned for modern workflows.
Leadership question: Are we modernizing the ERP, or just rebuilding yesterday’s system on a new platform?
What this looks like in practice: During Redwood Retail’s move from Dynamics AX to Business Central, Intelegain reviewed the heavily customized legacy environment, removed redundant code, and rebuilt only the specialized functionality the business still needed. Although the source platform was AX rather than GP, the lesson is directly relevant: do not carry every legacy customization into Business Central.
5. Revisit Business Processes Before Recreating Them in Business Central
Switching between enterprise resource planning systems creates an opportunity to review and improve existing business processes. Suppose your team has been using a multi-step approval process in Dynamics GP for years. Over time, extra spreadsheets, manual checks, and workarounds may have become part of the routine. During migration, it can be tempting to recreate that entire process in Business Central simply because everyone is used to it.
Instead, take a step back and ask what is still necessary. Review processes such as procure-to-pay, order-to-cash, financial close, inventory management, approvals, and reporting before rebuilding them. Otherwise, you may move to a new ERP while bringing many of the old inefficiencies with you.
Key message: Don’t migrate legacy complexity. Simplify it.
6. Decide Which Data the Business Actually Needs
Say your GP database goes back to 2012 and contains thousands of customers and items that have not been used in years. Do they all need to move? Probably not. Bring across the data the business still relies on, such as active master data and open transactions, rather than making the migration heavier with information that may never be used.
Critical decision: What moves, what gets archived, and what stays accessible outside Business Central?
7. Build a Data-Mapping Strategy Before Migration Begins
GP and Business Central have different structural assumptions. GP account segments become Business Central G/L accounts plus dimensions. Customers and vendors map differently. Items need reclassification. Fixed assets structure changes.
Poor mapping affects financial reporting and controls after go-live.
Leadership takeaway: This isn’t just IT housekeeping. It’s financial accuracy.
8. Clean the Data Before It Enters the New ERP
Imagine migrating a customer list only to find the same customer appears three times under slightly different names. By adding vendors, obsolete items, and incomplete records, you are moving those old data issues simply move with you. Sort out everything before migrating: clean up duplicates, outdated records, and inconsistencies so Business Central starts with data your teams can actually rely on.
Strong principle: Clean before you migrate.
9. Decide How Much Historical Data the Business Needs
Finance needs historical records for audits. The business might need transaction history for reporting. But does everything need to be searchable in Business Central?
Many organizations archive historical data separately, keeping only what’s operationally necessary in the new system.
Leadership question: Do we need all historical GP data in Business Central, or simply reliable access to it outside the platform?
10. Protect the Business Ecosystem Around GP
A successful ERP go-live means little if the systems around it stop working. Imagine Business Central is live, but your ecommerce orders, warehouse updates, or reporting data are not flowing as expected. That disruption can affect everyday operations immediately. Identify every system connected to your ERP and make integration readiness part of the cutover plan.
Critical insight: Technical go-live and business go-live are different moments.
Why integration readiness matters: In Ketto’s migration from Dynamics NAV to Business Central, Intelegain connected the donation platform, payment gateways, and bank-settlement processes to the ERP. Transaction flows were tested before cutover, showing why integration readiness must be treated as a business priority rather than a final technical check.
11. Configure Business Central Around the Future Operating Model
Avoid rebuilding your old GP setup in Business Central simply because it is familiar. Use the move to rethink workflows, approvals, permissions, and financial structures based on how the business needs to operate going forward.
12. Test the Business, Not Just the System
The real question before go-live is not simply, “Did the data migrate?” but “Can we run the business?” Test complete workflows, from processing orders and payments to approvals, reporting, and month-end close. This gives you a much clearer view of whether Business Central is ready for everyday operations.
Leadership question: Can the business operate in Business Central before we turn off GP?
A proven approach to validation: For Wonderchef’s migration from Dynamics NAV to Business Central, Intelegain cleansed and mapped historical data, rebuilt integrations, embedded Power BI reporting, and completed user acceptance testing and parallel validation before go-live. The published case study reports no migration downtime or data loss.
13. Reconcile Financials Before Giving the Go-Ahead
Remember, the final go-live decision should come only after the financials have been reconciled. If balances in Business Central do not match GP, resolve the differences before cutover. Reconcile the general ledger, receivables, payables, inventory, bank balances, fixed assets, and open transactions so the business enters the new system with confidence in its numbers.
Go-live principle: No financial sign-off means no go-live.
14. Plan the Cutover Around Business Continuity
How many hours can your finance team work offline? How much transaction disruption can the business tolerate?
Plan cutover windows accordingly. Final validation, transaction freeze, backup, migration, data upgrade, validation, user access activation.
Leadership focus: How long can the business operate without GP?
15. Stabilize the Business Before Retiring GP
Going live with Business Central does not mean GP should disappear immediately. You may still need GP for reference while the problem is investigated. Give the new environment time to settle, resolve early issues, reconcile the financials, and make sure critical processes are working reliably before retiring GP.
Leadership question: When is the migration actually complete?
Answer: when the business operates reliably in Business Central, not when it goes live.
5 Dynamics GP to Business Central Migration Risks Leaders Should Watch
Legacy complexity carried forward. Years of GP customizations and workarounds migrated into Business Central instead of modernized.
Poor data quality affecting decisions. Duplicate or incomplete master data corrupts reporting after go-live.
Critical integrations failing after launch. Banking, payroll, CRM, or warehouse systems disconnected because integration testing happened too late.
Financial discrepancies discovered post-go-live. Mapping errors or incomplete reconciliation surfaces in month-end close.
Underestimated change management. Users struggle because training was insufficient or process changes weren’t clear.
How to Know Your Business Is Ready for GP-to-Business-Central Go-Live
Before cutover, confirm these checkpoints:
- Migration objectives met
- Critical data validated
- Financial balances reconcile
- Critical integrations working
- Users trained and confident
- Business processes passed testing
- Security and permissions configured
- Cutover plan approved
- Business owners signed off
- Post-go-live support resourced
Treat Migration as a Business Transformation
The measure of a successful migration is simple: the business operates reliably on Business Central with clean data, validated processes, functioning integrations, and unquestionable financial accuracy.
Treat this as an opportunity to simplify legacy complexity, strengthen controls, and prepare for future growth. That turns an ERP transition into a business improvement initiative.
At Intelegain, our experience across complex Business Central migrations helps us anticipate technical risks and structure the transition around business continuity.
Need a realistic assessment of your GP environment and migration pathway?
We’ll map your current state, identify technical and business blockers, and show you what a smooth transition looks like for your organization.
FAQs
The price is not fixed, it may vary based on factors like the size of your GP environment, the amount of data to migrate, existing customizations, integrations, licensing, and training requirements. A review of your current setup can help identify the work involved and provide a more realistic estimate before the project begins.
For migrating, there is no one-size-fits-all timeline. The duration depends on the current GP setup and how much work is needed to get it ready for the move. A simpler environment could be migrated within a few months, while multiple companies, customizations, integrations, and extensive testing can stretch the timeline. A readiness assessment gives you a much more realistic starting point for planning the migration.
Microsoft's cloud migration tools can bring across core GP data including fiscal periods, chart of accounts, customers, vendors, inventory items, open receivables and payables, checkbook data, and historical information. Businesses can also configure the migration scope, including how many historical years to move. Custom or specialized data may need a different migration approach.
There isn't one standard downtime window because the cutover depends on the size and complexity of the GP environment and the final validation required. Microsoft supports repeated data replication, with later runs generally copying only data changed since the previous replication. A well-planned cutover should account for the final transaction freeze, reconciliation, validation, and user access before Business Central becomes the live system.
They shouldn't automatically be recreated in Business Central. Review each customization, integration, and report to decide whether it still serves a business need and should be retained, replaced, redesigned, or retired. Some legacy functionality may require redesign or separate migration work, making the move a good opportunity to remove complexity that has accumulated in GP over the years.
Get Your Business Central Migration Plan
