How to use it
- 01
Set the scope first
Give each kind of data a level before mapping anything. Deciding that closed orders are archived, for example, removes a large mapping task and shortens every trial run.
- 02
Map one record type
Take a single record type and list every field the new system needs, with its source. Fields with no source, and source fields with no target, are both findings worth raising.
- 03
Write the awkward rules
Conversions, defaults for empty values and reasons for rejection are where migrations go wrong. Each needs a decision from someone who uses the data, written in plain words.
- 04
Define the proof
Choose the checks, the totals that must agree and who signs. Agreeing these before the first trial run means the result is judged against a standard, not against relief that it finished.
What a migration mapping has to contain
Developers can move data from one structure to another. Whether the result is right is a business question, and the mapping is the document that lets the business answer it in advance.
| Part | What it settles | Why it matters |
|---|---|---|
| The move | Source, target, cutover and the business owner | Someone with authority must decide the rules |
| Scope | Move, archive or leave, per kind of data | The cheapest data to migrate is data you decide not to |
| Field mapping | Every target field with its source and rule | The only reviewable statement of what will happen |
| Conversions and defaults | Codes, formats and empty values | Silent defaults are the commonest source of wrong data |
| Cleaning | Duplicate rules, who cleans and where | Corrections at the source survive every rehearsal |
| Proof | Checks, control totals, trial runs and sign-off | Turns the migration from a hope into evidence |
A worked example
A plumbing supplier maps its customer records
The example is an invented plumbing supplier moving to a new ERP. Load it to see a completed sheet for one record type. The detail in the defaults and duplicates boxes is what makes it usable.
- ScopeOpen items and the current year move. Closed orders and old invoices are archived, which the financial controller agreed after confirming retention rules.
- Awkward rulesSix old payment codes become four. A customer with no terms defaults to cash only, a choice the sales office made deliberately.
- ProofThree trial runs, with customer count, open order value and outstanding balance as the totals that must agree.
The sheet can be read and challenged by the sales office in ten minutes. That review, before any script runs, is where wrong assumptions are cheapest to correct.
What this tool does not do
The template records decisions. It does not look at your data.
- It does not profile the source, so it cannot tell you how many records break your rules.
- It does not move anything. Extraction, loading and reconciliation are engineering work.
- Retention periods are set by law and differ by country. Confirm yours with an adviser.
- The sheet lives in this browser until you copy or download it.
What to do with the finished document
Have the people who use each record type read its sheet and sign it, then give the set to whoever will carry out the move. If you want a second opinion on the mapping, send one sheet and we will comment on it. Send it through the contact page or book a 30-minute call and bring it along.
Common questions
What is a data mapping in a migration?
It is the document that states, for every field in the new system, where its value comes from in the old one and how it is transformed on the way. It also covers what happens when a value is missing or invalid. It is written before any data moves, so that the people who rely on the data can review it.
Who should fill in the mapping template?
Someone who knows what the data means, working with someone who knows both systems' structures. In practice that is a business user and an analyst or developer together. A mapping written by a developer alone will be technically complete and will miss the meaning of old codes, special cases and fields that were reused for other purposes.
Why map one record type at a time?
Because each has its own fields, rules, owner and reviewers. Customers are reviewed by sales, stock by the warehouse, balances by finance. A separate sheet per record type lets each group check what concerns it, and makes it obvious which parts of the migration are ready and which are still open.
How detailed should the field mapping be?
Detailed enough that two different developers would produce the same result from it. Every target field needs a source or a rule, every conversion needs its table of old and new values, and every default needs to be stated. If a line contains the word probably, the decision behind it has not been made yet.