Data Mapping

What Is Data Mapping?

Data mapping is the documented definition of how each field in a source system corresponds to a field in the target archive or application – which source column becomes which target column, what data type conversion is needed, and how any coded values (a status field storing “1” instead of “Approved,” for instance) get translated into something meaningful in the destination. It’s the blueprint that a data transformation process executes against.

Mapping is where most of the domain knowledge in a migration or archiving project actually lives. A source system’s field names are frequently cryptic, abbreviated, or reused for different purposes across different modules of the same application – a field literally named “FLD12” might hold a critical business value that only someone who worked with the original application would recognize. Building an accurate map requires either that institutional knowledge or a thorough reverse-engineering effort against the source system’s documentation, sample data, and behavior.

Incomplete or incorrect mapping is a quiet failure mode: unlike a missing record, which a completeness check will catch, a field mapped to the wrong target column or an unmapped field silently dropped rarely triggers an obvious error. The data lands somewhere, technically, and the archive appears to work – until someone goes looking for a specific piece of information that was actually lost or mislabeled in the mapping step months or years earlier.

Key Points

• The blueprint, not the execution. Mapping defines the correspondence between source and target fields; transformation is the process that actually converts and moves the data according to that definition.
• Requires domain knowledge, not just technical skill. Correctly interpreting cryptic or reused field names in a legacy system’s data model often depends on institutional knowledge of how the original application was actually used.
• Coded values need explicit translation. Status codes, category flags, and other coded fields must be mapped to their meaningful equivalents, not just copied as raw codes that will be meaningless once the source application is gone.
• Failures are quiet, not obvious. An incorrectly mapped or dropped field doesn’t usually cause a visible error – the archive appears to function normally until someone specifically needs the data that was lost in translation.
• Documented as a durable artifact, not a throwaway step. A well-documented mapping specification is retained after the project, since it’s the reference needed to explain or defend how any given piece of archived data relates back to its original source field.

Common Use Cases

🔄 ERP-to-ERP field mapping during a platform switch

Every relevant field in a legacy ERP is mapped to its corresponding field in the new platform or archive, including translating internal status codes and abbreviated field names into their documented business meaning.

🏥 Clinical data mapping for regulatory consistency

Patient record fields from a legacy EHR are mapped to standardized clinical data fields in the archive, ensuring coded values for diagnoses or procedures translate correctly rather than becoming meaningless numeric codes once the source system is gone.

📄 Mapping for cross-system reporting after consolidation

When multiple regional systems are consolidated, each system’s fields are mapped to a common target schema, so consolidated reporting can compare data that originally came from differently structured source systems.

Data Mapping vs. Related Concepts

Mapping is frequently discussed alongside two directly related steps in the same pipeline.

DATA TRANSFORMATION

The execution step that applies the mapping – actually converting data types, translating codes, and restructuring records according to what the map specifies. Mapping is the plan; transformation is the work.

ETL (EXTRACT, TRANSFORM, LOAD)

The full pipeline that mapping informs. Mapping is typically defined between the extract and transform stages, since you need to know what you extracted before you can specify how it should be transformed.

DATA MIGRATION

The broader project of moving data between systems, which relies on accurate mapping as one of its core components. Migration can fail even with successful extraction if the underlying field mapping was wrong.