Data mapping is a source-to-target specification that defines, attribute by attribute, how data from one or more sources lands in a destination with a standardized format. It is technique 3.6 of the IIBA Guide to Business Data Analytics [2]. On the CBDA exam it belongs to Source Data, a domain worth 15% of 75 questions [1]. Data mapping is not one of the 50 BABOK Guide v3 techniques, so it is new even for CBAP holders [4].
Last verified: November 2026 (exam facts on the IIBA CBDA page).
What data mapping is, by the guide
Data mapping establishes a relationship between a source and a target repository so data can move even when formats differ [2]. The guide's purpose is short: consolidate data from one or more sources to a destination "to create a meaningful set of data with a standardized format". A general definition says the same in other words: data mapping is "the process of defining correspondences and transformation rules between" data in two models [5].
The guide names two uses [2]:
| Use | What happens | Condition |
|---|---|---|
| Data migration | Source data moves to a new data repository | Target attributes must hold the source data |
| Data integration | Source data merges with an existing repository | At a minimum, the data models of source and target are the same, even if the schemas differ; common attributes and relationships (one-to-one, zero-to-many) are analyzed |
Three rules from the description are worth keeping in mind [2]:
- Data mapping happens at the attribute level, not the table level.
- The target data size can equal the source size or be larger for future growth, but it should never be smaller, because that may lose data.
- New custom attributes can be calculated or derived, for example a tax amount or a product name based on a product code.
Complexity depends on how different the source and target are, and on any existing data hierarchy.
The three elements: source, target, specification
The technique has three elements, and the third one is the actual deliverable [2].
1. Source. The repository with the original data. The analyst looks at its format (delimited file, spreadsheet, database entity), the attributes of interest or potential interest, and their data types and sizes.
2. Target. The repository receiving the data. The analyst looks at its format, new attributes to create, source attributes that need a transformation rule, and new custom fields. Transformation rules come from a business rule or a business requirement. The guide's example: a source "TransactionDatetime" in mm/dd/yyyy hh:mm:tt becomes a target TransactionDate with the date only, for easy querying.
3. Data mapping specification. Usually a spreadsheet that maps target attributes to source attributes with the transformation logic [2]. The guide's basic map has these columns:
| Target entity | Target attribute | Data type | Source attribute(s) | Direct map? | Logic |
|---|
Its sample rows map an employee table: the ID maps directly, the name is a concatenation of first and last name, and the start date keeps only the date component in YYYY-MM-DD format. Note that the guide still marks the start-date row as a direct map (Y), even with that date-only logic.
My take: the "Logic" column is the most useful one. Every rule in it is a business decision someone has to confirm, and those rows are where migrations break. In my example below I mark date-only rows as "N" to make the rule visible; the guide's sample shows both conventions can exist.
Where data mapping appears in the CBDA domains
Data mapping lives in Source Data (Domain 2) [3], with an echo in Analyze Data through data flow diagrams (3.5). Unlike some techniques, section 3.6 has no domain-by-domain subsections. The links come from other parts of the guide:
| Place in the guide | What it says about data mapping |
|---|---|
| 2.2.4 Validate Data | Analysts use data mapping and business rules analysis when validating data; data mapping creates "a source-to-target data map" between the data sources and the target system |
| 2.2.5 Select Techniques for Source Data | Data mapping builds traceability between data elements and sources, with data owner, availability, frequency, constraints, assumptions, transformations and extraction or collection methods, "to build a reference for data collection"; BABOK reference N/A |
| 3.4 Data Dictionary | When sourcing data, the dictionary helps perform data mapping, migrations and transformations |
| 3.5 Data Flow Diagrams | In Analyze Data, data issues can come from migration, transformation or "incorrect data mapping" |
| 3.13 Interface Analysis | Findings about how interface data is saved are documented through data mapping for ELT activities and help business reporting stakeholders |
The 2.2.5 row is the one I would reread before the exam. In Source Data, the data map is wider than field-to-field rules: it also records who owns the data, how often it arrives and which constraints and assumptions apply. More on the domain in the CBDA Source Data domain guide.
A worked example: mapping an online shop into a new order platform
This is a made-up example from e-commerce, my own field. It is not from the guide. A retailer migrates customers and orders from a legacy shop database into a new order platform.
Step 1. Name the use. The new platform is empty, so this is data migration. If we were merging into an existing CRM, it would be integration, and both data models would have to match first.
Step 2. Analyze the source. Two database entities, Customer and Order. Attributes of interest and their types: Customer.ID varchar(10), FirstName and LastName varchar(40) each, Email varchar(80), Order.CustomerID varchar(10), Order.CreatedAt datetime, Order.NetAmount decimal(10,2), Order.TaxRate decimal(4,3).
Step 3. Analyze the target. The platform needs a full name field, a date-only order date and a stored tax amount. These are new attributes and transformation rules.
Step 4. Write the specification.
| Target entity | Target attribute | Data type | Source attribute(s) | Direct map? | Logic |
|---|---|---|---|---|---|
| T_Customer | Cust_ID | varchar(12) | Customer.ID | Y | |
| T_Customer | Full_Name | varchar(81) | Customer.FirstName, Customer.LastName | N | Concatenate with one space |
| T_Customer | varchar(50) | Customer.Email | Y | ||
| T_Order | Order_Date | date | Order.CreatedAt | N | Only the date component, YYYY-MM-DD |
| T_Order | Tax_Amount | decimal(10,2) | Order.NetAmount, Order.TaxRate | N | NetAmount × TaxRate, rounded to 2 decimals |
| T_Order | Cust_ID | varchar(12) | Order.CustomerID | Y | One customer to zero-to-many orders |
Step 5. Check sizes. Both Cust_ID targets are varchar(12), larger than the varchar(10) sources, which is fine and leaves room to grow. Full_Name fits: 40 + 1 + 40 = 81 characters. Email breaks the guide's rule: the target is varchar(50) while the source is varchar(80), so longer addresses would be cut. The fix is varchar(80) or larger.
Step 6. Check business rules. Tax_Amount is a custom calculated attribute, so finance confirms the rounding rule. Order_Date drops the time, so someone confirms no report needs the hour.
Step 7. Use the map to validate. After a test load, the map tells you what to compare per attribute. This is the traceability strength in practice: when a number looks wrong, you can trace it back to its source attribute and rule [2].
Step 8. Keep it alive. If the legacy shop adds a field next month, the map changes the same day. The guide lists this as a limitation, and practitioners agree, as the next sections show.
Strengths and limitations
The guide lists five strengths and three limitations [2]:
| Strengths | Limitations |
|---|---|
| A meticulous approach to smooth migration and integration between platforms | Needs careful attention to detail to avoid data loss, redundancies or other errors |
| Data traceability, useful when resolving data issues | Can be time-consuming, especially when done manually |
| Easy to learn and use | Needs updating as soon as the source or target changes |
| A standardized, business-focused repository for consistent access and reporting | |
| Helps identify data quality issues in the source or target |
What practitioners and data say about data mapping
Practitioners agree with the guide's limitations more than with its strengths, and the data explains why.
Migrations often run late. A 2007 study of more than 700 large companies with migration projects of $1 million or more found 64% were not delivered on time, and 37% had serious budget overruns of 30% on average; only 16% were unqualified successes [6]. A widely repeated figure, attributed to Gartner in a vendor white paper, says 83% of data migration projects fail or exceed budgets and schedules [7]. I could not find the original report, so I treat that number with care.
The map is a contract. A data analyst with eight years of enterprise data migration writes one row per source field, with sample values and who made each decision. His rule: "Nothing moves until the map is signed off" [8]. The same author warns against sending a huge spreadsheet for one approval and signs the map off in sections.
Field lengths and categories break first. A BA trainer describes a field-by-field specification where the problems were length limits and structure, because the source data can have "multiple categories while the search engine has a single text field" [9]. This is the guide's size rule and custom-attribute logic in real life.
Test the map, not only the load. A consultant writing about migration lessons tests character limits, date formats such as dd/mm/yy to mm/dd/yyyy, record counts and duplicates. He calls the map "a living document that will likely require updates over time" [10].
Keeping it current is the hard part. On a SQL forum, a long-time member says that once mapping documentation is done, "keeping it up to date with changes is an additional challenge"; the site's editor suggests that code changes in a pull request should include a documentation update [11].
Experts disagree on how to own and keep the map
Everyone agrees a mapping must exist; they disagree on who owns it and where it lives.
1. The spreadsheet is enough. The guide says the specification is often a spreadsheet and that the technique is easy to learn [2]. A data quality vendor's director agrees only partly: "Spreadsheets may be sufficient for small, short-lived projects" [13].
2. Mappings should live as data or code. One author on Medium argues: "Treat mappings as data" [14]. The forum editor in [11] ties the docs to code reviews. In this view a spreadsheet goes stale by design.
3. The analyst documents, the architect maps. An unsigned expert answer on a tech Q&A site says that "in most scenarios, the Business Analyst would document the requirements", while the mapping itself would better sit with a data architect [12]. The BA trainer in [9] takes the opposite side and lets the analyst write the specification.
4. Map up front or iterate. The migration analyst in [8] signs everything off before data moves. A data migration specialist argues the opposite rhythm: "Swap tail end panic for front-end discovery, prototyping and iterative release" [15].
5. Let AI draft the map. A lead data engineer describes large language models drafting mappings, but warns they "can sometimes hallucinate or generate incorrect mappings" [16]. The guide's limitation about careful attention to detail applies here even more.
My take: for the exam, follow the guide, which frames source and target analysis as the analyst's work. At work, the ownership question is real, and I think the analyst's best contribution is the "Logic" column, the business rules, whoever types the rest.
Common misconceptions
- "Data mapping is table-to-table." No. The guide says it happens at the attribute level (3.6).
- "Integration only needs matching schemas." The reverse: data models must match, schemas may differ (3.6).
- "A smaller target field is fine if the data is clean today." The target size should never be smaller than the source (3.6).
- "Data mapping is a BABOK technique." It is not among BABOK v3 techniques; the 2.2.5 table gives "N/A" as its BABOK reference.
- "Once signed, the map is done." The guide lists updating on every source or target change as a limitation (3.6, Usage Considerations).
Data mapping vs similar CBDA techniques
Four nearby techniques also deal with data structure and flow; the difference is what they produce.
| Technique | What it delivers | When the exam wants it |
|---|---|---|
| Data Mapping (3.6) | Attribute-level source-to-target rules | Migrate or integrate data into a standardized target |
| Data Dictionary (3.4) | Standard definitions of data elements | Common interpretation of data elements across sources |
| Data Flow Diagrams (3.5) | Where data comes from, which activities process it, where it goes | Trace the movement of data and find where discrepancies start |
| ETL (3.10) | The process that makes data available in a single standardized target | Extract, transform and load the data |
| Interface Analysis (3.13) | What information is exchanged between components and why | Understand how interface data is captured and stored |
A short way to remember it: the dictionary defines, the DFD shows movement, ETL moves, and the map specifies what goes where. For the BABOK side of these, see the data dictionary technique, data flow diagrams and data modelling.
Check yourself: CBDA practice questions
Three short questions, checked against section 3.6 of the guide.
1. A source attribute is varchar(80). What target size does the guide allow?
A. varchar(50), if most values are short B. varchar(80) or larger C. Any size, if a transformation rule exists D. Exactly varchar(80) only
Answer: B. The target can equal the source or be larger for future expansion, but never smaller (3.6).
2. A team merges customer data from a web shop into the existing CRM. What must be true at a minimum?
A. The schemas are identical B. The data models of source and target are the same C. The source is a delimited file D. All attributes map directly
Answer: B. For integration, data models must match even if schemas differ (3.6).
3. Which is a limitation of data mapping in the guide?
A. Hard to learn B. No traceability C. Needs updating when source or target changes D. Cannot find data quality issues
Answer: C. The other three contradict the listed strengths (3.6, Usage Considerations).
More drills: CBDA Source Data questions, then a timed mock on the CBDA exam simulator.
Conclusion: the gap between the guide and real data mapping
The guide describes the specification well; practice adds ownership, sign-off and upkeep.
| Area | Guide | Reality | Delta |
|---|---|---|---|
| Format | Often a spreadsheet | Fine for small work [13]; at scale, mappings as data or code [14] | Reduced to small projects |
| Ownership | Analysts analyze source and target; the owner of the spec is not named | Split between analyst and architect [12]; analyst-owned in [9] | Added by employers |
| Sign-off | Not described | Sectioned sign-off before data moves [8] | Added by practitioners |
| Upkeep | Update on every change (limitation) | The hardest part in practice [10, 11] | No gap |
| Tools | Manual work is time-consuming | AI drafts with human checks [16] | Added by practitioners |
So for the exam, learn the guide's rules on attributes, sizes, migration and integration. At work, I would add one thing the guide only hints at: a named owner who keeps the map current.
Related topics
- CBDA data quality questions: validation, the step where the guide uses data mapping.
FAQ
What is data mapping in the CBDA guide?
It is technique 3.6 of the Guide to Business Data Analytics: an attribute-level source-to-target map that consolidates data from one or more sources into a destination with a standardized format. It supports data migration and data integration.
Which CBDA domain uses data mapping?
Source Data (Domain 2, 15% of the exam). The guide uses it when validating data and lists it in the Source Data techniques table. It also appears in Analyze Data as a possible cause of data issues.
What is the difference between data migration and data integration?
In migration, source data moves to a new repository. In integration, source data merges with an existing repository, which requires matching data models and an analysis of common attributes and their relationships.
What goes into a data mapping specification?
Target entity, target attribute and data type, the source attribute or attributes, whether it is a direct map, and the transformation logic. The guide's example is a simple spreadsheet.
Is data mapping part of BABOK Guide v3?
No. BABOK v3 has data dictionary, data flow diagrams, data mining and data modelling, but not data mapping. The CBDA guide lists it with "N/A" as the BABOK reference.
Sources
- IIBA: Certification in Business Data Analytics (CBDA)
- IIBA: Guide to Business Data Analytics, 3.6 Data Mapping
- IIBA: Guide to Business Data Analytics, 2.2 Source Data
- IIBA: BABOK Guide v3, techniques in chapter 10
- Wikipedia: Data mapping
- CIOL: Informatica research reveals keys to migration success (2007)
- Oracle: Data migration white paper (PDF)
- DEV Community: Stage 3, map the fields
- Bridging the Gap: Data mapping (2023)
- Spyglass MTG: Data migration lessons (2022)
- SQLServerCentral forum: Source to target mapping lineage (2025)
- TechTarget: Business analyst vs data architect, who should do the source-to-target mapping?
- Data Ladder: Source-to-target mapping best practices (2026)
- Medium: Roadmaps, not pipelines: business-friendly mapping from sources to targets (2025)
- SAS blog: How to re-balance a data migration project plan (2014)
- DATAVERSITY: Performing data mapping through AI and LLMs (2026)