Ask anyone who has lived through an ERP project what they wish they had started earlier, and “data migration” is usually near the top of the list. Not because it is glamorous, but because it quietly affects everything that happens on day one and beyond.
The hard part is not moving data from System A into Business Central. The hard part is deciding:
- What really needs to live inside Business Central
- What can stay in legacy or an archive and still be usable
- How far back you actually need to go
- How much cleanup is worth doing before you load
This playbook is a practical guide to those decisions so you can go live with a clean, useful Business Central environment instead of dragging twenty years of baggage into your new system.
Why Business Central Data Migration Deserves Its Own Plan
It is tempting to treat data migration as a technical task that happens near the end of the project. In reality, it is a design decision that sits at the intersection of:
- Accounting and finance reporting
- Operational processes like sales, purchasing, and inventory
- Compliance and audit needs
- Everyday user behavior, where people actually go to find answers
If you decide what to bring and what to leave behind in a rush, you usually pay for it later in the form of awkward workarounds, confusing history, and frustrated users who keep logging back into the old system.
Business Central Data Migration: The Three Types of Data
It helps to group your data into three broad buckets before you talk about tools or file formats.
1. Master data
Core records that everything else depends on:
- Customers and ship-to addresses
- Vendors
- Items, resources, bills of material, variants
- Chart of accounts and dimensions
- Posting groups, payment terms, shipping agents, tax areas
These are almost always “bring it, but clean it” candidates. Duplicates, inconsistent naming, and half retired codes will follow you into Business Central if you do not decide what should survive and how it should look.
2. Open and in flight data
Anything that is still active at cutover:
- Open sales orders and quotes
- Open purchase orders
- Open accounts receivable and accounts payable
- Inventory on hand and item ledger entries around cutover
- Bank balances and unreconciled transactions
- Projects or jobs in progress
This is the non negotiable set. If you cannot see and manage open activity in Business Central on day one, users will immediately reach for the old system.
3. Historical data
Everything that is closed and in the past:
- Posted invoices, shipments, receipts
- Detailed ledger entries and audit trails
- Old projects, orders, and service history
- Legacy price lists and promotions
This is where you have the most flexibility and the biggest risk of overdoing it. A lot of teams default to “bring everything since 2004” without asking how often they really need to look ten years back in the operational system.
What You Should Almost Always Bring Into Business Central
Clean, current master data
You want Business Central to be the trustworthy place for core records going forward. That usually means:
- Active customers and vendors, with duplicates merged and obvious junk removed
- Items and resources that you actually buy, stock, or sell
- A cleaned up chart of accounts that matches your future reporting, not just your legacy system
- Dimensions and posting groups that have been deliberately designed, not just copied over
In many cases it is better to bring over only active records and keep the long tail of inactive codes in an archive or reporting database.
Open items and current balances
For a typical migration, you will want at least:
- Open customer invoices and credit memos
- Open vendor invoices and credits
- Open sales and purchase orders that still have work to do
- Inventory on hand, reconciled to your general ledger
- Bank balances per account, reconciled to a specific cutover date
- A general ledger trial balance as of the day before go live
The exact mechanics will depend on your partner and approach, but the goal is the same: Business Central should reflect your financial and operational position as of the cutover date without users needing to cross check the old system.
Some recent transaction history
You do not have to choose between “no history” and “everything back to the beginning of time.” A practical compromise is:
- One to two years of key transactional history, such as posted sales invoices and purchase invoices
- Possibly more for industries with long service or warranty cycles
- Summary entries for older periods so your balances and comparative reporting still work
This gives users enough context for questions like “what did we charge this customer last year” without turning your new system into a mirror of the old one.
What You Can Often Leave Behind (And Still Sleep at Night)
There is always a list of things someone would like to have “just in case.” Bringing all of them into Business Central has a real cost in time, complexity, and risk.
Very old detailed history
Detailed transactions from many years ago usually make more sense in:
- A read only legacy instance
- An archive database or data warehouse
- Exports in a reporting tool
As long as you can answer an auditor’s questions and support any remaining warranty or regulatory needs, you do not need every individual transaction living inside Business Central.
Dead codes and noise
Migration is the perfect time to leave behind:
- Obsolete items with no active inventory or sales
- Customers and vendors you will never work with again
- Dimensions that no one has used for years but still clutter every report
- Old posting groups and tax codes tied to retired scenarios
You can keep them accessible in the archive for historical reporting, but they do not need to be part of the day to day experience in Business Central.
Every low level log and audit trail
System logs, technical audit tables, and low level traces are better suited for specialized storage. What belongs in Business Central is the business record of what was sold, purchased, produced, or posted, not every internal system event from your legacy application.
Data Quality, Clean Up Before You Load
Migration is a rare chance to fix data problems that have been causing pain for years. A few high value clean up passes include:
- Deduplicating customers and vendors. Decide which record wins, align names and addresses, and agree on a single account going forward.
- Standardizing item and resource naming. Make descriptions readable and consistent so searches and reports make sense.
- Mapping your chart of accounts to the new design. Use migration as the moment to simplify and modernize your account structure.
- Rationalizing units of measure and variants. Remove one off units that cause confusion and agree on a standard per item.
- Aligning posting groups and dimensions. Avoid one off combinations that create reconciliation headaches later.
The goal is not perfection. The goal is to ensure that once data lands in Business Central, it supports clean posting, reporting, and day to day work instead of dragging old problems into the new system.
Business Central Migration Scope That Works in the Real World
Every implementation is different, but for many small and mid sized organizations a pragmatic scope looks something like this:
- All active master data, cleaned and deduplicated
- Open AR and AP, open orders, in flight projects, and inventory on hand
- A general ledger trial balance as of the cutover date
- One to two years of key posted documents for operational context
- Summary balances or external archives for older detailed history
This gives you a Business Central environment that feels complete to users on day one, without becoming a multi year data archaeology project.
Common Data Migration Traps to Avoid
A few patterns show up over and over again when migrations go sideways:
- Trying to migrate everything. The more you bring, the more mapping, cleanup, and testing you need. At some point, value flattens while risk rises.
- Postponing decisions about mappings. Waiting until the last few weeks to decide how accounts, dimensions, or items map into Business Central guarantees stress.
- Letting each department define its own codes without a shared design. That can feel flexible during migration and painful once you try to run cross functional reporting.
- Not testing with realistic data. A tiny test file that posts cleanly is not proof that your full data set will behave the same way.
- Ignoring where people will go for old answers. If you do not give users a clear way to find older history, they will keep logging into the legacy system indefinitely.
How to Make Migration Decisions Without Getting Stuck
A simple way to keep discussions moving is to classify each data set into one of three buckets:
- Must have in Business Central. Without this, we cannot operate or report correctly on day one.
- Nice to have in Business Central. Useful, but not required for go live. Candidates for limited history or a phase two.
- Archive only. We need to keep it somewhere, but we do not need it in Business Central for day to day work.
Then ask a short list of questions for each candidate data set:
- Who uses this data today, and for what decisions?
- How often do they need to see it?
- What happens if they have to click into an archive instead of seeing it in Business Central?
- Is there a regulatory or audit requirement that changes the answer?
Those answers usually make it clear whether something belongs in the must have list or can safely move to archive or a later phase.
Frequently Asked Questions
How many years of history should we migrate into Business Central?
It depends on your industry and reporting needs, but a common pattern is one to two years of detailed transactional history in Business Central, with older periods summarized or kept in an archive. If you have long warranty or service cycles, you may choose more for specific document types, such as service or contract history, while still summarizing other areas.
Can we go live without migrating any historical transactions?
In theory, you can go live with only master data, open items, and opening balances. In practice, most organizations find that having at least some recent history inside Business Central makes adoption smoother. Users can answer simple questions about recent pricing, order history, and issues without bouncing between systems.
What should we do with documents like signed contracts or proof of delivery?
Those documents do not always need to live inside Business Central, but they should live somewhere predictable and durable. Many teams use a document management system, a structured file storage pattern, or a CRM to hold the files and then link to them from Business Central via references or custom fields.
How long does data migration usually take?
The technical load itself can be fast once mappings and scripts are ready. The calendar time comes from decisions, cleanup, and testing. For many small and mid sized organizations, data migration runs in parallel with the rest of the implementation and goes through several cycles of test loads before a final cutover. The earlier you start making decisions about scope and mappings, the smoother that timeline becomes.
What if different departments disagree about what to bring?
That is normal. Use the must have, nice to have, and archive only buckets along with a simple cost benefit discussion. If bringing a data set into Business Central adds significant complexity, affects performance, or pushes out go live, it should deliver clear, frequent value to justify that cost.
