Business Central data migration that reconciles to the cent

What a Business Central data migration includes

Three kinds of data move. First comes master data: customers, vendors, items, the chart of accounts, fixed assets and bills of materials. Next come open transactions: unpaid invoices, open orders, inventory on hand and bank balances. Last is history, which is a decision, not a default. We agree on each group in writing first.

Setup data sits alongside: payment terms, posting groups, units of measure and dimension values. These must exist before the master data that refers to them. So the order of loading matters as much as the content. We prepare a load sequence at the start and follow it every time.

Cleaning source data for a Business Central data migration

Old systems collect duplicates, inactive records and fields used for something other than their label. Before we map anything, we give you extracts to go through. Which customers are still active? Which items are obsolete? Do any vendors appear twice under different spellings? Your answers decide what we load and what stays behind.

Mapping then turns each source column into a Business Central field. We split account strings into a natural account and dimensions. Free-text payment terms become coded ones. The map is a spreadsheet that you approve, and it records every decision. We keep it up to date through every trial.

Loading data in a Business Central data migration

Configuration packages are the standard loading tool. A package lists tables and fields and exports an Excel template. It then imports the filled file and checks each row against table rules before applying it. Errors show per record, so a bad postal code does not stop the rest.

We load open balances through journals, not straight into ledgers. So every opening entry posts through the normal routine and leaves a proper audit trail. For very large volumes or repeated loads, we use APIs or a small AL import routine. We choose the method per table, based on volume.

Trial loads that prove a Business Central data migration

Nothing loads just once. We run trial loads into a sandbox and fix what fails. Then we repeat until a full load completes without manual patching. Each trial gives your team a realistic system to test with. That finds mapping errors that a spreadsheet check would miss.

After every load, we reconcile. We compare the trial balance with the old system, aged receivables and payables by customer and vendor, and inventory quantity and value by location. Your finance lead signs off on the figures before we schedule the production load. We explain any difference line by line before we move on.

How much history a Business Central data migration brings

Bringing every old transaction across is rarely worth it. Detailed history carries old account structures and old mistakes. It also makes every trial load longer. Most companies bring open items plus summarized ledger balances by period. That is enough for comparative financial reports. We also ask auditors and tax advisers where they have a view.

The old system can stay available read-only for lookups. Or you can export its history to a reporting database that Power BI can query. We help you decide by asking who looks at old data, how often and why. The answer is often simpler than people fear at the start.

Business Central data migration questions

Which systems can you migrate data from?

Any system that can export its data. We have mappings for the common accounting and ERP products. For the rest, we work from exports to Excel, CSV or a database copy. Dynamics GP and NAV also have Microsoft's own migration tooling. So your Business Central data migration does not depend on one source system or one file format.

Who is responsible for cleaning the data?

Your team decides what is correct, because only you know which customers are real and which item numbers are dead. We prepare the extracts and highlight likely duplicates and errors. Then we apply your decisions in bulk and keep a record of each rule. That way, nobody has to repeat the same cleanup for the next trial load.

Can open sales and purchase orders be migrated?

Yes. We can load open orders as documents with their remaining quantities. Many companies choose to complete as many orders as possible in the old system before cutover. They then enter the few that remain. That is often simpler and safer, because the new system starts with fewer open items to check.

What is the difference between data migration and cloud migration?

Data migration moves records from any system into Business Central, usually through packages and journals. Cloud migration uses Microsoft's tool to copy a whole on-premises Business Central or Dynamics GP database into an online tenant. The second route suits companies that stay within Microsoft products. We help you pick the one that fits.

How do we know nothing was lost?

We reconcile totals and counts after every load: the number of records per table, balances per account, and quantities per item and location. Any difference leads back to a single row. The sign-off sheet from your finance lead is part of the go-live checklist. So you can show, with evidence, that nothing was lost.

Related migration pages

Data migration is one part of a larger move. The pages below cover the project around it and the specific routes from the systems that companies leave most often. Read the one that matches your source system. Then we can plan your Business Central data migration step by step, from extract to final reconciliation. For the product detail, see Migrating customer data with configuration packages.