The Definitive Guide to Migrating to Dynamics 365 Business Central

Microsoft Dynamics 365 Business Central is the cloud successor to Dynamics NAV (Navision), released in 2018 and aimed at small and mid-sized organisations ¹. It sits below Dynamics 365 Finance & Operations on price and complexity, and above QuickBooks and Xero on functional depth, with deep ties to Microsoft 365, Power BI, Power Automate and Azure Active Directory.

The typical Business Central customer is a 10 to 300-user mid-market business — manufacturers, distributors, professional services, non-profits — that has outgrown an entry-level accounting package or is exiting an aging legacy ERP. Per-user pricing runs $80/user/month for Essentials and $110/user/month for Premium, with implementation budgets that typically land $30,000 to $100,000+ depending on complexity. Per the Microsoft administrative tooling, a tenant is provisioned with 80 GB of database storage plus a per-user allowance ⁴.

The shapes of migration that actually land on Business Central fall into four patterns. First, Dynamics GP exits, driven by Microsoft's announced end of new GP subscription sales on April 1, 2026 and end of support in 2029-2031. Second, NAV-to-BC moves, where on-premises Navision customers shift to the cloud version using Microsoft's purpose-built cloud migration tool ⁶.

Third, QuickBooks and Xero graduations, where a growing business hits the ceiling on inventory, multi-entity or manufacturing features. Fourth, NetSuite consolidations, often M&A-driven, where the parent standardises on Microsoft's stack for the Outlook, Teams and Power BI integration. Each shape has a different difficulty profile: a GP migration ships with Microsoft's own Data Migration Extension that pulls master data plus open transactions, while a QuickBooks move is essentially a re-implementation that uses Business Central's own Data Migration Wizard.

What makes migrating *to* Business Central easier than the category average is the Configuration Package mechanism built into RapidStart Services — an Excel-based ingestion path that handles master data, opening balances and journal entries with row-level validation before anything posts. The Outlook add-in, Teams card and Power BI embed work out of the box, so the post-migration adoption curve is shorter than for any ERP that needs a separate productivity layer wired in.

What makes it harder than the average is the posting groups architecture — every customer, vendor and inventory item must be assigned posting groups that drive the GL accounts hit on every transaction, and a missing or mis-mapped posting group blocks the entire posting process ⁹. The fiscal period and cutover model also bites: Business Central uses a date-based posting framework where unrolled prior periods can be re-posted into, useful for adjustments but unforgiving without deliberate period-close discipline during migration.

Workflows, custom reports, AL extensions and Power Automate flows do not import from the source ERP — they are rebuilt from documentation or re-developed in Visual Studio Code with the AL Language extension ¹⁰. Teams that scope for that work up front finish on time; teams that assume a push-button cloud migration finish late.

Microsoft markets a push-button migration tool, but moving from GP to Business Central is a full ERP re-implementation — not an upgrade.

Business Central organises data as tables surfaced through cards in the UI. Master data lives on its own tables — Customer, Vendor, Item, G/L Account — and transactional data flows through journals and documents that post into the General Ledger and subledger entry tables (Customer Ledger Entry, Vendor Ledger Entry, Item Ledger Entry).

Before mapping any source field, you need to know which destination table the row belongs on, its No. (number) format, and which posting groups drive its GL behaviour. The table below summarises the objects you will touch in any Business Central migration.

Business Central has no universal external-ID field. The canonical primary key is the No. on each card (Customer No., Vendor No., Item No., G/L Account No.), and the canonical match key on import is that same No. Configuration Packages match by primary key — re-running with the same No. updates the existing record rather than creating a duplicate. If source identifiers are non-numeric, remap to Business Central's No. Series and store the original in a *Legacy No.* field.

Custom-field options are constrained compared with a generic SaaS platform. Out of the box you can add up to 32 custom fields per card via the EOS Custom Defined Fields AppSource app with no developer involvement ¹³. For deeper extension you write AL extensions in Visual Studio Code that add fields directly to the underlying table — there is no on-platform field-builder UI for native development ¹⁰.

Relationships are modelled as TableRelation properties on each field — a Customer No. on a Sales Header points at the Customer table. There is no general-purpose junction object; many-to-many is modelled via explicit junction tables (Item Vendor, Default Dimension, Item Category) with composite primary keys.

Posting groups are the most consequential concept to internalise before mapping. Customer Posting Group points at the AR control account, Vendor Posting Group at the AP control account, Inventory Posting Group at the inventory and COGS accounts, and General Business + General Product Posting Groups jointly drive sales and purchase line GL via the General Posting Setup matrix ⁹. Get the posting groups wrong on master data and every document the customer touches posts to the wrong account.

The single best predictor of a clean Business Central migration is how much work you do on the chart of accounts and master data *before* any package is uploaded. Practitioners consistently report that the most expensive mistakes are caught the day they try to post the first transaction and discover a missing posting group or an unmapped GL.

Validate as you go. Don't wait until launch week to discover that inventory fields never made it across — that's how launch week becomes panic week.

Treat the source export as raw material that needs to be reshaped to Business Central's expected formats — GL account numbers conformed to a fresh chart, dates in a consistent format, currency codes in ISO-4217, customer and vendor records with payment terms and posting groups assigned before they ever cross the wire.

Source-side prep

• Audit the chart of accounts in the source ERP and decide whether to lift-and-shift the numbering or restructure. A GP-to-BC move almost always requires restructure — the GP chart was likely built before dimensions existed and uses sub-accounts that should collapse into Business Central dimensions instead.
• Dedup customers, vendors and items in the source before export. A customer that appears twice in QuickBooks under slightly different names will land as two Customer No. records in Business Central with split ledger histories.
• Normalise units of measure — every Item must have a Base Unit of Measure, and alternate UoMs must declare a numeric conversion factor (e.g., Box of 12 = 12 × Each). Missing or zero conversion factors block the Item import ¹¹.
• Resolve currency exchange rates — pull the full historical rate table from the source for every currency you transacted in, with the *Starting Date* on which each rate applied. Business Central uses the exchange rate effective on the document's Posting Date, not a single corporate rate ¹².
• Decide on AP/AR open-invoice strategy — load as journal entries against control accounts (simpler, no document detail) or as posted documents (preserves invoice number and aging detail). The right call depends on how often Finance needs to look back at the source document, not on technical ease.

Destination-side prep

• Create a sandbox environment from the Business Central administration center — sandboxes are full copies of production and can be created in unlimited number for trial runs ¹⁹. Use the sandbox to dry-run every Configuration Package before touching production.
• Build the chart of accounts in production with Account Type, Income/Balance, Direct Posting flag and Totaling ranges set. Header and Total accounts must be structured before any G/L Account can post.
• Configure posting groups upfront — Customer Posting Groups, Vendor Posting Groups, Inventory Posting Groups, General Business and General Product Posting Groups — with the matrix in General Posting Setup filled in before any sales or purchase document import runs ⁹.
• Set up fiscal year and accounting periods under Setup → Accounting Periods. Lock prior periods you do not intend to allow postings into during cutover.
• Provision users via Microsoft Entra ID (formerly Azure AD), assign Permission Sets and User Groups, and configure SSO before go-live. Permission Sets control table-level access; missing permissions during user testing surface as cryptic 'You do not have permission' errors at posting time.
• Create dimensions and default dimensions for every Customer, Vendor and G/L Account that needs analytics. Default Dimensions auto-populate journals and documents; without them, every line needs manual dimension entry.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — typically a full weekend, longer for multi-entity — and communicate it to AP, AR, Sales and Finance. Train department leads on Role Centers, document approvals and posting flows in the sandbox before go-live. A typical Business Central implementation runs three to six months end-to-end; the data move is two to six weeks of that, the rest is process redesign and user readiness.

Business Central exposes several load paths and the right one depends on dataset size, table mix, and whether you need to re-run idempotently. Configuration Packages (part of RapidStart Services) cover most master-data and opening-balance migrations. The Data Migration Wizard handles guided one-shot loads from QuickBooks, GP and Excel. Programmatic loads handle large, repeatable transactional volumes.

Configuration Packages (RapidStart Services)

The canonical path for any Business Central migration is Configuration Packages, accessed via Setup & Extensions → RapidStart Services → Configuration Packages. A package is a metadata bundle declaring which tables to load, which fields are in scope, validation rules, and processing order.

The workflow: define the package on the destination, export an empty Excel template seeded with the chosen columns, populate from source data, import back, run Apply Package to write into live tables. Apply runs field-level validation against TableRelation, Option enums and mandatory-field rules before any row commits — errors surface as rows with status Invalid that you fix and re-apply without re-loading clean rows. Configuration Packages handle master data, historical exchange rates, opening journal entries and document templates.

Data Migration Wizard (Assisted Setup)

The Data Migration Wizard sits under Assisted Setup and offers guided ingestion from Dynamics GP, QuickBooks Desktop and Online, and plain Excel via Data Templates. For Dynamics GP, a dedicated Data Migration Extension connects to the on-prem GP database, pulls master data plus open transactions, and applies them via the same Configuration Package engine ²¹. The Wizard is the right call for a small business with a supported source and little transformation; the wrong call for custom legacy systems.

Programmatic loads

Business Central exposes programmatic surfaces for the standard entities Customer, Vendor, Item, JournalLine, SalesInvoice and so on ²². Tenant authentication runs through Microsoft Entra ID. Custom Business Central extensions can expose additional entities for anything not in the standard set.

The platform-wide ceiling is roughly 5 concurrent operations and 95 queued per tenant, with too-many-requests responses returned when either is exceeded ¹⁶. Choose the programmatic path when the load is over 100,000 records, when you need to push transactional documents (Sales Invoices, Purchase Invoices) at scale, or when the migration needs to be re-runnable and audit-logged from your side.

Third-party staging tools

Fivetran, Workato, Tipalti and SmartConnect (eOne) all have certified Business Central connectors. The pattern is reverse-ETL: source lands in a warehouse, transforms in SQL or a low-code mapper, then flows in programmatically or via Configuration Packages. Insight Works's Import Export PowerTool is a Business Central-native app that runs imports up to 30 times faster than standard RapidStart. For one-time migrations the value is repeatability under failure; for ongoing syncs, they become the integration system of record.

Mapping is where every ERP migration earns its scars. The schema decisions you make in your mapping spreadsheet determine whether the trial balance ties on day two, whether inventory valuation reconciles on day five, and whether the AP team trusts vendor balances on day thirty.

Work table by table, top to bottom of the import order: G/L Account first (so every other table has somewhere to post), then Posting Groups and Dimensions, then Customer and Vendor, then Item, then Currency and Exchange Rate, then opening journal entries, then AP/AR open items, then historical transactions if in scope.

Chart of accounts and posting groups

The Chart of Accounts is the foundation. Every G/L Account row needs No., Name, Account Type (Posting, Heading, Total, Begin-Total, End-Total), Income/Balance flag, and a Direct Posting yes/no that controls whether the account can be posted to from journals directly versus only via subledger postings.

GL opening balances

Opening balances enter Business Central through a General Journal with Posting Date set to the last day of the closing prior period and Document No. set to a consistent code (e.g., OPENING-2026). Every Debit line needs a balancing Credit line, posted against the Opening Balance Equity holding account (typically account 3990 or similar) so the journal balances ²⁵.

Once you confirm the trial balance ties to the source, reclassify Opening Balance Equity into Retained Earnings via a separate journal. AP and AR control accounts are loaded zero in the opening journal — their balances arrive via the AP/AR open-invoice load, which posts directly to the control accounts through the subledger.

Inventory items, BOM and units of measure

Item master data is the most field-rich table in Business Central. Required at minimum: No., Description, Base Unit of Measure, Inventory Posting Group, General Product Posting Group, Costing Method (FIFO, LIFO, Average, Specific, Standard), and optionally Item Category Code and Item Tracking Code for lot/serial numbers.

Opening inventory quantities are loaded via the Item Journal with Entry Type *Positive Adjmt.*, which creates Item Ledger Entries and posts inventory value to GL via the Inventory Posting Setup. Lot or serial-tracked items must include tracking lines in the journal or Business Central rejects the row at posting.

Multi-currency and historical exchange rates

Every additional currency must be defined on the Currency card with code, description, the rounding precisions for amounts and unit amounts, and the GL accounts used for posting realised/unrealised gains and losses ¹². The Currency Exchange Rates table stores the rate history — every row carries Starting Date, Exchange Rate Amount and Relational Exchange Rate Amount, and Business Central uses the rate effective on the document's Posting Date.

For migrations, load the full historical exchange-rate table from the source covering every currency-date combination touched by any open document. If you only load today's rates and then post historical AP/AR with prior posting dates, Business Central converts at today's rate and your statutory reporting breaks immediately.

Fiscal periods and AP/AR open invoices

Set up the fiscal year and Accounting Periods before importing transactional data. Allow Posting From / Allow Posting To dates on User Setup and General Ledger Setup gate the active window. Recommended pattern: leave the prior year open during the parallel-run window, post late adjustments via General Journal, reconcile, then close the prior year and lock posting forward.

Open invoices migrate two ways. The journal-entry approach posts each as a General Journal line with Account Type *Customer*/*Vendor*, original Document No., Posting Date, Due Date and Amount — fast, ages correctly, applies cleanly against cash receipts. The document approach creates full Posted Sales/Purchase Invoices with header and line detail — more work, but preserves the invoice document for audit and reprinting.

Customer, Vendor, payment terms and Dimensions

Customer and Vendor cards are required-field heavy. Beyond Name and Address, the load must include Customer/Vendor Posting Group, Gen. Bus. Posting Group, VAT Bus. Posting Group, Payment Terms Code (e.g., 30D, NET60), and Currency Code if non-local. Pre-create every payment term referenced in the source before importing master data, or rows with unknown Payment Terms Code values are rejected.

Dimensions replace the legacy GL sub-account model — typical dimensions are *Department*, *Project*, *Customer Group*, *Salesperson*, *Location*. Define each under Setup → Dimensions, then assign Default Dimensions at Customer, Vendor, Item or G/L Account level. The *Value Posting* rule (No Code / Same Code / Code Mandatory) enforces dimension capture at posting; use Code Mandatory on revenue-tracking dimensions to prevent unanalysed transactions.

Historical transactions, files and audit trail

Business Central does not have a generic 'import historical transaction' path that preserves Entry No. integers — Entry No. on every ledger entry is system-assigned at posting. The two patterns are: (1) load each historical document as a posted invoice via the document approach, which gets a new Entry No. but preserves Document No., Posting Date and amounts; or (2) keep the source ERP read-only as an archive for pre-cutover lookups.

Document attachments (PDFs, scanned invoices, contracts) attach to records via the Document Attachments FactBox. As of the 2026 wave 1 release, Business Central supports external file storage for attachments via SharePoint, Azure Blob Storage and other providers, which keeps the database under capacity caps and lets you move large attachment estates without bloating the tenant ²⁶. Configure External Storage Setup before bulk-loading attachments.

System fields — SystemCreatedAt, SystemCreatedBy, SystemModifiedAt, SystemModifiedBy — are Microsoft-managed and stamped on every write. They cannot be overridden during a Configuration Package apply ²⁷. If audit trail matters, add Legacy Created Date and Legacy Created By as extension fields and populate from the source export. The on-platform Change Log captures field-level changes from when it is enabled — turn it on *after* the migration so cutover writes do not flood the log ²⁸.

Validation is the bridge between the import jobs completing and Finance being allowed to close month-one. The most reliable signal is having department leads — AP, AR, Inventory, GL — run their week-one work in the sandbox and sign off that the numbers tie. Build a reconciliation spreadsheet comparing source and destination on each of these counts; anything outside a $0.01 GL variance or a 0% record-count variance gets investigated before users get login access.

• Trial balance per account — run G/L Account Balances report in Business Central as of the opening-balance date and tie line-by-line to the source ERP trial balance. Any variance traces to either a missing journal line or a GL account that landed with the wrong sign.
• AR aging by customer and aging bucket — run Customer - Top List and Aged Accounts Receivable reports and compare to source aging. Variances usually trace to missing or mis-dated open invoices.
• AP aging by vendor and aging bucket — run Aged Accounts Payable report and reconcile to source. Apply the same logic as AR.
• Inventory valuation per item and per location — run Inventory Valuation report and tie to source inventory subledger. Variance per item points at a missing Item Journal positive adjustment or a wrong Costing Method.
• Customer and Vendor counts vs source — count distinct No. on each table; any duplicates indicate the dedup transform missed cases.
• Item count plus BOM coverage — count distinct Item No. plus count Production BOM Header rows; gaps in BOMs mean assembly orders will fail at release.
• Currency exchange-rate row count per currency — every starting-date row from the source should be present on Currency Exchange Rates; missing rows mean historical revaluation breaks.
• Posting Group coverage matrix — confirm General Posting Setup has a row for every Gen. Bus. × Gen. Prod. combination actually used on imported documents.

On top of reconciliation, run a manual spot-check: pick 20 customers, 20 vendors and 20 items and verify each card against the source UI. Pick the five largest open invoices on each side (AR and AP) and trace the full document — header, lines, dimensions, posting groups. If discrepancies show in three or more of 20, halt cutover, fix root cause, re-apply affected Configuration Package rows.

Change Log must be enabled from cutover day forward — Setup → Change Log Setup, enable per table for every table you want field-level history on. It captures user, timestamp, table, field, old value and new value and is the canonical audit source going forward ²⁸. India-localised tenants must enable the equivalent Audit Trail functionality for statutory compliance ³².

There is no native bulk-undo for posted transactions — posting is one-directional, and reversal is via posting an opposite entry, not by deleting the original. For Configuration Package applies that have not yet hit transactional tables, the package can be re-applied with corrected data because primary-key match updates the existing record. For everything posted, stamp every imported row with a deliberate Document No. prefix (e.g., MIG-) and post offsetting reversal journals filtered on that prefix if catastrophe strikes.

Cutover sequencing: (1) source ERP goes read-only Friday evening; (2) final delta export captures everything changed during the test-import window; (3) delta applied via Configuration Package on Saturday; (4) reconciliation runs Sunday; (5) Monday users get access with the migration lead on call for two weeks of hyper-care; (6) source decommission scheduled 90 to 180 days out, never the same month.

The Microsoft Solution Partner program designates partners by specialisation (Business Applications) and competency level (Solutions Partner, plus the legacy Gold/Silver designations). For Business Central migrations specifically, partners with a stated Dynamics GP-to-BC or NAV-to-BC practice tend to ship cleaner than generalist Microsoft partners.

RSM, Armanino, Western Computer, Synoptek, Itransition, Liberty Grove, Sabre Limited and Enavate are commonly named in the Business Central migration corner of the market, each offering fixed-scope packages and Microsoft-aligned methodologies. eOne Solutions ships SmartConnect and Popdock as BC-native migration tooling, strong on NAV-to-BC and GP-to-BC data movement. Insight Works's Import Export PowerTool is a free app that runs imports up to 30x faster than RapidStart for large master-data loads.

On the ETL and iPaaS side, Fivetran, Workato, Hopp Tech, Tipalti and Apideck all have Business Central connectors. Their role in a migration is rarely the migration itself — it is the staging layer that lands source data into a warehouse, the transformation layer that conforms posting groups and dimensions, and the ongoing-sync layer that takes over once the one-time migration is complete. Hopp Dynamics specifically targets Dynamics 365 data migrations with a tracking portal and pre-built business-object templates.

Managed-migration cost ranges vary widely. Per market-published guidance, a clean QuickBooks-to-BC move with under 1,000 customers and no manufacturing typically lands $35,000 to $60,000 inclusive of license setup and basic training. A Dynamics GP-to-BC project with multi-entity, manufacturing BOMs, three years of historical AR/AP and Power BI rebuild typically runs $60,000 to $150,000+, with the upper end driven by entity count, custom AL extension scope, manufacturing depth, and the number of integrations that need rebuilding rather than re-pointed.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Business Central migrations and handles the chart-of-accounts mapping, posting-group setup, Configuration Package authoring, opening-balance journal design, historical-exchange-rate loading and reconciliation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on record count, entity count and source platform, with separate line items for manufacturing BOMs, multi-currency depth and AL extension scope so the scope is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want a Microsoft Solution Partner with full implementation scope, an iPaaS-first approach for ongoing-sync needs, a Business Central ISV like eOne for migration-specific tooling, or a specialist migration vendor. Explore FlitStack →