Dynamics GP to Business Central Migration: IT Manager's Checklist

Microsoft's end-of-mainstream-support deadline for Dynamics GP has turned a slow-burning IT conversation into a boardroom priority. If you are an IT manager or CTO sitting on a GP environment — possibly layered with SalesPad, Mekorma, or a decade of custom Dexterity code — you already know that "just migrate to Business Central" is not a plan. It is a wish. This post gives you the replicable, decision-maker-ready framework that most migration guides skip: the data layer risks, the feature parity map, the parallel-run playbook, and the honest criteria for when Business Central is the right landing zone versus when Dynamics 365 Finance & Operations is actually cheaper at scale.

Why Dynamics GP Migrations Fail at the Data Layer

The most expensive surprises in any GP migration do not happen during the go-live weekend. They happen three months earlier, when the integration architect opens the GP database for the first time and finds what the business has built on top of the vanilla product over fifteen years.

ISV Dependencies That Business Central Cannot Simply Absorb

GP's extensibility model allowed ISVs to write directly against the Great Plains SQL database using Dexterity, eConnect, or direct table manipulation. Business Central's extension model is entirely different — it runs on AL code against an abstracted data layer, and no GP ISV product migrates automatically. Before you begin any migration project, audit every third-party product in your GP stack against its Business Central AppSource equivalent.

• SalesPad / Cavallo: Deeply embedded sales order entry and inventory workflows. The AppSource ecosystem has replacements (Cavallo's own BC version, Insight Works), but workflow parity must be validated screen-by-screen, not assumed.
• Mekorma MICR / Payables: Check printing and payables automation. Business Central's native payment journals cover basics; advanced batch approval workflows require Mekorma's BC extension or a Power Automate rebuild.
• Binary Stream MEM: Multi-entity management is a flagship GP ISV feature. Business Central handles multi-company natively but with different intercompany posting logic. Transactions that flow automatically in MEM may require manual journal entries or a third-party BC extension until your team rebuilds the logic.
• Custom Dexterity / VBA Macros: These have zero migration path. Every customization must be re-evaluated: retire it, rebuild it in AL extensions, or replace it with a Power Platform flow.

Legacy Integrations: The Hidden Debt

GP environments that have been in production for more than eight years almost always carry integrations built on Integration Manager, eConnect web services, or flat-file FTP drops into the GP SQL tables. None of these integration patterns work in Business Central. BC uses OData APIs, Business Central web services, and AL-based APIs. Map every inbound and outbound data flow before migration starts, and budget rebuild time for each one. A conservative estimate for a mid-market manufacturer is 40 to 120 hours of integration rebuild per connected system.

Your Data Layer Audit Checklist

• ☐ Export a full list of GP modules in use (run SELECT * FROM DYNAMICS..SY01500 to pull installed modules)
• ☐ Document every ISV product, version, and its Business Central equivalent status
• ☐ Identify all SQL Agent jobs, SSRS reports, and stored procedures that touch GP tables directly
• ☐ Map all inbound integrations (EDI, CRM, WMS, e-commerce) and their current connection method
• ☐ Catalog all outbound exports (payroll processors, 3PL feeds, banking files) and validate BC API equivalents
• ☐ Run a Dexterity customization report and flag every modified form and table
• ☐ Assess historical data volume: years of open transactions, closed transactions, and attachments to determine migration vs. archive strategy

Side-by-Side Feature Parity Map: GP + SalesPad vs. Business Central in 2026

One of the most common mistakes IT managers make is assuming Business Central is a feature-for-feature replacement for a heavily customized GP environment. In many areas it is. In some areas it exceeds GP. In a few critical areas, you will need AppSource extensions to close the gap.

The key takeaway: Business Central in 2026 closes most of the GP feature gap natively, but distributors and manufacturers running SalesPad-heavy workflows will need a deliberate AppSource extension strategy, not a one-size-fits-all BC implementation.

Phased Cutover Framework for Manufacturers and Distributors

Running GP and Business Central in parallel sounds simple in a slide deck and is genuinely complex in production. Here is a phased framework that mid-market manufacturers and distributors have used to make parallel operation manageable without doubling the support burden on an already stretched IT team.

Phase 1: Stabilise and Isolate (Months 1–2)

• Freeze GP customisations — no new Dexterity work, no new SQL integrations
• Complete the data layer audit (checklist above)
• Stand up the Business Central sandbox environment and begin AL extension development for critical customisations
• Document current GP chart of accounts and dimension structure; design the BC dimension mapping

Phase 2: Data Migration Dry Runs (Months 3–5)

• Use Microsoft's built-in GP Cloud Migration Tool (available in BC administration) for initial data lift — it handles master data, open transactions, and historical balances
• Run at least two full dry-run migrations and reconcile trial balances between GP and BC down to the penny
• Rebuild integrations in the BC sandbox and test against real transaction volumes
• Train super-users on BC workflows in parallel — do not wait until go-live month

-- GP Cloud Migration Tool prerequisite check
-- Run in GP SQL database before initiating migration
SELECT DB_NAME() AS [Database],
       COUNT(*) AS [Open Transactions]
FROM   SOP30200
WHERE  VOIDSTTS = 0
  AND  SOPTYPE IN (2,3)
  AND  BACHNUMB = ''
ORDER BY 1;
-- Any unposted batches must be cleared before migration tool runs

Phase 3: Parallel Run (Months 6–7)

• Go live in Business Central for new transactions only in one business unit or legal entity
• Maintain GP for historical lookups and open period close — do not ask users to enter data twice
• Designate a single GP-to-BC reconciliation owner who checks daily transaction counts and GL balances
• Set a hard parallel-run end date of 60 days maximum — longer than that and the business stops taking BC seriously

Phase 4: Decommission and Archive (Month 8+)

• Archive GP SQL databases to Azure Blob Storage (read-only access via SSRS or a legacy reporting VM)
• Redirect all user historical queries to BC's built-in ledger entries or a Power BI historical dataset
• Terminate GP licence subscriptions only after confirming audit and compliance data retention requirements are met

Decision Criteria: Business Central vs. Finance & Operations

Not every GP customer should land on Business Central. Microsoft's messaging sometimes obscures this, but the decision criteria are actually quite clear once you look at the numbers and operational complexity honestly.

Choose Business Central When:

• Annual revenue is under $500M and you operate in fewer than 10 legal entities
• Your manufacturing complexity is discrete or light process — not high-volume batch or regulated pharmaceutical
• Your total ERP user count is under 300 named users
• You need to be live within 6 to 9 months — BC implementations run faster and at lower professional services cost
• Your IT team is small and you need a SaaS model with Microsoft managing the infrastructure

Consider Finance & Operations When:

• Revenue exceeds $500M or you have significant global entity complexity (15+ legal entities)
• You run advanced process manufacturing, catch-weight inventory, or regulated production environments
• You require advanced demand planning, Master Planning (MRP II), or Warehouse Management System capabilities at scale that AppSource extensions cannot cost-effectively deliver in BC
• Your total cost of ownership analysis shows F&O licence costs are offset by lower customisation spend — this happens at scale when the out-of-box F&O feature depth eliminates the need for multiple AppSource extensions

The honest truth: For the majority of GP's installed base — mid-market manufacturers and distributors under $500M in revenue — Business Central is the correct landing zone. F&O's implementation timelines (12–24 months), licence costs, and complexity overhead are genuinely not justified below that threshold. The cases where GP customers should go to F&O are real but represent a minority of the installed base.

Your Pre-Migration Technical Readiness Checklist

Before you engage a Microsoft partner or issue an RFP, use this checklist to assess your organisation's readiness and frame the conversation accurately.

• ☐ Data Audit Complete: ISV inventory, integration map, and customisation catalogue documented
• ☐ Feature Gap Analysis Done: GP + ISV capabilities mapped against BC native + AppSource equivalents
• ☐ Historical Data Strategy Decided: Full migration, selective migration, or archive-and-access model chosen
• ☐ BC vs. F&O Decision Made: Based on revenue, entity count, manufacturing complexity, and TCO
• ☐ Integration Rebuild Scoped: Every connected system assessed and rebuild hours estimated
• ☐ Chart of Accounts Redesign Started: BC dimension model designed before migration, not during
• ☐ Parallel Run Duration Agreed: Hard end date set with executive sign-off
• ☐ Super-User Training Plan in Place: Training begins in Phase 2, not Phase 3
• ☐ GP Licence Retirement Date Set: Drives urgency and prevents indefinite parallel operation
• ☐ Partner Selected with GP Migration Experience: Verify the partner has completed GP-to-BC migrations specifically — not just greenfield BC implementations

Conclusion

Dynamics GP migrations fail when organisations treat them as software upgrades instead of what they actually are: ERP re-implementations that happen to carry fifteen years of business logic, custom code, and integration debt into a fundamentally different architectural model. The IT managers and CTOs who navigate this successfully are the ones who do the unglamorous audit work first, make the BC-versus-F&O decision with real data, and run a time-boxed parallel operation instead of an open-ended one.

At CRMONCE, we work with manufacturers and distributors across India and the broader Microsoft partner ecosystem to design and execute GP-to-Business Central migrations that account for exactly the complexity described in this checklist. If you are past Microsoft's mainstream support window and ready to build a migration plan that actually holds up under technical scrutiny, reach out to our team for a no-obligation readiness assessment.

This post references and expands on Microsoft's official Dynamics GP to Business Central migration documentation and the GP Cloud Migration Tool available in the Business Central administration centre. Always validate feature parity and licence costs with your Microsoft partner against the current release wave, as Business Central receives two major updates per year.