How to map a source system to a target system
Record how fields in a source system correspond to a target, then check what the change affects before it is scheduled.
When this is useful
- A migration is being planned and the mapping currently lives in a spreadsheet nobody owns.
- An integration needs a specification the receiving team can implement against.
- You need to prove which source fields feed a reported number.
Before you start
- Both models present — see how to import a database schema if the source exists only as a database.
Step 1: Open Source→Target Map
The mapping tool sits in the Data menu alongside the rest of the data landscape tools.
Data ▸ Source→Target MapData ▸ Data Manager
Step 2: Record the mapping at field level
Map fields rather than tables. A table-level mapping looks complete and answers none of the questions that arise during implementation.
Step 3: Check what it disturbs
Run Impact Analysis against the source objects. A migration that changes a field is a change like any other, and the things that consume that field are the ones that will break.
Data ▸ Impact Analysis
What happens next
The mapping is part of the model rather than an attachment, so lineage can follow it and a later change to either side is visible against it.
If the target is a new schema, Delta DDL produces the migration script between what is modelled and what is deployed.
Example
A CRM consolidation: 214 field mappings recorded, of which impact analysis showed 31 fed live reporting — those became the migration's first phase rather than being discovered on cutover weekend.
Tips
- Record the transformation, not just the correspondence. "source.amount → target.amount_cents, ×100" is a specification; an arrow is not.
- Map the fields nobody uses too, and mark them. Deciding not to migrate something should be a recorded decision.
Limitations
- Impact analysis follows recorded relationships only, so a consumer nobody modelled is a consumer it cannot warn you about.