What Is Data Mapping?
Also known as: field mapping, source-to-target mapping
Definition
Data mapping is the process of defining how each field in a source system corresponds to a field in a target system, including the transformation rules, value translations, default values, and conditional logic needed to move data correctly between them.
Data Mapping Explained
Every integration and every migration rests on a mapping. At its simplest a mapping says source field A becomes target field B. In practice it must also say what happens when A is empty, when A is longer than B allows, when A holds a code the target does not recognize, when the target requires a value the source never captured, and when one source record must become several target records. The mapping specification is where those decisions are made explicit and reviewable, and undocumented mappings are the most common cause of integration defects that surface months later.
Transformations fall into recognizable classes. Direct moves copy a value unchanged. Format conversions reshape dates, decimals, and text - a source sending YYYYMMDD to a target expecting an ISO timestamp, or a quantity with three implied decimals landing in a field with two. Value translation resolves code lists through cross-reference tables: a customer's unit of measure code CA becoming the internal code BOX, or a supplier's status code becoming an ERP status. Derivations compute a target value from several sources, and constants supply required values the source does not provide.
Cardinality is where mappings get structurally interesting. One source record may become one target record, or a flat EDI line loop may expand into a header and multiple schedule lines, or several source rows may aggregate into one target summary. Getting cardinality wrong produces the classic failure where an order with five lines creates five separate orders, or where a shipment with multiple lots collapses into one and destroys traceability. Cardinality decisions belong in the mapping document alongside field-level rules.
The recurring practical pitfalls are unglamorous and expensive. Field length truncation silently loses characters at the end of long descriptions and addresses. Numeric precision differences round quantities and prices in ways that accumulate. Trailing spaces cause exact-match lookups to fail. Time zone handling shifts dates across a boundary so a shipment appears to occur a day early. Null versus empty string is treated differently by different systems. Code list drift - a partner adding a value nobody mapped - fails quietly if unmapped values default rather than error.
The discipline that separates durable mappings from fragile ones is treating the specification as a maintained artifact rather than a project deliverable. Version it alongside the integration code, record who approved each rule and why, log unmapped values rather than defaulting them, and test with production-representative data including the ugly records - the customer with an apostrophe in the name, the part number with a leading zero, the order with a hundred lines. Those records are where mappings break.
Why It Matters
- Undocumented mapping rules become tribal knowledge, so the only person who can debug an interface is the person who built it.
- Truncation, rounding, and time zone errors corrupt data quietly and are often discovered only during an audit or a customer dispute.
- Cardinality mistakes destroy lot and serial traceability, which is a compliance failure in aerospace, defense, medical, and food supply chains.
- Unmapped code values that silently default rather than error propagate bad data across every downstream system that consumes the feed.
In Practice
Never default an unmapped value - error on it. A supplier mapped inbound EDI unit of measure codes and defaulted anything unrecognized to EA. When a customer began sending CA for case quantities, orders for cases of 24 were entered as 24 eaches, and the error was found only after several shipments went out short. Routing the unmapped code to a monitored exception queue would have surfaced the new value on the first transaction instead of the fortieth.
Frequently Asked Questions
What should a data mapping document contain?
At minimum: source field name, path, data type, and length; target field with the same details; the transformation rule; handling for null and empty values; the cross-reference table used for any code translation; cardinality between source and target records; validation rules; and the error behavior when a rule cannot be satisfied. Version history and approver names make it auditable.
What is a cross-reference table in data mapping?
A cross-reference table stores value translations between systems, such as a trading partner's unit of measure or country codes and the equivalent internal ERP codes. Keeping these in a maintained table rather than hard-coded in transformation logic means business users can add new partner values without a code change, and unmapped values can be detected and reported rather than silently defaulted.
Related Terms
EDI (Electronic Data Interchange)
EDI (Electronic Data Interchange) is the computer-to-computer exchange of business documents such as purchase orders, invoices, and shipping notices between trading partners in a standardized structured format, without human intervention.
EDI 850 Purchase Order
The EDI 850 is the ANSI X12 transaction set used to transmit a purchase order electronically from a buyer to a supplier, carrying header terms, ship-to and bill-to parties, and line item details such as quantity, price, and product identifiers.
Middleware
Middleware is software that sits between applications and handles the communication, transformation, routing, and reliability concerns of moving data between them, so that the applications themselves do not need to know about each other directly.
Go Deeper
AS9100 Audit Readiness Checklist
A 30-point checklist for AS9100 Rev D certification and surveillance audits, weighted toward the aerospace-specific requirements where auditors write the most findings.
Lot Traceability in Electronics Manufacturing
Lot traceability in electronics manufacturing explained: component-level genealogy, ERP lot control setup, IPC-1782 levels, recall readiness, and AI-driven trace.
Serialization Strategies for Defense Electronics
Serialization strategies for defense electronics: IUID and MIL-STD-130 marking, ERP serial control, DFARS compliance, genealogy, and AI-driven serial management.
Working with Data Mapping in a live environment? Our engineers do this every day - and our AI agents automate most of it.