Business Central Data Migration Field Mapping Worksheet
A mapping sheet is the first document a Business Central migration lives or dies by. This worksheet gives you one row per legacy field, the BC table and field it lands in, the rule you will apply and how clean the data is today. Edit it in the browser and export to Excel.
| Source table / file | Source field | BC table | BC field | Transformation | Records | Clean % | Ready to load | Owner | |
|---|---|---|---|---|---|---|---|---|---|
1,795 | |||||||||
1,332 | |||||||||
582 | |||||||||
4,316 | |||||||||
420 | |||||||||
171 |
Add one row per field you plan to load. Records are counted per field so weak fields stand out. Export to Excel and share with the data owners listed in the Owner column.
Mapping sheet review
Send us your exported mapping sheet and we will point out missing dependencies and risky fields. Optional.
Optional. The tool and every export work without this. No spam.
How to use the worksheet
Start with the master data that everything else depends on: customers, vendors, items, the chart of accounts and dimensions. For each legacy field add a row, choose the target BC table, and type the target field name as it appears in the BC page or in the configuration package field list. Pick the transformation type, then record how many records exist and what share passes your validation rules. The ready-to-load column and the overall readiness figure update as you type.
- One row per field, not per table, so weak fields are visible
- Use Lookup / cross-reference for anything that needs a BC code to exist first, such as payment terms or posting groups
- Assign every row an owner who can fix the source data
What good mapping looks like
Business Central requires that referenced setup records exist before the master data that uses them. Payment terms, units of measure, posting groups, countries and dimension values must be loaded or configured first, or the import of customers, vendors and items fails on validation. Sort your sheet by load sequence, not alphabetically, and add the dependency to the Transformation or Owner text. Keep the numeric key rules explicit: BC number series, code length limits such as 20 characters for many code fields, and case handling all affect legacy IDs.
Reading the readiness figure
Overall readiness is the sum of ready records divided by the sum of records across all rows. It is weighted by volume, so a field with thousands of records drags the figure more than a small table. Treat anything below roughly 80 percent as a signal to schedule a cleansing sprint before the first trial load. A high figure does not prove correctness; it only says records pass the rules you wrote down.
Common mistakes
Teams often map only the visible fields and discover mandatory ones during the first import. Check required fields on each BC page and any extension fields your partner has added. Another frequent gap is ignoring open transactions: balances, open sales and purchase documents, inventory by location and bin, and fixed asset depreciation books each need their own mapping rows and a reconciliation plan.
Frequently Asked Questions
Should I map into configuration packages or use Excel and the Edit in Excel feature?
Configuration packages suit larger first loads of master data across several tables, with validation and error reporting. Edit in Excel suits small corrections to existing records. Many partners use packages for cutover and Excel for cleanup. This sheet works for either approach.
How many fields should a typical BC mapping sheet include?
It depends on scope, but master data alone for customers, vendors, items and accounts often reaches 100 to 300 mapped fields once extensions and dimensions are included. Start with required fields and the fields that drive posting, then add reporting fields.
Does the worksheet connect to my BC environment?
No. It runs entirely in your browser and nothing is sent anywhere. You export the sheet to Excel and use it as a planning and tracking document alongside your own configuration packages or load tools.
How do I handle data that does not fit any BC table?
Choose Other as the BC table, describe the intended handling in the BC field column, and decide whether it needs an extension field, an attachment, a dimension or should be archived outside the system. Record the decision so it is not lost.
If your source is NAV, SyteLine, Epicor or a spreadsheet estate, Netray can help profile the data and build repeatable load scripts under human review. Ask for a review of your mapping sheet.
Related Tools
Business Central Chart of Accounts Mapping Worksheet
Map legacy accounts to Business Central G/L accounts, flag account types and direct posting, and reconcile opening balances to zero variance.
Microsoft DynamicsBusiness Central Go-Live Cutover Plan Template
A cutover runbook for moving to Business Central: freeze, extract, load, reconcile, go/no-go decision, hypercare and rollback.
Microsoft DynamicsBusiness Central Implementation Statement of Work Template
A fill-in SOW for Business Central projects covering scope, phases, deliverables, assumptions, change control and acceptance.
More Microsoft Dynamics tools
See all- Business Central API v2.0 URL Builder
- Business Central Configuration Package Worksheet
- Business Central Permission Set Design Worksheet
- Business Central Year-End Close Checklist
- Business Central Posting Groups Setup Worksheet
- Business Central Functional Design Document Template
- Business Central User Acceptance Test Script Template
- Business Central License Cost Calculator
- Business Central Core Table Numbers Reference