Define What “the Same Record” Means
When customer and product data is spread across CRM, ERP, commerce, service, warehouse, and analytics systems, each application tends to hold a reasonable but slightly different version. One company may have separate customer numbers for its legal entity, branches, billing accounts, and delivery sites. One commercial offering may have distinct codes for its product family, package size, regional variant, and stock-keeping unit.
The first step is therefore not to build a larger table. It is to define the business entities and their relationships. Decide whether a customer record represents a legal organization, a trading account, a ship-to location, or a person. For products, distinguish the product family, sellable item, inventory unit, and service plan. These objects may be connected, but compressing them into one code creates ambiguity that synchronization cannot solve.
Separate Stable Identity from Business Codes
Each master record should have an immutable internal identifier with no embedded business meaning. Tax numbers, email addresses, and product numbers can be corrected, reassigned, or changed after a reorganization. They are useful matching attributes, but fragile permanent keys. A practical design assigns a global ID in the master-data layer while retaining every source system's local ID and the mapping between them.
Human-readable business codes still have value. The important point is to define their scope, uniqueness, and change policy. An ERP item number may remain the code shown on orders and labels, while the data platform links history through a global product ID. This two-layer approach introduces mapping work, but avoids rewriting years of transactions when an item is renumbered, a company merges, or an application is replaced.
- Global identifier: Immutable and meaning-free, used for system relationships and historical continuity.
- Business code: Readable and operationally useful, with explicit versioning and retirement rules.
- Alternate key: A tax ID, barcode, or supplier number used for search and matching, without assuming permanent uniqueness.
- Mapping record: The source system, local code, global ID, effective period, and mapping status.
Assign Authority Instead of Allowing Mutual Overwrites
Every important field needs an authoritative source. ERP commonly owns payment terms, tax data, and inventory units. CRM is often better placed to own prospects, contacts, and sales segmentation. A product information system may control specifications, media, and multilingual descriptions. Authority can be distributed across systems, but only one owner should make the final decision for a field at a given stage of the business process.
A common failure mode is unrestricted bidirectional synchronization: a change in any application can overwrite every other application. It appears flexible, but produces update loops, stale values returning from downstream systems, and unclear accountability. A field-level ownership matrix is safer. Define who may create, edit, approve, merge, and retire each type of data. When a non-authoritative application needs a correction, it should submit a change request rather than directly replacing the master value.
Choose the synchronization mechanism according to business tolerance for delay. A credit status needed before order acceptance may require a synchronous API lookup. Product descriptions or analytical classifications can usually travel through events or scheduled batches. Real-time integration reduces latency, but increases coupling and the chance that one unavailable system blocks another. Use it where the business decision is truly time-sensitive, not as a default for every field.
Make Matching, Merging, and Exceptions Explicit
During migration, exact name equality is rarely sufficient to identify a customer or product. Start with deterministic rules, such as tax ID plus branch or item number plus revision. Then generate possible matches from normalized names, addresses, phone numbers, barcodes, and technical attributes. Fuzzy matching is useful for reducing the review workload, but uncertain matches should not be merged automatically. An incorrect merge is usually harder to unwind than a temporary duplicate.
A merge must preserve lineage: source records, former identifiers, field-selection decisions, and the user or rule that approved the action. Do not simply delete the losing record. Mark it as redirected to the surviving master so that historical orders, reports, and external references remain traceable. The operating model should also cover company splits, repackaged products, and reversal of an incorrect merge.
- Controlled creation: Limit which systems and roles can create master records, with duplicate checks before acceptance.
- Validation: Apply required-field, format, reference, and cross-field business rules rather than checking only for empty values.
- Review queue: Route low-confidence matches, ownership conflicts, and records missing critical attributes to named data stewards.
- Audit trail: Retain old and new values, source, time, actor, and approval reason.
Operate Quality Through Observability and Phased Delivery
Master-data management is not a one-time cleansing exercise. After launch, monitor duplicate candidates, unmapped local codes, synchronization failures, missing mandatory values, unusual update volumes, and exceptions waiting too long for review. The goal is not a cosmetic zero-error dashboard. Metrics should help the team locate the source of defects and determine whether a rule is unrealistic, users are bypassing a process, or an interface is failing.
Start with one bounded flow, such as creating a customer in CRM and approving it for ERP, or publishing ERP products to commerce and analytics systems. Complete the definitions, ownership rules, mappings, retry behavior, and monitoring before expanding. A large MDM suite is not always the first requirement; a reliable identity service, versioned APIs, event delivery, and disciplined governance can provide a sound foundation. As the number of systems and approval paths grows, an integration team can then evaluate whether a dedicated platform has become justified.