Business Central Data Migration: What Actually Happens When You Move From Your Old System

Most people think data migration means “export from the old system, import into the new one, done.” If you’ve been through an ERP migration before, you’re already laughing — or wincing.

Data migration is the part of a Business Central implementation where the ugly truth about your legacy data comes out. Duplicate vendors. Items with no cost. Customers last active in 2012. Chart of accounts entries that only Karen understood, and Karen left three years ago.

This guide covers exactly what happens during a Business Central data migration — what moves, what doesn’t, how long it really takes, why so many migrations fail, and what you need to do before the process starts. No sugarcoating. Just what we’ve learned across dozens of migrations from NAV, QuickBooks, SAP Business One, Excel, Sage, and custom-built systems.

What “Data Migration” Actually Means in Business Central

Data migration is not a file copy. It’s not a database backup and restore. It’s a structured process of extracting data from your legacy system, mapping it to Business Central’s data model, transforming it to fit, cleansing the garbage, validating the result, and loading it into a clean target environment.

Business Central has its own way of organizing everything. Your old system’s “customer record” doesn’t map one-to-one to BC’s customer card. BC has posting groups, dimensions, number series, and validation logic that your legacy system may not enforce — or enforced differently. A customer code that worked fine in QuickBooks might be invalid in BC because BC requires a specific format or doesn’t allow special characters your old system tolerated.

This is why “just export to Excel and import” fails. You might get the rows in, but they’ll fail posting the moment someone tries to use them — because the dimensions are missing, the posting groups are wrong, or the G/L accounts don’t tie to the chart of accounts.

A proper migration involves:

• Extraction: Getting data out of the source system, ideally via API or database export, not CSV copy-paste
• Mapping: Defining exactly which source fields go to which BC fields — and which BC fields need default values because the source has no equivalent
• Transformation: Converting data formats, splitting or merging fields, recalculating values
• Cleansing: Removing duplicates, fixing inconsistencies, deactivating obsolete records
• Validation: Checking that balances match, trial balances tie, inventory quantities reconcile

If your implementation partner treats this as a single step during go-live week, you’re in trouble.

Master Data vs. Transactional Data: What Moves, What Stays

This is the most important distinction to understand before your migration starts.

Master Data (Always Moves)

Master data is your business’s reference data — the entities and structures everything else depends on. This data is relatively small in volume but critically important to get right:

Master data volume is typically hundreds to low thousands of records per type. A mid-size distributor might have 2,000 customers, 500 vendors, 5,000 items, and a 200-line chart of accounts. That’s manageable — if the data is clean.

Transactional Data (Selectively Moves)

Transactional data is the day-to-day activity: invoices, payments, receipts, journal entries. You don’t migrate all of it. You migrate what’s needed for continuity:

The rule of thumb: migrate what you need to continue operating on day one, archive the rest.

Your legacy system becomes a read-only archive. You keep a license (or export to a static database) so you can look up old transactions, but you’re not running dual systems. Every client who tried to migrate “everything” — every historical transaction since the company was founded — saw their timeline triple and their budget blow up. Don’t do it.

Why Historical Data Stays Behind

Business Central’s posting structure is fundamentally different from older systems. NAV 2013’s item ledger entries don’t map one-to-one to BC’s. QuickBooks transactions don’t have the dimension and posting group depth BC expects. Trying to force-fit 15 years of transactions through transformation scripts is a fast track to corrupted data.

You keep the old system for lookups and audit purposes. If a customer disputes an invoice from 2019, you open the archive — same as you would have done anyway. You don’t need that invoice in BC.

The Tooling: How Data Actually Gets Into BC

There are several approaches, and which one you use depends on your source system, data volume, and budget.

Configuration Packages (RapidStart)

RapidStart Services for Business Central is Microsoft’s built-in data import tool. It uses configuration packages — essentially templated Excel workbooks — that map to BC tables. You fill in the Excel sheets, import them, and BC validates and creates the records.

Best for: Simple source systems (QuickBooks, Xero, spreadsheets), smaller data volumes, straightforward master data.

Limitations: No built-in transformation logic. If your source data needs reshaping — splitting a field, combining values, recalculating — you do that in Excel before import. For transactional data with dependencies (an invoice references a customer which references a posting group), you must load in exactly the right sequence or imports fail.

APIs (Business Central API v2.0)

BC exposes a comprehensive REST API for creating and updating records. You can write scripts (PowerShell, Python, C#) that read from your source system and write to BC via API calls.

Best for: Complex migrations with transformation logic, systems with API access on both sides, transactional data with dependencies.

Limitations: Requires development effort. API rate limits apply. Large volumes take time — you might need to run scripts overnight or across multiple days.

Custom AL Extensions

For the most complex scenarios — multi-entity, heavy transactional data, systems with proprietary data structures — partners build custom AL extensions that handle the entire migration pipeline inside BC.

Best for: NAV-to-BC migrations (same family, familiar data model), massive data volumes, complex validation rules.

Limitations: Highest cost and longest build time. Only worth it when other methods can’t handle the complexity.

Third-Party Tools

Tools like Scribe, KingswaySoft, and Layer2 exist for ETL (Extract, Transform, Load) between systems. They sit between source and BC, handling mapping, transformation, and error handling.

Best for: Migrations from major ERPs (SAP Business One, Sage, NetSuite) where pre-built connectors exist.

Limitations: License cost. Learning curve. You’re adding another tool to a process that already has enough moving parts.

What We Actually Use

In practice, most migrations combine methods. A RapidStart package for master data, API scripts for open transactions, and maybe an AL extension for anything the standard tools can’t reach. There’s no single “right” tool — there’s the right combination for your specific migration.

The Timeline Nobody Publishes

Here’s what data migration actually looks like, week by week, based on real projects.

This assumes a standard migration — mid-size company, one source system, moderately clean data. It can go faster (3 weeks for a simple QuickBooks migration with clean data) or slower (8+ weeks for multi-entity, multi-system migrations with heavy cleansing).

The non-negotiable: You cannot compress this into go-live week. If your partner’s project plan shows “data migration” as a single line item in the final week, have a serious conversation about what exactly they’re planning — and what they’re skipping.

The 5 Things That Destroy a Business Central Migration

We’ve seen these patterns repeat across dozens of projects. Here’s what kills a migration — and how to avoid each one.

1. Bad Data in the Source System

A migration doesn’t fix bad data. It moves bad data from one system to another, often making it worse because the new system applies validation the old one didn’t.

The classic example: duplicate customers. John Smith exists as CUST001, CUST001-A, and JS-2021. They all have open balances. The migration script doesn’t know these are the same customer — it creates three customer cards in BC, and now you have receivables split across three records that should be one.

Fix it before migration: Deduplicate, standardize, deactivate. Run a data quality audit before you start any technical work. Budget at least 20% of the migration timeline for cleansing — if your partner isn’t talking about this, they’re being optimistic.

2. Scope Creep Mid-Migration

The migration is halfway through week 3 when someone says: “Actually, can we also bring over five years of sales history? The sales team wants historical reporting.”

Suddenly you need to map, transform, and validate years of transactional data that wasn’t in scope. The mapping decisions change. The validation effort triples. The timeline slips by weeks.

Lock scope early: Define exactly what moves in the project initiation document. Any “let’s also bring over” requests go into a phase 2 backlog, not the current migration.

3. No Budget for Data Cleansing

Companies budget for partner fees and licensing, but not for their own team’s time to clean data. Then the project lead discovers that 30% of item records have no cost, 15% of vendor bank details are outdated, and the chart of accounts hasn’t been reviewed since 2018 — and nobody has time to fix it all.

Budget for it: Estimate cleansing effort honestly. A mid-size company with 5,000 item records and moderate data quality issues will need 40–80 hours of internal time for data cleansing. Factor it into the project plan — or accept that dirty data goes live, and you’ll fix it under pressure post-go-live (which costs 3x more).

4. Treating Migration as IT-Only

IT can extract data and run scripts. Finance needs to validate that the trial balance ties. Operations needs to confirm inventory quantities match physical counts. Sales needs to verify customer payment terms and credit limits.

When migration is treated as a technical exercise owned solely by IT, the validation step fails. Nobody from the business side checks the data until go-live week, and that’s when they discover the chart of accounts mapping is wrong or vendor payment terms are missing.

Every department validates their own data. The partner handles the technical pipeline. Your team handles the business validation. This is not optional.

5. Skipping the Trial Migration

The single most expensive mistake. A partner loads data directly into the production environment two days before go-live, crosses their fingers, and hopes everything works.

It doesn’t. Balances don’t tie. Posting groups are misconfigured. The trial balance is off by €47,000 and nobody knows why. Go-live is delayed — or worse, goes ahead with bad data that takes months to untangle.

Always do at least one full trial migration into a sandbox environment. At least two weeks before go-live. Every record type. Validate everything. Fix what’s broken. Then do another trial if the first one had significant issues. The trial migration is not a nice-to-have — it’s the safety net that catches problems when there’s still time to fix them.

Pre-Migration Checklist for Clients

Before your partner starts the first migration script, here’s what you need to have done:

• Identify all source systems. If you think you have “one system” but warehouse uses a separate WMS and sales uses a CRM that feeds the ERP, you have three.
• Assign a data owner for each domain. Finance owns G/L and customers. Operations owns items and inventory. Sales owns customer pricing. One person per domain who can make decisions.
• Run a data quality audit. Export your master data. Sort by last activity date. Flag everything inactive for 2+ years for deactivation. Find duplicates. Identify missing critical fields.
• Deactivate obsolete records. Don’t delete — you might need the history. But flag inactive customers, discontinued items, and closed vendors so they don’t migrate to BC as active records.
• Reconcile before extracting. Trial balance, aged receivables, aged payables, inventory valuation — all of it should tie before you extract. Fix reconciliations in the old system, not during migration.
• Standardize naming and formatting. Item descriptions that follow a pattern. Customer names with consistent capitalization. No special characters in codes unless BC supports them. Do this in the source — it’s easier than fixing it in the migration pipeline.
• Verify bank account details. One wrong digit in a vendor bank account number creates hours of payment troubleshooting post-go-live. Verify now.
• Review the chart of accounts. This is your last chance to restructure before it gets locked into BC. Merge redundant accounts. Add dimensions. Plan the structure you actually want, not what you inherited.
• Block time for validation. Every data owner needs 4–8 hours to validate their domain after each trial migration. Put it on calendars now.

Post-Migration Validation: What to Check Before Go-Live

After the final migration into the production environment, here’s the validation punch list — the minimum you must verify before anyone transacts in BC:

Financial Validation

• Trial balance ties to the source system at cut-off date. Every G/L account. Not “close enough.” Exact.
• Aged accounts receivable matches: total outstanding and aging buckets tie to the source report.
• Aged accounts payable matches: same standard.
• Bank balances reconcile to the last bank statement before cut-off.
• VAT/tax control accounts match the source system — if they don’t, your first tax filing from BC will be wrong.

Operations Validation

• Inventory quantities match the last physical count, by location and bin if you’re using warehouse functionality.
• Inventory valuation ties to the source system. If you use standard costing, standard costs are set correctly. If actual costing, the valuation method transfers correctly.
• Open sales orders are complete — every line, every quantity, every ship-to address.
• Open purchase orders are complete and receipt-capable.

Master Data Spot Checks

• Sample 20 customers: verify name, address, payment terms, currency, posting group.
• Sample 20 vendors: same, plus bank details.
• Sample 20 items: description, base unit of measure, cost, price, item category.
• Verify the chart of accounts: every account, every posting group assignment.

System Validation

• Post a test sales invoice end-to-end and verify it flows through to G/L correctly.
• Post a test purchase invoice.
• Process a test payment.
• Run financial reports and verify they produce expected output.

The sign-off rule: Every data owner signs off on their domain in writing. Not a Slack message. Not a nod in a meeting. A written confirmation that they’ve validated their data and it’s correct. This sounds bureaucratic. It’s insurance — for you and for the partner.

What This Costs: Migration Pricing in Context

Data migration is typically included in the implementation fee — not priced separately — because it’s inseparable from configuration. However, the scope of migration heavily influences the overall project cost.

In the context of a Business Central implementation:

• A lightweight implementation (€8K–15K) usually includes migration from a simple source (QuickBooks, Xero, Excel) with clean data. Master data plus open transactions. Typical: 2–3 weeks of migration effort.
• A standard implementation (€18K–40K) includes migration from a structured ERP (NAV, SAP Business One, Sage) with moderate data cleansing. The migration effort is typically 3–5 weeks within the overall project.
• A complex implementation (€45K–90K+) includes migration from multiple systems, heavy transformation, or custom AL extensions. Migration can run 5–8+ weeks and may require a dedicated data architect on the partner team.

What drives migration cost up (within the implementation fee):

• Data that requires heavy cleansing before it can be loaded — duplicate resolution, standardization, missing-field remediation
• Multi-system sources (ERP + CRM + WMS that all feed into BC)
• Large transactional data volumes (thousands of open invoices, complex inventory)
• Custom transformation logic requiring AL development
• Multi-entity consolidations with intercompany balances to reconcile

What keeps it down:

• Clean, well-maintained source data
• A single source system
• A client team that handles cleansing internally before the partner touches the data
• Clear scope — you’ve already decided what moves and what doesn’t

For a deeper dive into implementation costs, see our 2026 pricing breakdown.

The Bottom Line

Data migration is where the bill for years of neglected data maintenance comes due. The companies that sail through it are the ones that treat data quality as an ongoing discipline, not a one-time project they scramble through before go-live.

If you take nothing else from this guide: start cleaning your data now, before you’ve even selected a partner. Every duplicate you fix, every inactive record you deactivate, every reconciliation you close — that’s time and money you don’t spend during the implementation.

And always, always do a trial migration. We’ve never met a company that regretted the dry run. We’ve met plenty who regretted skipping it.

Need help planning your Business Central data migration? Our team handles migrations from NAV, QuickBooks, SAP Business One, Sage, Excel, and custom legacy systems. See our implementation services or reach out for a migration readiness assessment.