# ERP Data Migration Mapping Worksheet (Source to Target Fields)

> Source: https://netray.co/tools/eu-erp-data-migration-mapping-worksheet
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Editable source-to-target field mapping sheet for moving a legacy ERP into abas, proALPHA, IFS, Exact or any other target. Tracks rules, owners and sign-off.

## Category

erp-migration

## Region

Europe

## Industry

Discrete Manufacturing

## Audience

- ERP project manager
- Data migration lead
- ERP consultant

## Tool

**Kind:** worksheet

**Mode:** editable

**Columns:**

#### Data object

**Key:** object

**Type:** select

**Options:**

- Item master
- Customer
- Supplier
- BOM
- Routing
- Open sales order
- Open purchase order
- Stock balance
- GL balance
- Asset

#### Source field

**Key:** src_field

**Type:** text

#### Target field

**Key:** tgt_field

**Type:** text

#### Transformation rule

**Key:** rule

**Type:** text

#### Records

**Key:** records

**Type:** number

#### Rejects in last load

**Key:** rejects

**Type:** number

#### Reject rate

**Key:** reject_pct

**Type:** number

**Expr:** if(gt(records,0), rejects / records * 100, 0)

**Format:** percent

#### Data owner

**Key:** owner

**Type:** text

#### Status

**Key:** status

**Type:** select

**Options:**

- Not started
- Mapped
- Loaded in test
- Reconciled
- Signed off

#### Due date

**Key:** due

**Type:** date

**Rows:**

**Object:** Item master

**Src field:** ITEM.DESCRIPTION (60 chars)

**Tgt field:** Item.Description1 / Description2

**Rule:** Split at word boundary after 40 characters

**Records:** 18400

**Rejects:** 230

**Owner:** Planning lead

**Status:** Loaded in test

**Due:** 2026-11-15

**Object:** Customer

**Src field:** CUST.VAT_NO

**Tgt field:** Customer.VATID

**Rule:** Strip spaces, validate country prefix, check VIES offline

**Records:** 2150

**Rejects:** 41

**Owner:** Sales admin

**Status:** Mapped

**Due:** 2026-11-20

**Object:** Supplier

**Src field:** VEND.PAY_TERMS

**Tgt field:** Supplier.PaymentTerm

**Rule:** Lookup table old code to new term code

**Records:** 960

**Rejects:** 12

**Owner:** Purchasing

**Status:** Loaded in test

**Due:** 2026-11-22

**Object:** BOM

**Src field:** BOM.QTY_PER

**Tgt field:** BOMLine.Quantity

**Rule:** Convert scrap factor into separate scrap percent field

**Records:** 31200

**Rejects:** 610

**Owner:** Engineering

**Status:** Mapped

**Due:** 2026-12-01

**Object:** Stock balance

**Src field:** INV.ONHAND

**Tgt field:** StockLedger.OpeningQty

**Rule:** Load by location and lot, valued at standard cost

**Records:** 7800

**Rejects:** 95

**Owner:** Warehouse lead

**Status:** Not started

**Due:** 2026-12-10

**Totals:**

#### Total records

**Key:** records

**Agg:** sum

**Format:** integer

#### Total rejects

**Key:** rejects

**Agg:** sum

**Format:** integer

**Summary:**

#### Overall reject rate

**Key:** overall_reject

**Expr:** if(gt(sum_records,0), sum_rejects / sum_records * 100, 0)

**Format:** percent

**Primary:** true

**Notes:** Add one row per field, not per object, once mapping starts. Keep the rule column precise enough that a second person could rebuild the load script from it.

## Content

**Intro:** A mapping worksheet is the single document every data migration depends on. It states, field by field, where a value comes from, where it lands in the new ERP and what happens to it on the way. This version computes reject rates per row so you can see which objects are hurting each trial load.

**Sections:**

#### How to use the worksheet

**Body:** Start with one row per field of each data object you plan to migrate. Fill the source and target names exactly as they appear in the legacy table and the new system's field list, then write the transformation rule in plain language. After every trial load, update the records and rejects columns and move the status forward. The reject rate column is calculated for you and the summary shows the overall rate across all rows.

**Bullets:**

- One owner per row, a business person and not the consultant
- Write rules as lookups, splits, defaults or formulas
- Update rejects after every trial load, not only the last one
- Keep a separate tab for code translation tables

#### What to map and in what order

**Body:** Load static master data first: units of measure, currencies, payment terms, tax codes, then customers, suppliers and items. Structures such as BOMs and routings come next because they depend on items and work centres. Open transactions, stock balances and finance opening balances are loaded last and reconciled against the legacy system. European projects also need legal fields mapped carefully, such as VAT IDs, IBAN and BIC, commodity codes for Intrastat and country of origin.

#### Reading the reject rate

**Body:** A reject rate under one percent on master data is a reasonable target for the final dress rehearsal, but the number matters less than the reasons. Group rejects by cause: missing mandatory field, failed validation, duplicate key or unmapped code. Fix the cause in the source data where possible, not in the load script, so the clean data stays clean after go-live.

#### Common mistakes

**Body:** Teams often map only the fields they know the legacy system has and forget that the target requires new mandatory fields. Others migrate everything, including a decade of inactive items, which inflates the effort and the reject count. Agree an inactivity cut-off early and archive the rest. Finally, do not let the mapping live only in the consultant's laptop; the customer must own and sign it.

**Cta:** If your migration source is Infor SyteLine, Baan or another system we work with, we can generate a first-draft mapping from the schema for you to review. Entirely optional.

**Faq:**

#### How granular should a mapping row be?

**Answer:** One row per target field is the safest. Object-level rows hide the transformation logic, and that logic is where most rejects come from. A BOM with fifteen fields should have fifteen rows, even if twelve of them are a straight copy.

#### Who should sign off the mapping?

**Answer:** The business data owner for each object signs the rows, for example purchasing for suppliers and engineering for BOMs. The project manager tracks status, and the technical lead confirms that each rule is implementable in the load tool.

#### Does this work for non-European ERPs?

**Answer:** Yes. The structure is system neutral. The European angle is only in the example rows, such as VAT ID validation and Intrastat related fields. Replace those with local equivalents for your own country.

#### How often should reject counts be updated?

**Answer:** After every trial load. Typical projects run three to five trial loads, and the trend across loads is the best indicator of readiness. A flat reject count between loads means the root causes are not being fixed.

## Search terms

erp data migration mapping template, data mapping template excel, erp migration field mapping, legacy erp data mapping worksheet, item master migration mapping, erp data migration template, source to target mapping template

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json