# Migration mapping

From legacy discovery to a validated mapping: map the source, let the Migration agent propose candidates, have experts validate, find problems before load.

## Map the source first

A migration starts with a source system nobody fully understands: decades of schema, custom fields, a few people who remember why. The usual approach is weeks of mapping by hand before a record moves.

Datapace starts by documenting the source the same way it documents any estate: infer the graph, confirm it with the people who know the system. See [documenting an estate](/docs/guides/documenting-an-estate). Once the source is a confirmed graph, the mapping has something to start from.

## Candidate mappings

The Migration agent proposes field-level mappings from the source graph into the target model. Each candidate carries a confidence score and the evidence behind it: matching semantics, matching value shapes, the lineage that shows which source field actually feeds the number the business reports.

An illustrative slice of a mapping:

| Source | Target | Confidence | Note |
| --- | --- | --- | --- |
| `CUST_MASTER.CUST_NO` | Customer, external id | High | Unique, referenced by every order |
| `CUST_MASTER.CUST_TYPE` | Customer, is vendor flag | Medium | Two of nine codes mean vendor; expert to confirm |
| `ORD_HDR.CURR` | Order, currency | High | Three currencies in use, one row in a fourth |
| `CUST_MASTER.REMARKS` | To decide | Low | Free text, phone numbers in some rows |

## Expert validation

Every mapping row is validated by a domain expert, the way every fact in the graph is. A high-confidence row is confirmed in seconds; a medium one is a question with the evidence attached; a low one is a decision the expert makes with the business. Nothing loads on an inferred mapping.

## Findings before load

Because the source is confirmed and the target model is known, the problems that usually surface after the first load surface before it:

- **Duplicate keys.** Two customer records that the target model treats as one.
- **Mixed currencies.** Amounts in a column the target expects in one currency.
- **Orphaned rows.** Lines whose header was deleted years ago.
- **History the target does not want.** Closed accounts, retired products, the years before the cut-off.

Each finding is a proposal: keep, merge, convert, or drop, decided by the expert, recorded with the reason.

## The decision trail

Every mapping and every finding is recorded with who decided, what the evidence was, and when. When the migration is questioned later, and it will be, the trail answers with the decision and its reason rather than with a spreadsheet nobody can date.

## Targets

The target model decides what the candidate mappings look like. The use-case pages describe the three targets Datapace's ERP work is documented for: [Odoo](/use-cases/erp-migration-odoo), [Microsoft Dynamics 365](/use-cases/erp-migration-dynamics-365), and [Workday Financial Management from PeopleSoft](/use-cases/peoplesoft-to-workday-migration). The same map serves a move to a new engine or a new cloud.