There are four ways to get data into Business Central and each is right for a different job. Configuration packages for master data and opening balances, APIs for anything repeatable or large, the cloud migration tool for NAV and on-premise databases, and the migration assistants for Xero, QuickBooks and Dynamics GP. Which to use when, how each actually behaves, and the traps in each.
The data migration post was about the plan: what to bring, cleaning it in the source, reconciling to the penny twice. This one is about the tools, because the choice of tool decides how repeatable the migration is, and repeatability is what makes the go-live weekend boring.
A configuration package is a defined set of tables and fields, exported to Excel, filled in, imported, validated and applied. It is built into every Business Central and it is the right tool for master data: customers, vendors, items, G/L accounts, dimensions and dimension values, posting groups, locations, bins, units of measure, and the setup tables themselves. It is also the right tool for opening balances when they are loaded as journal lines (General Journal, Item Journal, FA Journal lines as package tables, then posted).
How it behaves: import puts rows into a staging table per package table; Apply runs them through the real table's validation (Validate on each field in the order you specify, which matters: posting group before anything that depends on it) and reports errors per row. You fix in Excel and re-import. A package can be exported from a configured company and applied to a new one, which is how you clone setup across companies and how partners ship starter configurations.
Traps: validation order (set Processing Order and the field "Validate Field" flags deliberately); Excel mangling leading zeros, dates and long text; the package silently skipping fields you did not include; and package tables for transactional data (do not load ledger entries directly, ever; load journals and post). Keep the packages in the repository with the extension; they are part of the implementation.
For anything large, repeatable or coming from another system programmatically: the standard v2.0 APIs and custom API pages. A migration script (PowerShell, Python, a small .NET app) reads the source, maps the fields, and writes through the API in batches, with the external ID stored so it is idempotent and can be re-run. This is how you migrate 200,000 items or two years of open documents, and how you make the third migration rehearsal identical to the first. Microsoft's Business Central APIs are also what Power Automate and Dataverse dataflows use, if the business already has those skills. Journal lines can be created through the journals and journalLines APIs and posted with the post action, which is how opening balances are automated.
Traps: throttling (batch, back off); validation happening in a different order than the UI (test one record first); and the temptation to write to tables that should only be written by posting. The API will not let you insert a ledger entry, which is the point.
For a business on Dynamics NAV (2015 onwards) or Business Central on-premise, Microsoft's cloud migration tool replicates the on-premise SQL database to the online tenant: companies, all tables including ledger entries, with history. It runs through Azure Data Factory via the admin centre's Cloud Migration Management page, can be run repeatedly (delta replication) during the project, and is finished with a final replication at cut-over. For NAV it requires the on-premise database to be upgraded to a supported technical version first (the "technical upgrade" to a Business Central version that the tool supports), and any C/AL customisations have to have been rebuilt as extensions before the data arrives, because the online tenant will not have the old objects.
When to use it: when history matters enough to bring in full and the source is a supported NAV or on-premise version. When not to: when the on-premise database is a mess that the business would rather leave behind, in which case a fresh implementation with opening balances (tools 1 and 2) is cleaner and usually quicker. Traps: table extensions on-premise must match the online extension's fields exactly; the schema differences between versions; permissions and users not migrating (they are re-created online); and the replication of data that should have been archived.
Microsoft and partners ship assisted-setup migrations for QuickBooks Online and Desktop, Dynamics GP, and (via partner apps on AppSource) Xero and Sage. They connect to the source, pull customers, vendors, items, the chart of accounts and open balances or transactions, and create them in Business Central with a mapping step. They are good for a straightforward single company and they save days on the master data. They are not a substitute for redesigning the chart of accounts (they copy it), and they will bring across the duplicates and the dormant accounts if you let them. Use them for the pull, then clean in Business Central before anyone posts, or clean in the source first as the migration post argues.
| Data | Tool |
|---|---|
| Setup tables, posting groups, dimensions | Configuration package (or copy company for a template) |
| Master data, up to tens of thousands of rows, cleaned in Excel | Configuration package |
| Master data, large or from another system by script | API |
| Opening balances and open items | Journals: via configuration package or API, then post |
| Open sales and purchase orders | API (documents with lines), or package to journals for simple cases |
| Full history from NAV or on-prem BC | Cloud migration tool |
| Small business from Xero / QuickBooks / Sage / GP | Migration assistant for the pull, then clean |
Whatever the tool, the migration is scripted so it runs the same way every time, it is rehearsed twice, and five numbers are reconciled after each run. The tool is the easy part; the discipline is the migration.
