---
name: data-migration-field-mapping
description: Maps source-system fields to a target data model for migration, documenting transformations, requiredness, value translations, identifiers, validation rules, and unresolved collisions. Use for CRM migrations, ERP imports, warehouse loads, application replacement, and controlled spreadsheet-to-system field mapping.
license: Apache-2.0
metadata:
  adlass.categories: "data-tables/migration"
  adlass.industries: ""
  adlass.tags: "data-migration,field-mapping,transformation,validation,etl,cutover"
  adlass.adaptation: "mapping"
  adlass.source: "original"
  adlass.version: "1"
---

# Data migration field mapping

## Purpose

Produce a migration mapping that an implementation team can execute and audit. Every source column is assigned to a target field or an explicit disposition, with transformations and validation checks that protect identifiers, dates, relationships, enumerations, and sensitive values.

## Scope

Cover source and target schemas, field descriptions, data types, nullability, primary and foreign keys, code translations, concatenations, splits, date and unit conversion, deduplication keys, default rules, masking, rejection criteria, and reconciliation totals. **Excluded:** running the migration, changing source data, approving mappings, or inventing target fields that are not in the target model.

## Data basis

- Source schema or tables with table name, column name, type, null rate, distinct examples, and row count.
- Target schema or import template with field name, type, required flag, allowed values, relationship, and length limit.
- Data dictionary, code lists, privacy classification, business rules, and legacy-to-new identifier crosswalks.
- Optional `migration_scope` input naming entities, release, or cutover boundary.

## Result

Deliver a field-mapping sheet with source table/column, target entity/field, mapping type, expression, source and target types, requiredness, allowed values, sensitivity, validation test, owner, and disposition. Add an exceptions sheet for unmapped, ambiguous, duplicate, rejected, or lossy cases and a short migration-readiness memo.

## Quality criteria

- Every target required field has one documented source or an approved default marked as unresolved.
- Every source column has a target, archive, ignore, or reject disposition with a reason.
- Key mappings preserve uniqueness and relationship direction; no silent many-to-one collapse is allowed.
- Transformations specify timezone, decimal, encoding, truncation, and null behavior where relevant.
- Row counts, key counts, and rejected-record totals have explicit reconciliation formulas.

## Instructions

Use the target schema as the destination authority and preserve exact source names beside normalized names. Prefer deterministic expressions over prose. Never convert unknown to zero, invent a code-list value, truncate a key, or merge people or accounts without a stated match rule. Mark a mapping “blocked” when requiredness, type, relationship, or security treatment cannot be proven from the corpus. Separate technical conversion from business ownership of the resulting value.

## Adapt before use

- Provide source and target schemas, data dictionaries, code lists, and identifier crosswalks.
- Define null, duplicate, truncation, timezone, encoding, masking, and rejection policies.
- Map migration owners and specify reconciliation tolerances, release scope, and target import format.