Baan to Infor LN Data Conversion Mapping Worksheet
A data migration fails in the details: a unit of measure that does not match, a status that has no target, a date held as text. This worksheet puts every field decision in one place so the team and the business can see what is mapped, who owns it and how much has loaded.
| Business entity | Source table | Source field | Target LN table | Target field | Transform rule | Load method | Owner | Source rows | Rows loaded | Row gap | Status | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
12 | ||||||||||||
0 | ||||||||||||
600 | ||||||||||||
960 |
Table and field codes in the example rows are illustrative. Confirm every target table and field against your LN data dictionary and VRC before use.
Data mapping review
Optional: share the mapping and we will point out missing cross-references and risky transforms.
Optional. The tool and every export work without this. No spam.
How to use it
Create a row for each source field you intend to carry across. Name the business entity so reviewers can filter by Item, Business partner, Open sales orders and so on. Record source and target table and field, then choose a transform rule. Pick the load method that matches how you will load the data: an exchange scheme, a session import, a BOD or API call, a SQL load or a manual entry for small sets. Enter source rows and rows loaded after each trial run. The row gap column shows what is missing, and the completeness summary gives a single progress number.
- One row per field, grouped by entity
- Pick a rule for every row, including Drop
- Name an owner who can answer data questions
- Update row counts after each trial load
Choosing transform rules
Direct copy is rare in practice. Units, statuses, tax codes, currencies and warehouse codes almost always need a lookup table, so keep that cross-reference as its own signed-off artifact and name it in the notes. Concatenate and Split cover fields that were merged or divided differently in the old system. Default value is acceptable only when the business confirms what the value should be. Mark fields you will not carry as Drop, with the owner's agreement, so nobody wonders later whether it was missed.
Reading the gap and completeness
A small row gap on a master entity such as business partners usually points to rejected records: duplicate keys, missing mandatory fields or invalid references. Open the load log and group the rejections by reason, then fix the cause in the source or the rule rather than patching individual records. A large gap on transactional entities such as open orders often means the entity was loaded in the wrong sequence. Load masters first, then the transactions that refer to them. Completeness is a progress measure, not a quality measure, so also reconcile values and totals.
Common mistakes
Teams map only the fields they can see in the old screens and miss fields used by reports and integrations. They also skip reconciliation: a load that reports success can still carry wrong values. Plan at least two full trial loads and compare record counts, financial totals and a sample of records field by field. Finally, freeze the mapping before the final rehearsal, and put later changes through change control.
Frequently Asked Questions
Does this worksheet load data into LN?
No. It is a planning and tracking sheet. The actual load runs through exchange schemes, import sessions, BODs or your chosen method. Use the sheet to control scope, ownership and progress, and export it to Excel for reviews.
How many trial loads should I plan?
At least two full trial loads before cutover plus a final rehearsal is a sensible minimum. Complex data with many cross-references often needs more. Each trial should have a documented reconciliation.
What order should entities be loaded in?
Load reference data first, then business partners and items, then structures and routings, then open transactions. The rule is that referenced records must exist before the records that point to them.
Are the example table codes correct for my system?
They are illustrative. Table and field names depend on your LN version and customer VRC. Verify them in the data dictionary before you commit them to the mapping.
If your legacy data is messy and the mapping is stalling, we can discuss using a private, on-prem model to profile source data and suggest cross-references, with your team approving every rule.
Related Tools
Infor LN and Baan Customization Inventory Worksheet
Editable worksheet to list every Baan or LN customization with type, owner, effort and a retire, keep or replace decision.
Infor LN & BaanInfor LN Cutover Runbook Template
Editable task-by-task cutover plan with owners, durations, dependencies and total cutover hours.
Infor LN & BaanInfor LN Go-Live Readiness Checklist
Go or no-go checklist for an LN implementation, upgrade or Baan migration, with critical items flagged.
Infor LN & BaanBaan Data Migration Effort Calculator
Estimate the hours, cost, and timeline to migrate your Baan data to Infor LN based on table scope, record volumes, data quality, and load iterations.
More Infor LN & Baan tools
See all- Infor LN Session and Module Code Reference
- Infor LN Production Order Status and Lifecycle Reference
- Infor LN 4GL Session Script Template
- Infor LN Company and Enterprise Unit Design Worksheet
- Infor LN DAL Hook Review Checklist
- Infor LN Warehousing Order Origins and Types Reference
- Infor LN Table Name and SQL Query Builder
- Infor LN Regression Test Effort Calculator
- Infor LN User Role and Authorization Matrix Worksheet