What is an example of data mapping?

A simple one: your ecommerce platform stores a customer as full_name in a single field, and your CRM stores First name and Last name separately. The map says full_name splits on the first space, the first part goes to First name, and the remainder goes to Last name. A harder one: the ecommerce platform stores country as a two-letter code (GB) and the CRM expects the full country name (United Kingdom), so the map needs a lookup table rather than a direct copy. The first example is a transformation, the second is a lookup, and both are ordinary requirements that a field-to-field mapping screen cannot express on its own.

What are the types of data mapping?

Five show up repeatedly. Direct mapping copies a value from one field to another unchanged. Transformation mapping reshapes the value in transit, such as splitting a name, reformatting a date, or converting currency. Conditional mapping applies a rule, for example writing a value only when the deal stage is Closed Won. Lookup mapping resolves a code to a value using a reference table, such as a country code to a country name. Aggregation mapping combines several source records into one target value, such as summing invoice lines into an order total. Most connector interfaces only handle the first, and offer a limited version of the second.

What is the difference between data mapping and data transformation?

Mapping is the plan, transformation is the work. A data map is the specification that says source field A corresponds to target field B under these rules. Transformation is what actually happens to the value while it moves: the split, the reformat, the unit conversion, the lookup. In practice they are discussed together because a map that only pairs fields is useless the moment the two systems disagree about format, which they almost always do. A useful shorthand is that the map is the design document and the transformation is the code that honors it.

What is data mapping in ETL?

In an ETL pipeline, data mapping is what happens between the extract and the load. Extract pulls raw records out of the source, transform reshapes them into the target's structure using the map, and load writes them into the warehouse or destination system. The map is the specification the transform step executes. In ELT, the newer variant, raw data is loaded first and mapped afterward inside the destination, which trades up-front rigor for flexibility. Either way the mapping work does not disappear, it just moves to a different point in the pipeline.

What is field mapping in HubSpot?

Field mapping is how HubSpot's data sync decides which HubSpot property corresponds to which field in a connected app, in which direction, and how conflicts resolve. Every data sync app ships with a set of default mappings covering the standard fields. Creating your own custom mappings requires at least a Data Hub Starter subscription, which is the single most common surprise when a team installs a free connector and then discovers the mapping they actually need sits behind a paid tier. The HubSpot Salesforce connector goes further and gives each mapping one of four sync rules, with a ceiling of 500 field mappings per object.

Why do data mappings break?

Rarely because someone mapped the wrong field. They break because the systems on either end keep changing underneath a map that was correct when it was written. Someone adds an option to a dropdown and the sync does not pick it up, because option lists are typically read once at setup. A field type changes from text to number. A record acquires a second email address, and multi-value fields like emails, phones, and addresses cannot be mapped to custom fields at all. Or two systems both edit the same field between syncs and the conflict rule silently discards the version you wanted. Almost every mapping failure is drift, not error.

Is data mapping the same as GDPR data mapping?

No, though the term is used for both. In integration work, a data map pairs fields between two systems so data can move correctly. In privacy and compliance work, data mapping means documenting what personal data your organization holds, where it lives, why you process it, and who it is shared with, which is the record of processing activities that regulations like GDPR require. The two share a name and a spreadsheet aesthetic and almost nothing else. This guide covers the integration meaning.

Data Mapping: The Complete Guide (2026)

Q: What is data mapping?

Data mapping is the process of defining how a field in one system corresponds to a field in another, so data can move between them without losing its meaning. A source field like first_name is matched to a target field like First Name, along with a rule for what happens to the value on the way across and which system wins if both have changed. It is the design step that comes before any integration, migration, or warehouse load actually runs. Every connector you have ever configured is executing a data map, whether or not it showed you one.

Every integration you have ever configured is really a data map wearing a nicer interface. Underneath the toggles and the dropdowns sits a list of pairs: this field over here corresponds to that field over there, and here is what happens to the value on the way across.

That list is the actual product. When an integration works, it is because the map was right. When reporting disagrees with the ledger, when a contact turns up twice, when a deal closes and nothing downstream notices, the map is almost always where it went wrong. This guide covers what data mapping is, the five types you will actually encounter, how field mapping works inside a real connector, why maps break in production, and the point at which a mapping screen stops being the right tool for the job.

One clarification first, because the term does double duty. In privacy and compliance work, data mapping means documenting what personal data your organization holds and why, the record of processing activities that regulations like GDPR require. This guide is about the other meaning: mapping fields between systems so data can move. Same phrase, unrelated discipline.

In this article

10.

11.

Key takeaways

Data mapping defines how a field in one system corresponds to a field in another, plus what happens to the value in transit and which system wins on conflict. It is the actual specification an integration executes.
Five types cover most real requirements: direct, transformation, conditional, lookup, and aggregation. Connector interfaces handle the first well and the rest badly or not at all.
Mappings fail from drift rather than error. Dropdown options added after setup, changed field types, multi-value fields, and conflict rules that silently pick the wrong version account for most production breakage.
The moment a mapping needs a condition, a lookup, or a one-to-many relationship, it has stopped being a mapping and become logic, and that is the line where a mapping screen stops being the right tool.

What Is Data Mapping?

Data mapping is the process of defining how each field in a source system corresponds to a field in a target system, so information can move between them without losing its meaning.

A complete map answers three questions for every pair of fields, and most people only think about the first:

Which field goes where. The source field billing_email corresponds to the target property Email.
What happens to the value in transit. Does it copy across unchanged, get reformatted, get looked up in a reference table, or get combined with something else?
Who wins when both sides changed. If the CRM and the billing system both hold an address and both were edited since the last sync, which one is authoritative?

Skip the second question and your sync fails on the first date field it meets. Skip the third and it does something worse: it succeeds, quietly, using the wrong value.

Mapping is the design step underneath every kind of data movement. It sits at the center of integrations, one-time migrations, warehouse loads, and any ETL pipeline, because as Informatica puts it, effective integration is only possible once the source and target structures can be mapped to each other in the first place.

Why Data Mapping Matters

Two systems almost never agree about how to describe the same customer, and the disagreements are more structural than they look.

The same thing has different names
One system calls it a Company, another an Account, a third an Organization. One stores first_name, another stores given_name, a third stores a single name field with a space in the middle. None of them are wrong. They just cannot be joined without someone stating the correspondence.
The same value has different shapes
Country as GB or United Kingdom. Dates as 2026-07-31 or 31/07/2026. Currency as a number, or a number with a symbol, or minor units. A copy operation between two incompatible shapes does not produce an error, it produces garbage that looks like data.
The same record has different granularity
An order in the store is one record. In the ledger it is an invoice with line items. In the CRM it is a deal with an amount. Mapping between different granularities is the requirement that most quietly exceeds what a mapping interface can express.
The same field has two owners
When both systems can edit a value, the map has to decide precedence, and that decision is business policy rather than a technical detail. Getting it wrong is how a corrected billing address gets overwritten by the stale one every night at 2am.

The reason this matters more than it used to is that revenue data now lives in six systems instead of one. A typical stack has a CRM, a marketing platform, a billing system, a support tool, an ecommerce or product database, and a warehouse, each holding a partial copy of the same customer. The connections between them are all maps, and the quality of your reporting is capped by the worst one.

The Five Types of Data Mapping

Mapping requirements sort into five patterns. The distinction matters because tooling that handles the first two comfortably tends to fall apart at the third.

Type	What it does	Example	Handled by a connector UI?
Direct	Copies a value unchanged	`email` to `Email`	Yes
Transformation	Reshapes the value in transit	Split `full_name` into first and last	Partially
Conditional	Applies a rule before writing	Set Lifecycle Stage only when the deal is Closed Won	Rarely
Lookup	Resolves a value via a reference table	`GB` to `United Kingdom`	Rarely
Aggregation	Combines several records into one value	Sum invoice lines into an order total	No

Direct mapping is the easy 80 percent, and it is what every connector screen is designed around. Transformation is where the friction starts, because most interfaces offer a fixed menu of transformations rather than an arbitrary one, and your requirement is either on the menu or it is not.

The last three are the interesting ones, and they share a property: they are not really mappings at all. A conditional mapping contains the word "unless." A lookup mapping needs a table that lives somewhere. An aggregation mapping needs to know about records other than the one in front of it. All three are logic, and a mapping screen is a data structure, not a programming language.

The moment a requirement contains the word "unless," it has stopped being a mapping and become a rule. Mapping interfaces express correspondence. They do not express reasoning.

Data Mapping vs Transformation vs Migration

Three terms that get used interchangeably and should not be.

Data mapping is the specification. It says field A corresponds to field B under these conditions. It is a document, or a screen, or a config file. Nothing has happened yet.

Data transformation is the execution. It is the code that actually splits the name, converts the currency, or reformats the date while the value is in flight. The map is the plan, the transformation is the work.

Data migration is a one-time move of records from an old system to a new one, and mapping is its first and most important phase. The difference from integration is duration: a migration runs once and then the source is retired, while an integration keeps running forever and therefore has to survive both systems changing underneath it.

That last distinction explains why migration maps and integration maps get built so differently. A migration map only has to be right once, against a known snapshot of the data. An integration map has to stay right for years, against two systems that will both add fields, rename options, and change types without telling you. For a fuller treatment of where the movement itself happens, the guide to iPaaS covers the platform layer and the Operations Hub guide covers HubSpot's own sync engine.

How Data Mapping Works, Step by Step

The process is the same whether you are configuring a connector or scoping a custom build. Skipping steps two and three is the most common reason a project that looked simple in the kickoff turns into a quarter of rework.

1
Inventory both schemas
List every field in the source and the target that carries meaning, along with its type, whether it is required, and its allowed values. Do this against the live systems, not against documentation, because the two diverge faster than anyone expects.
2
Pair the fields and name the type
Match each source field to its target and label the pattern: direct, transformation, conditional, lookup, or aggregation. This is the step that surfaces cost. Every pair that is not direct is work, and counting them up front is how you avoid discovering the number halfway through.
3
Decide direction and precedence per pair
For each mapping, choose one-way in either direction or two-way, and for anything two-way decide which system is authoritative when both have changed. Do this field by field rather than object by object. Direction is rarely uniform across a record.
4
Define the matching key
Decide how the two systems recognize the same record, usually email, an external ID, or a domain. This is the single highest-consequence decision in the whole map, because a weak key does not fail loudly, it quietly creates duplicates until someone notices the reporting is double counting.
5
Test against real records, especially ugly ones
Run the map over a sample that includes the records you would rather ignore: the contact with no last name, the customer with three addresses, the deal in a currency nobody remembers adding. Clean test data proves nothing, because clean data was never the problem.
6
Document it and put it somewhere findable
A map that exists only inside a connector's settings screen is undocumented. Write down what each non-obvious pair does and why, because the person debugging it in eighteen months will not be you, and the reasoning behind a precedence rule is never recoverable from the config.

Data Mapping in Practice: How HubSpot Field Mappings Work

Abstract mapping theory becomes concrete the moment you open a real connector, so it is worth walking through one. HubSpot's data sync is a good example because its constraints are documented and typical of the category.

Every data sync app ships with default mappings covering the standard fields, and those are visible on the app's marketplace listing before you install anything. Creating your own mappings on top of them requires at least a Data Hub Starter subscription. That single fact is the most common surprise in HubSpot integration work: teams install a free connector, discover that the field they actually needed is not in the default set, and find that adding it means a paid tier they had not budgeted.

Direction is decided per mapping rather than per object, and the available options depend on the field types on both ends. Matching types, text to text, number to number, date picker to date picker, can usually sync two-way. Mismatched types get downgraded to one-way. Several third-party field types, including number, date, and checkbox, can only map into a HubSpot text property, which means the value arrives but arrives as a string and stops being usable for filtering or math. In the other direction, HubSpot's multiple checkbox, calculation, and score properties leave as text only.

The HubSpot Salesforce connector adds explicit conflict rules, and they are the clearest illustration of the third mapping question in a real product:

Sync rule	What happens on conflict
Prefer Salesforce unless blank	HubSpot only writes when Salesforce is empty
Always use Salesforce	HubSpot never writes to Salesforce at all
Two-way	The most recent change wins, in either direction
Don't sync	The pair is defined but dormant

Two details in that connector catch teams out regularly. Existing values do not retroactively sync when you create a new mapping, so adding a mapping populates the field going forward and leaves every historical record blank until someone runs an import. And there is a hard ceiling of 500 field mappings per object.

None of this is criticism of HubSpot specifically. It is what a general-purpose mapping engine looks like when it has to work for every customer on earth, and the same shape of constraint appears in the Salesforce connector, the Xero app, and every other managed sync in the category.

Where Data Mappings Break

Mappings rarely fail on day one, because day one is when someone is looking at them. They fail in month seven. These are the failure modes that show up most, and none of them announce themselves.

The drift that breaks a working map

Dropdown options added after setup. Option lists are typically read once when the sync is created. Add a new deal stage, lead source, or product category afterwards and the mapping does not learn about it. HubSpot's own documentation is explicit that new options require saving and starting the sync again, which is not something anyone remembers to do at the moment they add a picklist value.
Field types changing underneath the map. Someone converts a text field to a number, or a single-select to a multi-select, to solve a reporting problem. The mapping that depended on the old type either fails or starts writing values that are technically valid and semantically wrong.
Multi-value fields that cannot be mapped at all. Emails, phones, and addresses are fields that can hold several labelled values, and they cannot be mapped to custom fields. Any requirement involving a customer's second email or their shipping address as distinct from their billing address hits this wall immediately.
Name splitting on the first space. A full name field splits into first and last on the first space it finds. That is correct for most records and wrong for compound surnames, multi-part given names, and most naming conventions outside the anglophone default, which produces a permanent low-grade data quality problem nobody owns.
Owner and user fields that match on a string. Assigning ownership across systems usually depends on an email or a name matching exactly in both. A rep changes their surname, or exists under a different address in one tool, and records silently stop being assigned.
Conflict rules that resolve the wrong way. Two systems both edit a field between syncs, the precedence rule picks one, and the other version is gone. This is the failure mode that generates no error and no log line, which is precisely why it is usually found by a customer rather than by monitoring.
A matching key that was never strong enough. Email as the key seems fine until a contact uses a personal address on one system and a work address on the other, or two people share an accounts@ inbox. The duplicates accumulate slowly and then all at once, and by the time they are visible in reporting they are expensive to unpick.

The pattern is that mapping is treated as a setup task when it is actually a maintained artifact. Both systems on either end of it are living products with their own release schedules, and a map with no owner degrades on a timescale of months.

Manual, Native, or Custom: Choosing Your Mapping Layer

Where the map lives is a real decision with real tradeoffs, and the right answer changes as the requirements grow.

PickA native connector's mapping UIWhenStandard objects, compatible field types, mostly direct pairs

Fast, free or cheap, and maintained by the vendor. This covers most of what most teams need, and reaching past it before you have to is a waste. Budget for the paid tier that custom mappings usually require, and accept that you get the transformations on the menu rather than the ones you want.

PickAn iPaaS mapping layerWhenOne or two pairs the connector cannot express

Zapier, Make, or Workato can hold a transformation the native app refuses, and they are genuinely good for proving a requirement is real before committing engineering to it. Costs scale per task and the mapping logic ends up spread across steps that nobody documents, so treat it as a prototype rather than a foundation.

Best fitPickA custom integrationWhenConditions, lookups, one-to-many, or data leadership reports on

When the map needs to reason rather than correspond, it belongs in code that can be read, tested, versioned, and monitored. Lookups live in a real table, conditions are explicit, one order becomes several line items correctly, and a failed sync raises an alert instead of a shrug.

Most mature setups use all three deliberately: the native connector carries the standard objects, nothing important depends on an iPaaS step, and a custom layer handles the specific pairs that encode how the business actually works. That layering is the same conclusion the complete guide to HubSpot integrations reaches from the other direction.

Data Mapping Best Practices

What separates a map that lasts from one that rots

Map fewer fields than you can. The instinct is to sync everything because it is available. Every mapped pair is a thing that can drift, and a field nobody reads is pure liability. Map what a person or a report actually uses.
Pick one system of record per field, and write it down. Not per object, per field. Billing address belongs to the ledger, lifecycle stage belongs to the CRM, and stating that explicitly converts most future conflict-rule arguments into a lookup.
Make the matching key stronger than an email. An external ID stored on both sides survives everything an email address does not: role changes, shared inboxes, personal addresses, and people who leave.
Test with the records you would rather ignore. The missing last name, the third address, the refunded order, the deal in an unfamiliar currency. Those records are where the map either holds or does not, and clean sample data hides all of them.
Turn objects on one at a time. Enabling every object at once makes a single bad mapping almost impossible to trace, because the symptoms arrive together. Sequence them and each problem stays attributable.
Monitor the map, not just the connection. A sync that is running is not a sync that is correct. Watch for records that stop matching, fields that suddenly write blanks, and volume that changes without a business reason.

The unifying idea is that a data map is documentation of how your business defines its own records. Treat it like configuration and it decays. Treat it like a specification with an owner and it keeps working, which is the whole reason RevOps teams end up spending as much time on this as they do, as the guide to RevOps covers in more depth.

Mapping requirement your connector cannot express?

Conditions, lookups, one-to-many relationships, and multi-value fields are where mapping screens run out, and they are usually the pairs that matter most. StackTie builds custom HubSpot integrations for a fixed fee and maintains them on a flat monthly retainer, alongside the native connector you already have. Live in 14 days or it's free. Book a free audit and we'll map exactly which pairs need real logic.

Get a free audit

The Bottom Line

Data mapping is the specification that says how a field in one system corresponds to a field in another, what happens to the value in transit, and which system wins when both have changed. It is the real content of every integration, every migration, and every warehouse load, and it is the thing that is actually wrong on the days your systems disagree.

Five patterns cover the requirements: direct, transformation, conditional, lookup, and aggregation. Connector interfaces are built for the first and offer a fixed menu for the second. The last three are logic rather than correspondence, and no amount of configuration turns a mapping screen into a place where reasoning can live.

The practical takeaway is to treat the map as a maintained artifact rather than a setup task. Map fewer fields, name a system of record for each one, use a matching key stronger than an email, test against your ugliest records, and monitor the map rather than the connection. When a pair needs a condition or a lookup or has to turn one record into several, that pair has outgrown the screen, and building that one piece properly is usually cheaper than the reporting discrepancy it would otherwise produce every month.

Data Mapping: What It Is and How It Works