Dynamics GP to Business Central Migration: 2026 Data Mapping Playbook

You have already made the decision. Dynamics GP is heading toward end of mainstream support, the 2026 extended support boundary is closing fast, and your organization is committed to moving to Microsoft Dynamics 365 Business Central. The strategic roadmap conversation is behind you. What sits in front of you now is far more demanding: the line-by-line, entity-by-entity, field-by-field work of actually getting your data from GP into BC without breaking payroll runs, vendor payments, or the chart of accounts your CFO has relied on for fifteen years.

This post is written for the people doing that work — IT managers, functional consultants, and project leads who need granular answers, not high-level reassurance. We cover the five data entities responsible for 80% of migration failures, a structured comparison of migration tooling options, a 20-question pre-migration audit checklist, and a 90-day post-go-live stabilization framework built around Microsoft Power Platform.

The Five Data Entities That Break GP-to-BC Migrations

Every GP-to-BC engagement we have worked on at CRMONCE has surfaced the same pattern: the majority of critical defects trace back to five entity categories. Identifying and resolving these before data migration begins is the single highest-leverage activity you can perform.

1. Chart of Accounts Structure

GP uses a segmented account framework. Business Central uses a flat, dimension-driven structure. This is not a minor field-mapping exercise — it is an architectural transformation. GP's account segments (for example, Department-Account-Location: 100-1200-03) must be decomposed into a BC main account plus financial dimensions.

The mapping table below reflects the most common conversion pattern:

GP Segment Structure        BC Equivalent
--------------------------------------------
Main Account (1200)      → G/L Account No. (1200)
Department (100)         → Dimension Value: DEPT = "100"
Location (03)            → Dimension Value: LOCATION = "03"
Cost Center (optional)   → Dimension Value: COSTCENTER

Key risk: GP accounts with more than three active segments frequently require custom dimension sets in BC. Validate your segment count and cardinality during discovery. Any account with more than 5,000 unique combinations should trigger a redesign conversation before migration begins.

2. Multi-Currency Setups

GP stores realized and unrealized exchange gains and losses in dedicated GL accounts per currency. BC handles this through the Currency Gains/Losses accounts defined in the General Ledger Setup page. If you migrate historical transactions without reconciling these accounts, your trial balance will be out of balance from day one.

GP Field                          BC Field
--------------------------------------------
Currency ID                    → Currency Code
Exchange Table ID              → Currency Exchange Rate (date-driven)
Realized Gain Account          → Realized Gains Acc. (GL Setup)
Realized Loss Account          → Realized Losses Acc. (GL Setup)
Unrealized Gain Account        → Unrealized Gains Acc. (GL Setup)
Unrealized Loss Account        → Unrealized Losses Acc. (GL Setup)

Actionable step: Run GP's Multicurrency Revaluation report as of your migration cutoff date and reconcile every open foreign-currency transaction before attempting data extraction.

3. Fixed Assets

GP Fixed Assets stores book value, depreciation method, and asset life at the asset-book level, supporting multiple depreciation books (Tax, GAAP, Internal) per asset. BC supports this through FA Depreciation Books, but the field alignment is non-trivial.

GP FA Field                       BC FA Field
--------------------------------------------
Asset ID                       → FA No.
Asset Class                    → FA Class Code
Acquisition Cost               → Acquisition Cost (FA Ledger Entry)
Book Value (per Book)          → Book Value (per Depreciation Book)
Depreciation Method            → Depreciation Method
Useful Life (Years)            → No. of Depreciation Years
Placed-in-Service Date         → Depreciation Starting Date
Salvage Value                  → Salvage Value

Key risk: GP allows mid-year depreciation method changes with retroactive recalculation. BC does not. Any asset with a method change in the current fiscal year must be manually adjusted post-migration.

4. Historical AP and AR Transactions

The open-versus-closed transaction debate is one of the most consequential scoping decisions in any GP migration. Migrating only open transactions is faster but leaves your team unable to answer vendor payment history questions for 12 to 24 months. Migrating full history increases timeline and cost significantly.

For open transactions, the mapping is relatively clean:

GP AP Field                       BC Vendor Ledger Entry Field
--------------------------------------------
Vendor ID                      → Vendor No.
Document Type (Invoice/Credit) → Document Type
Document Number                → Document No.
Document Date                  → Document Date
Due Date                       → Due Date
Original Amount                → Original Amount
Remaining Amount               → Remaining Amount
Currency ID                    → Currency Code

For historical closed transactions, you must decide whether to post them as summarized journal entries (fast, loses granularity) or as matched invoice-payment pairs (slow, preserves audit trail). Our recommendation: migrate open transactions as live ledger entries and summarize closed history as a single opening balance journal per vendor/customer per fiscal year.

5. Custom Modifier Forms

GP Modifier and Dexterity customizations are the silent killers of migration timelines. Every custom field added to a GP window that feeds a back-end table needs to be evaluated: does Business Central have a native equivalent, can it be handled by a custom extension, or does the business process itself need to change?

Build a custom field inventory using this framework before migration begins:

Build vs. Buy: Migration Tooling Decision Framework

Three tooling approaches dominate GP-to-BC migration projects. Each carries a different cost profile, implementation timeline, and risk of data fidelity issues.

SmartConnect (Now Part of Celigo)

SmartConnect remains one of the most widely deployed integration and migration tools in the GP ecosystem. It supports GP as a source and BC as a target, with pre-built maps for common entities. Cost: Licensing typically ranges from $15,000 to $40,000 depending on connector volume. Timeline advantage: Pre-built maps reduce mapping configuration time by 40 to 60 percent for standard entities. Data fidelity risk: Medium — complex custom fields and multi-book fixed assets require custom map development that can erode the timeline advantage.

Microsoft BACPAC Export Method

For organizations with strong SQL and Azure Data Factory skills, Microsoft's own tooling — exporting GP's SQL database as a BACPAC file and transforming data through Azure Data Factory pipelines into BC's API — offers maximum control. Cost: Infrastructure costs only (Azure consumption), but internal development time is substantial. Timeline: Longest of the three options for initial setup; fastest for repeat migrations if you standardize your pipeline. Data fidelity risk: Lowest, because you control every transformation step and can validate against GP SQL directly.

Jet Reports Migration Utilities

Jet Reports (now part of insightsoftware) offers migration-adjacent utilities primarily focused on financial data extraction and reconciliation reporting during migration. It is strongest as a validation and reporting layer rather than a primary migration engine. Use it alongside SmartConnect or BACPAC pipelines to confirm that migrated trial balances, open aging reports, and fixed asset schedules reconcile correctly before go-live sign-off.

The IT Manager's Pre-Migration Audit: 20 Questions to Answer Before Signing a Statement of Work

Do not sign a migration Statement of Work until you have answered every question on this list. Each unanswered item is a potential change order.

Post-Migration Stabilization: The 90-Day Hypercare Plan

Go-live is not the finish line. The 90-day hypercare window is where migrations succeed or quietly fail. Here is how to structure it.

Days 1–30: Triage and Reconciliation

Assign a dedicated hypercare team with at least one functional consultant who knows both GP and BC. Daily stand-ups are non-negotiable. Priority reconciliations in this window: open AP aging versus GP cutoff report, open AR aging, bank reconciliation, and the first payroll run (if applicable). Every discrepancy must be logged, root-caused, and resolved before month-end close.

Days 31–60: Process Stabilization and Automation Rebuild

GP users commonly rely on macros and Modifier automations that no longer exist in BC. This is the window to rebuild critical workflow automations using Power Automate. Priority flows to rebuild include:

Days 61–90: Reporting Gap Closure in Power BI

GP's Management Reporter and SSRS reports do not migrate to BC. Every report your finance team relied on must be rebuilt. Use the Business Central connector in Power BI Desktop to connect directly to BC's OData feeds. Priority reports to rebuild in this window:

For organizations that had heavy Management Reporter usage, consider deploying the Business Central Finance Report Pack available on AppSource as a starting point to reduce rebuild time by 30 to 40 percent.

Final Thoughts: Precision Is the Differentiator

The difference between a GP-to-BC migration that closes on time and on budget and one that drags into its second year is almost never about the technology. It is about the level of rigor applied before the first data extract runs. Organizations that invest in detailed data mapping, honest pre-migration audits, and structured post-go-live hypercare consistently outperform those that rely on high-level roadmaps and vendor optimism.

At CRMONCE, our Dynamics 365 Business Central migration practice is built on exactly this kind of practitioner-grade detail work. If your organization is planning a GP migration and you want a partner who will work through the mapping tables with you — not just hand you a slide deck — we are ready to start that conversation.

Schedule a free GP migration assessment with the CRMONCE team today.