This program went live. The customer, product, and supplier domains are all in production on Reltio, the golden records feed an ERP, a CRM, an e-commerce platform, and a lakehouse, and the steward team closes its queue most weeks. By the measures that appear in a steering-committee deck, it worked. That is exactly why it is worth writing about honestly, because the things that went wrong on a successful program are the things that will go wrong on yours, and nobody puts them in the deck.
The client is a North American industrial distributor with roughly forty source systems, three of them ERPs inherited through acquisitions, and a sales organization that had spent a decade arguing about which of four customer hierarchies was the real one. The details below are anonymized and a few have been composited with a second engagement of similar shape so that no single client is identifiable. The mistakes are real. Most of them were ours.
1. We sequenced the domains by who was loudest, not by what depended on what
Customer went first because the CRO sponsored the program and the CRM migration was on a fixed date. Product went second because the e-commerce team had budget. Supplier went last because procurement had not yet decided whether it wanted to be involved. That order felt pragmatic and it cost us close to four months, because the customer domain's most valuable relationships, the ones that told you which accounts bought which products through which channel, needed a stable product hierarchy that did not exist until month eleven. We modeled those relationships against a placeholder product reference, loaded them, and then remodeled and reloaded when product arrived. Twice.
What we would do now is spend the first six weeks drawing the dependency graph between domains before promising anyone a go-live date, and then sequence by dependency with the sponsor's priority as a tiebreaker rather than the driver. On this program that would have meant a thin product domain first, containing only the hierarchy and the identifiers that customer relationships needed, then customer, then the rest of product, then supplier. Reltio's multidomain model makes that kind of thin-first, deepen-later approach entirely practical. We simply did not use it because the sequencing conversation was political before it was technical.
2. We let the data model grow before the match rules were stable
Reltio makes it easy to add attributes. That is a feature, and in month three it was a trap. Every workshop produced a dozen more attributes the business could not live without, and because adding them was cheap, we added them. By month five the customer entity had over two hundred attributes, a third of them populated by exactly one source system, and the match rules had to be re-baselined every time a new attribute changed the shape of what a duplicate looked like. Match quality regressed three times in a row, each regression traced to model churn rather than to a rule change.
The discipline we now impose is a hard freeze on the match-relevant attribute set, the eight to fifteen fields that actually participate in identity resolution, from the moment rule tuning begins. Everything else can keep growing. Attributes that are not part of the match key are cheap to add later and expensive to argue about early. We also require that any attribute proposed for the model has at least two sources or a documented consumer before it goes in. Roughly a third of what we built on this program has never been read by anything.
3. We treated match tuning as a phase instead of a practice
The plan had a six-week block labeled Match and Merge Tuning. It sat between data load and UAT, it had a start date and an end date, and when the end date arrived we declared match tuning complete because the plan said so. Precision on a sampled set was acceptable. Recall was not measured at all, because measuring recall means finding the duplicates the rules missed, and nobody had built the labeled set that makes that possible. Six weeks after go-live the sales team found that a national account existed as eleven separate golden records, one per acquired ERP plus a few more from the CRM, and confidence in the program took a hit it did not fully recover from for a quarter.
Match tuning on a real multidomain program does not end. It is a standing activity with a named owner, a labeled evaluation set that grows every sprint, and a precision-and-recall report that goes to the same steering committee that sees the queue metrics. On this program we started that practice in month fourteen. It should have started in month four, before the first production load, with the labeled set built from the very pairs the business argued about in workshops. Those arguments were free training data and we let them evaporate.
4. Survivorship rules were written by IT and owned by nobody
Survivorship, the logic that decides which of several conflicting values becomes the golden one, was configured by the implementation team based on a spreadsheet of source-system rankings that a data architect assembled in a week. It was defensible and nobody owned it. When the CRM's billing address won over the ERP's billing address and an invoice went to the wrong site, the question of who had decided that had no answer. The rule was in Reltio, the spreadsheet was on a laptop, and the architect had rolled off.
Every survivorship rule now gets a business owner by name, a one-paragraph rationale in plain English, and a review date. The rules live in a governance register the stewards can read, not only in the tenant configuration. Where the business cannot agree on a rule, we default to most-recently-updated with the conflict flagged to a steward, and we make the disagreement itself a governance ticket rather than a technical decision. That sounds bureaucratic. It is considerably cheaper than a misdirected invoice run.
5. We built for batch and were asked for real-time in month nine
The integration architecture was nightly. Sources landed in a staging layer, a batch job pushed to Reltio, Reltio published to a downstream topic, and consumers picked up changes the next morning. Every requirement we had been given fit that pattern. Then the e-commerce team, in month nine, decided that a new B2B customer registering on the storefront needed a golden record and a credit-check identifier before checkout completed, which meant a synchronous create, match, and return inside a two-second budget. Reltio can do that. Our integration layer could not, and retrofitting an event-driven path alongside a batch path that was already in production took eleven weeks and introduced a class of ordering bugs, where the batch load overwrote a real-time change from an hour earlier, that we were still chasing at go-live.
We now design the event path first even when nobody has asked for it, because on a multidomain program somebody will. The batch path becomes a bulk producer onto the same event stream rather than a separate channel with its own semantics. That single decision, made in week one instead of month nine, removes the ordering problem entirely and costs almost nothing extra to build.
6. We sized the steward team from the vendor estimate
The staffing model assumed two full-time stewards for customer, one for product, and a half for supplier. Those numbers came from a benchmark and they were wrong by roughly a factor of three for the first six months after each domain went live, because the initial load surfaced every unresolved conflict in forty systems at once. The queue hit fourteen thousand potential matches in the first week of customer go-live. Two people cannot clear that, and a queue that cannot be cleared is a queue that gets ignored, at which point the golden record is only as good as the automated rules and the business knows it.
The staffing shape that works is a surge team for the first ninety days after each domain load, typically five to eight people who know the source data rather than generic stewards, followed by a steady-state team sized from the observed queue rate rather than from a benchmark. We also now insist that the surge team includes at least two people from the business unit that owns the domain, because a steward who does not know that the Houston branch and the Houston distribution center are different customers will merge them, and the rules will learn from the merge.
The eighteen months as they happened, and as we would run them now
Laid side by side, the two timelines are not radically different in total length. The difference is where the risk sits. The program as run pushed the hard problems, match quality, survivorship ownership, real-time integration, to the back half, where they collided with go-live dates. The program as we would run it pulls them forward into months two through six, where they are cheap to get wrong.
| Months | What we did | What we would do now |
|---|---|---|
| 1–2 | Customer workshops, model design, sponsor-driven sequencing | Cross-domain dependency map, thin product hierarchy, event-first integration design, match-key freeze |
| 3–5 | Customer model grows to 200+ attributes, batch integration built | Labeled match set built from workshop disputes, survivorship register with named owners, thin product live |
| 6–8 | Six-week match tuning block, UAT, customer go-live with 2 stewards | Customer go-live with 6-person surge team, weekly precision/recall report begins |
| 9–12 | Real-time retrofit, ordering bugs, product model design, national-account duplicate incident | Full product domain deepened on the live hierarchy, steady-state stewards sized from observed queue |
| 13–15 | Product go-live, customer relationships remodeled and reloaded, match practice finally stood up | Supplier domain, cross-domain relationships loaded once against stable references |
| 16–18 | Supplier go-live, stabilization, survivorship rules retro-documented | Stabilization, first governance review cycle, hand-off to a program that already runs itself |
What we would keep
Not everything needs changing, and a post-mortem that lists only failures is as misleading as a deck that lists only wins. Three things on this program were right and we would fight to keep them. The first was choosing a single multidomain tenant rather than one tenant per domain, which the client's architecture board pushed for on the grounds of blast radius. Cross-domain relationships are the entire point of multidomain MDM, and splitting tenants would have turned every one of them into an integration project. The second was refusing to let any consumer read from a source system once the golden record for that domain was live. It caused friction for about a month and then the friction disappeared, along with the shadow spreadsheets. The third was putting a data quality dashboard in front of the CRO from week one, before there was much to show, so that the executive sponsor had spent a year watching the numbers move and did not need to be persuaded of anything when the national-account incident hit.
What we would insist on
If we were starting this program again on Monday, four conditions would be non-negotiable before the first workshop. Sequencing is decided by the dependency graph and signed off by the architecture board, not by whichever sponsor has the nearest deadline. The match-relevant attribute set is frozen before tuning starts, and match quality has a named owner, a labeled set, and a recall number from the first production load onward. Every survivorship rule has a business owner and a plain-English rationale in a register the stewards can read. And the steward plan has a surge budget for the first ninety days of every domain, staffed with people who know the data rather than people who know the tool.
None of these is a Reltio problem. The platform did what it was configured to do throughout, including in the months when we configured it badly. Every item on this list is a program-management decision that was made, or not made, in the first quarter, and every one of them showed up as a technical incident in the third. That is the pattern worth remembering. Multidomain MDM programs rarely fail on the platform. They fail on the sequencing, the ownership, and the staffing decisions that were treated as too obvious to write down.
Apptad is a Reltio Strategic Implementation Partner, and our multidomain practice has carried programs like this one from the dependency map through steady state. If you are planning a multidomain program or trying to recover one that has stalled, talk to our MDM team and we will walk through where your risk actually sits.
