Migration Checklist: Moving to Dynamics 365 Business Central

Phase 0

Decide & Plan

Resolve the questions that determine whether the migration is even the right move.

• Document the in-scope objects: Chart of Accounts, Customers, Vendors, Items, Bank Accounts, Fixed Assets, open AR, open AP, open Sales Orders, open Purchase Orders, and any modules in use (Manufacturing, Jobs, Service). Decide which Business Central tables receive data and which legacy modules will not be carried over. Write this list down before any other work.

  Risk if skipped: Scope creep mid-project forces re-do of the configuration package mapping after sandbox tests have already started.

• Decide the historical-data cutoff: how many closed fiscal years of GL detail and how many years of posted documents to bring across. Most teams load only opening balances and the current open year of detail. Anything older stays in the source as a read-only archive.

  Risk if skipped: Loading several years of historical entries multiplies storage cost against the 80 GB plus per-user database allowance and slows every report.

• Choose the Business Central license tier (Essentials vs. Premium) based on modules in scope. Premium is required if Manufacturing or Service Management is in scope. The decision affects user-license cost from day one.

  Risk if skipped: Re-tiering after go-live forces a re-quote and may block users from modules they were trained on.

• Decide the multi-company structure: one tenant per legal entity vs. multiple Companies inside a single tenant. Business Central uses a Tenant → Environment → Company hierarchy. Inter-company posting is configurable but only inside a tenant.

  Risk if skipped: Picking the wrong topology forces a re-implementation when consolidation reporting fails to roll up across entities.

• Confirm Azure geography for the production environment to satisfy data-residency rules. Environment localization at creation time pins the database to a specific Azure geo and cannot be changed later without re-provisioning.

  Risk if skipped: GDPR or sector data-residency findings post-go-live force a re-migration into a new environment in the correct geo.

• Identify SOC 2, HIPAA, India audit-trail, or industry retention requirements that affect logging, Change Log, and retention policies. Business Central supports retention policies that auto-purge tracked log tables; the rules must be set before users start posting.

  Risk if skipped: Retention defaults silently delete log data that a later audit needs.

• Set the target cutover window with a hard freeze date on the source ledger. Pick a date close to month-end and avoid year-end. The window must cover final reconciliation, cloud-migration replication, and validation.
• Name a single accountable owner (DRI) for the migration and identify the Finance, Operations, IT, and Microsoft Entra admin counterparts. Business Central depends on Entra ID for user identity. The Entra admin is needed before any user account can be created.
• Write the success criteria as falsifiable statements (e.g., trial balance matches the source to the cent, all open AR invoices reconcile by customer, item on-hand quantities match by location).

  Risk if skipped: Without explicit numeric exit criteria the project never formally closes and resources keep getting pulled back for rework.

• Document explicitly out-of-scope items: legacy custom reports, third-party add-on data, posted email attachments, deleted-record audit history. Tell users which decisions were made so expectations match what go-live delivers.

Phase 1

Pre-Migration Prep

Cleanse the source, stand up the destination, and prep the people — before exporting a single row.

Phase 2

Source Export

Extract every byte you will need, with timestamps captured so you know the delta at cutover.

• Export the full source Chart of Accounts including Account No., Name, Type, Income/Balance flag, parent account, and totaling string. Save as CSV with a UTF-8 BOM. Capture the export timestamp in the filename.
• Export the source GL trial balance as of the planned cutover date by Account and Dimension.

  Risk if skipped: Without a dimension-level trial balance you cannot rebuild the opening journal with the right analytical splits.

• Export the Customer master with all standard fields plus any custom attributes flagged in scope. Include Tax Registration No., Payment Terms, Currency Code, default Salesperson, default Dimensions.
• Export the Vendor master with all standard fields plus custom attributes in scope. Include Tax/VAT Registration No., Payment Terms, Payment Method, Currency Code, default Dimensions.
• Export the Item master with Description, Base Unit of Measure, Item Category, Inventory Posting Group, Gen. Prod. Posting Group, VAT Prod. Posting Group, Costing Method.

  Risk if skipped: Missing Costing Method on import forces a default that may not match the source valuation.

• Export Item Units of Measure and conversion factors against the base UoM for every item that uses alternate units. Box, case, pallet conversions must travel with the item or quantity math breaks on purchase and sales documents.
• Export Bills of Materials (BOM) and routing data if Manufacturing is in scope.
• Export open Sales Orders, open Purchase Orders, open Sales Invoices, open Purchase Invoices, and open Credit Memos as of the freeze date. Document the exact freeze timestamp in the filename of each export.

  Risk if skipped: Mixing a half-frozen source with a half-loaded destination creates phantom orders.

• Export open AR Customer Ledger Entries by document, including Document No., Document Date, Due Date, Original Amount, Remaining Amount, Currency.

  Risk if skipped: Open AR loaded as a single net balance per customer destroys aging and remittance allocation.

• Export open AP Vendor Ledger Entries by document with the same fields as AR open items.
• Export on-hand inventory by Item, Location, and Lot/Serial if applicable, with quantity and standard or actual cost.
• Export Fixed Assets with acquisition date, original cost, accumulated depreciation as of cutover, depreciation book, useful life, and remaining life.
• Export Bank Accounts with the last reconciled balance and the list of unreconciled transactions.

  Risk if skipped: Without the unreconciled list the first bank rec in Business Central reports a phantom variance.

• Export historical Currency Exchange Rates covering at least the open-document period. Daily rates if the source used them; otherwise the rate that was actually applied to each open foreign-currency document.
• Export the user list with roles and reporting structure for re-creation in Entra and Business Central Permission Sets.
• Export attachments and associated document metadata (which file belongs to which Document No., Customer, Vendor, or Item). Capture the binary files plus a manifest CSV that maps each filename to its parent record key.
• Screenshot or export configuration of source reports, dashboards, automations, and workflows. These do not migrate. They will be rebuilt in Business Central, Power BI, or Power Automate in Phase 7.

Phase 3

Transform & Map

Translate the source exports into Business Central–shaped Configuration Package files and RapidStart templates.

Phase 4

Sandbox Test Migration

Find every breakage in the sandbox before it costs you a real cutover window.

• Refresh the sandbox environment from a recent production backup so it matches the production setup tables. Use the Business Central administration center to copy the production environment into the sandbox slot.
• Load a 1–5% representative sample of each object via Configuration Package into the sandbox. Pick rows that include the trickiest data: long names, accented characters, multi-currency documents, lot-tracked items.
• Spot-check 10 random Customer, Vendor, and Item records field-by-field against the source.

  Risk if skipped: Field-level drift caught after full load forces a destructive re-import.

• Test that mandatory fields enforced by AL extensions (e.g., Customer Posting Group on Customer) reject blank rows. Configuration Package validation surfaces these as row-level errors with a specific field name.
• Test datetime handling: load a record with a timezone-sensitive datetime and verify the value displayed in Business Central matches the source.
• Test special-character handling on names, addresses, and item descriptions.
• Load the opening General Journal in sandbox and verify it posts with debits = credits and produces a trial balance that matches the frozen source TB.

  Risk if skipped: A sandbox trial balance that does not tie forces a transform fix before any production load.

• Load the Item Journal positive adjustments in sandbox and verify Item Ledger entries are created with correct cost and Location.
• Load open AR and open AP samples in sandbox and verify aging buckets match the source aging report.
• Run a full-volume timing test if sandbox capacity allows, to extrapolate cutover-window duration. Business Central throttles concurrent and queued operations at the tenant level; bulk loads must pace themselves below those ceilings.

  Risk if skipped: Hitting tenant throttling mid-cutover forces the load to back off and extends the window past business hours.

• Test attachment upload to the Document Attachments table for a sample of records.
• Have a Finance, Inventory, and AP user spot-check sandbox data using their normal day-to-day workflows.

  Risk if skipped: Issues that only surface in real workflows (statement runs, payment proposals, inventory picks) stay hidden until go-live.

• Capture sandbox load times and error counts in a written test report and have the migration sponsor sign off before Phase 5.

  Risk if skipped: Skipping written sign-off means later disputes about whether the sandbox passed at all.

Phase 5

Production Cutover

Tight, sequenced execution. Every step is logged and idempotent.

• Confirm the source freeze: verify no posting activity in the source for the last hour.
• Take the final delta export of source data covering everything that changed since the Phase 2 baseline.
• Verify production Allow Posting From / Allow Posting To windows are open for the opening-journal date. Check both General Ledger Setup and the User Setup for the migration user.
• Disable production job queues, AppSource integrations, and notification flows that might fire during the load.

  Risk if skipped: An active recurring job queue can post against partially loaded master data and create orphan ledger entries.

• Apply Configuration Packages in dependency order: setup tables (Posting Groups, Currencies, Exchange Rates, Locations, Dimensions, Payment Terms) first.
• Apply master-data Configuration Packages next: Chart of Accounts, Customers, Vendors, Items, Item Units of Measure, Bank Accounts, Fixed Assets.
• Post the GL opening-balance General Journal with Opening Balance Equity as the offset. Confirm the trial balance immediately after posting and match it to the frozen source TB before continuing.

  Risk if skipped: Continuing past an out-of-balance opening journal compounds the variance into every downstream report.

• Post the Item Journal positive adjustments to seed inventory on hand by Item and Location.
• Load open AR documents (or the open-AR journal) and verify customer balances roll up to the AR control account on the GL.
• Load open AP documents (or the open-AP journal) and verify vendor balances roll up to the AP control account on the GL.
• Load open Sales Orders and open Purchase Orders.
• Capture every Configuration Package status, row count, and error count from the Config. Package Card.

  Risk if skipped: Without recorded row counts you cannot prove reconciliation later.

• Re-tighten Allow Posting From / Allow Posting To windows to lock historical periods.
• Re-enable job queues, integrations, and notification flows.

Phase 6

Validate

Prove correctness against the frozen source numbers before any user is let in.

Phase 7

Post-Migration Cleanup

Decommission the source, rebuild what did not migrate, and close the project.

• Communicate go-live to all end users with login URL, MFA setup steps, and a single support channel.
• Run role-based training refreshers in the first week using the migrated production data as the example dataset.
• Set the source system to read-only and announce the read-only date. Read-only mode kills the temptation to dual-post.
• Rebuild source reports and dashboards in Business Central report layouts, Excel, or Power BI. Reports do not migrate. Recreate the top 10 most-used reports first; backlog the rest.
• Rebuild source workflows, approvals, and notifications using Business Central Approval Workflows and Power Automate.
• Re-establish integrations to Outlook, Teams, Power BI, bank feeds, EDI, payroll, and any other downstream systems.
• Connect AppSource extensions that were paused during cutover and verify each one runs against the new data.
• Monitor integration throughput against tenant-level throttling for the first two weeks and tune any integration that approaches the cap.

  Risk if skipped: An integration hitting the throttle in production silently fails to deliver bank feed, EDI, or webshop data.

• Schedule a 30-day post-migration retrospective with the migration team and key users.
• Decide and document the source-system decommission date. A common interval is 90 days after cutover, after the final retention window passes.
• Archive all source-system exports, frozen reference reports, Configuration Packages, and load logs to long-term storage.

  Risk if skipped: Throwing away the export files before audit closes their books on the migration year forces a forensic recovery later.

• Close the migration project formally with a final status report, lessons-learned doc, and project closure.