Data migration into Business Central for a retail go-live

Data migration · 8 min read

A retail go-live stands or falls on the data load, not the software install. The tills need items with correct prices and barcodes, the office needs opening balances that reconcile, and none of it can be patched quietly once the store is trading on the new system. This guide walks the documented Business Central route — configuration packages, also known as RapidStart — in the order the dependencies actually require, and ends with the validation checks that should pass before anyone declares go-live.

Data accuracy note: opening balances and inventory values feed financial reporting. Treat every total in this process as a number to reconcile against the legacy system, not a number to trust because the import reported success.

What actually moves

Microsoft's guidance is to capture master data about customers, items, vendors, and the general ledger. In practice, a retail migration scope normally contains active master data, current balances, and open transactions: customers, vendors, items, the chart of accounts, opening balances, outstanding receivables and payables, inventory, and open sales and purchase orders.

What does not need to move is the full history. Historical data can stay available through the legacy system, a reporting database, or another archive instead of being migrated. Decide that up front: every historical record added to the load is another record to map, test, and reconcile.

Configuration packages: how the documented tool works

Configuration packages are applied to an empty company in the customer's tenant to set up Business Central. Microsoft's own starting point is to set up a company in a sandbox first, so users can practise before Business Central is used in production — and so the load itself can be rehearsed.

Data comes in from Excel or from a .rapidstart file, from either the Configuration Worksheet page or the Configuration Package page. Two documented constraints shape the whole job:

• The Excel workbook must be exported from the Configuration Packages page. That export is what makes the workbook comply with the Business Central data structure. In the exported default package there is one worksheet per table, and the columns in those worksheets must not be moved, changed, or deleted — if they are, the worksheet cannot be imported back.
• The default package is finite. It consists of 27 tables, covering master data such as customers, vendors, items, and accounts, basic setup tables such as shipping methods, and transaction tables such as sales header and lines. Master data and some transactional data can be imported this way — not everything.

Where the source structure differs from Business Central, tables and fields are mapped on the Configuration Package page. Mapping follows table relations: a mapping defined directly for a field is used; otherwise Business Central searches for the mapping defined for the primary key field in the related table — and that related table must itself be part of the package. Fields of type Blob cannot be exported or imported using Excel at all, so anything stored that way needs a different route or stays behind.

One warning from Microsoft deserves bold type in every project plan: RapidStart configuration packages are for setting up a company for the first time only. They are not intended for companies already in production, and importing large amounts of data with them can impact performance and prevent all users from using Business Central during the process. For a company already in production, Microsoft strongly recommends an XMLport for import and export instead. Working with configuration packages is also classed as advanced functionality, with a recommendation to involve the reselling partner.

The load sequence

Order is not a preference; it is dictated by record dependencies. Customers must exist before customer transactions, vendors before payables or purchase documents, items before inventory or sales transactions, and accounts and dimensions before financial balances. For a retail go-live, that resolves into this sequence:

1. Setup and reference data first. The basic setup tables in the package (shipping methods are the documented example) and the chart of accounts go in before anything that references them.
2. Items, with units and prices attached. Items must exist before inventory quantities or sales transactions can reference them, so the item load — including the unit-of-measure and barcode data the POS will scan — precedes every stock figure.
3. Customers and vendors. Both must be in place before any open receivable, payable, or open order can point at them.
4. Open documents. Open sales and purchase orders load once the items and the customers or vendors they reference exist.
5. Opening balances last. Financial balances depend on the accounts being present, and the journal procedure below depends on master data already being in place.

Per table, the import itself is a two-stage process — import and validate first, then apply:

1. Open the Configuration Worksheet page or the Configuration Package page and import the master data.
2. Check the No. of Package Errors field. If errors are reported, drill down: the Config. Package Records page opens.
3. Choose the Show Error action to read the actual error for a record, and fix the underlying data — a typical message is that a value is not a valid option and lists the valid options.
4. Choose the Apply Data action to apply the mapping that has been set up. Only now does the data land in the destination tables.
5. On the Migration Overview page, review the No. of Migration Errors field. For a table with errors, choose the Errors action: each record with an error has the Invalid check box selected, Show Error shows the Error Text and the Field Caption, and the record itself is corrected via the Migration Record action.

What success looks like: every package table shows zero in No. of Package Errors, the Migration Overview shows zero migration errors, and record counts per table match the counts in the files that were loaded. An import that "completed" with errors still outstanding is not a completed import.

Opening balances without double-counting

Master data in place is only half the load. Opening balances are added afterwards by creating journal lines — Microsoft documents the G/L account procedure, and notes the same steps apply to creating journal lines for customers, vendors, and items:

1. Choose the Create G/L Acct. Journal Lines action and fill in the Options FastTab, setting filters as needed — for example, entering a name in the Journal Template field. The records are created in the journal with empty amounts.
2. Export the journal table to Excel and manually enter the posting and balancing account information from the legacy data.
3. Import and apply the table information into the new company. The journal lines are now ready for posting.
4. In the configuration worksheet, select the journal line table, choose the Database Data action, review the information, and choose Post.
5. Repeat for each other set of opening balances.

There is one documented exception to memorise: for opening balances for bank accounts, do not post directly to the G/L accounts associated with the bank accounts — bank accounts have their own setup route.

The posting order and method inside the journals matter as much as the load order, because subledger openings touch the general ledger whether intended or not:

• Inventory openings post GL entries automatically. Posting an item journal with item numbers and quantities creates corresponding general ledger entries. Those entries are reset with a general journal opening for inventory that mirrors the quantities and reverses the inventory postings in the GL — the item quantities stay in stock, the GL effect is cancelled.
• Subledger openings can be made GL-neutral. For customers, vendors, VAT, bank, and fixed assets, use the subledger account as one side of the posting and the same account as the balancing account. The two sides cancel, so the net effect on the general ledger is zero even though entries are created.
• The general ledger opening goes last. Post all the separate subledger and inventory openings first, neutralising their GL effect as they go, then post the final general ledger opening — that one is the actual opening balance for go-live.
• Open receivables and payables do not go straight into ledger entries. They cannot be imported directly into the Customer/Vendor Ledger Entries. Open receivables come in through the Sales or General Journal and open payables through the Purchase or General Journal, usually against a clearing G/L account, so Business Central creates the correct ledger entries and payments can be applied properly afterwards.

Validation before go-live

Validation is a documented phase of the migration in its own right, not a glance at the import log. The checks worth running, per data set:

The decision rule that ties this together: if a total does not reconcile, the go-live waits. A store can trade around a missing report; it cannot trade around opening inventory or receivables that are wrong, because every transaction after go-live builds on them.

The go-live cutover checklist

1. Full rehearsal load completed in the sandbox company, with the error-clearing steps above timed — the production load will take at least as long.
2. Final legacy extract taken after trading stops in the old system, so no transaction exists in neither system.
3. Load run in sequence: setup, items, customers and vendors, open documents, opening journals — GL opening posted last.
4. Error fields at zero on every table; counts and financial totals reconciled against the legacy close.
5. POS spot-checks passed: a sample of items scans at the correct price, and a test sale posts against an existing customer and item.
6. Legacy system kept available as the history archive — it is the fallback record, not a system to delete on go-live weekend.

What success looks like: day one trades on Business Central with stock, prices, open orders, and balances that all tie back to the legacy close — and the migration file set, mappings, and error log are kept, because the first month-end will ask questions only they can answer.

FAQ

Can configuration packages top up data after go-live? No — Microsoft documents them as a first-time setup tool only, warns that large imports can lock users out during the process, and recommends XMLports for companies already in production.

Why did records import but not appear? Import and apply are separate steps. Until Apply Data runs and the Migration Overview is clear of errors, records sit in the package rather than in the destination tables.

Does full history have to move? No. Master data, current balances, and open transactions are the operating scope; history can remain in the legacy system or an archive.