Most MDM project plans end at cutover. The final slide is green. The consultants invoice the last phase. Someone sends a thank-you email. Three weeks later the platform has 400 unreviewed changes in the approval queue, two open integration tickets nobody understands, and a finance director asking why the supplier dashboard does not match the GL.
The first 90 days after go-live are not a victory lap. They are the most fragile window the platform will ever go through, and they decide whether the new MDM becomes the system everyone trusts or the system everyone goes around. I have watched both outcomes, more than once. The difference is rarely the platform. It is whether anyone planned the 90 days.
The handover that wasn't
Every project plan has a handover slide. It usually says something like "transition to operations" and lists three names. By Friday of the cutover week, the implementation partner has rolled their best people onto the next project. The stewards who spent six months on this engagement go back to being 30%-time on MDM and 70%-time on their day job. The IT manager who sponsored the project is in budget meetings for the next quarter.
What is left in the room is a tool, a few stewards, and an unspoken agreement that "we will figure it out." That agreement holds for about ten days.
Days 1–7: production volumes find the bugs
The first week is integration tickets. Not the slow, polite kind. The kind that come in on Tuesday afternoon because the nightly job that pushes new suppliers to NetSuite ran for an hour and then died on a record that had a comma in the name. The test data did not have commas. The production data has thousands.
Other things that surface in week one: the publish job that ran in 90 seconds in UAT now runs in 25 minutes because production has 200x the row count. A subscriber view that looked fine in test is missing three columns the downstream consumer assumed were there. A SAP RFC call times out because production goes through a different network route than test did.
None of these are platform bugs. They are the gap between "passed UAT" and "works at real volumes against real downstream systems." The implementation team usually planned for this and budgeted hypercare for two weeks. Sometimes they did not, and that is when day eight gets ugly.
Days 8–30: the steward queue compounds
By the start of week two the integration tickets are slowing down and the approval queue is filling up. This is the moment most projects discover that real usage produces ten to fifty times more change requests than the test phase did. Procurement is now creating new suppliers daily. Operations is updating attributes that used to live in a side spreadsheet. A shared-service team is mass-correcting old data because they finally have a tool that lets them.
The stewards who used to clear the queue in 30 minutes a day now have 200 items waiting. They review the easy ones. The borderline cases sit. After a week the queue has 400 items, the oldest is 11 days old, and the steward lead opens it in the morning, scrolls for a minute, closes the tab, and goes to a meeting. That is when the queue stops being a queue and starts being a graveyard.
The fix is unglamorous. A standing 20-minute review at 9:15 every morning, with two named owners, one primary and one backup. Not a weekly governance meeting that gets canceled twice and then forgotten. Daily, short, on the calendar, in production from day one. The teams that do this never lose the queue. The teams that postpone it to "once things settle" never get it back.
Days 31–60: the first "this is wrong" tickets
Somewhere in week five, a controller pulls up a supplier spend report and the number is off by 4%. The MDM is suspect because it is new. The MDM is investigated. The MDM is, often, wrong about something nobody noticed at cutover.
The cause is rarely a bug. It is usually an assumption from the load that turned out to be wrong. Eight suppliers got merged that should not have been. Inactive records were marked active because the source system used a flag the load did not interpret correctly. A reference-data mapping was applied to a region that did not match. None of these are visible until someone looks at a totaled number and asks where it came from.
The platform makes this either bearable or unbearable. The bearable version: the steward opens the record, sees the change history, finds the merge that introduced the error, unmerges it, and the published view updates within the hour. The unbearable version: there is no change history, the merge is permanent, and the only fix is to retire the bad record and create a new one, which breaks every downstream reference. If you did not look at the audit trail and unmerge story during the demo, this is the week you wish you had.
Days 61–90: scope creep arrives, on schedule
Two months in, the platform has proved itself enough that people start asking it to do more. The pattern is consistent. A neighboring team wants their domain on it (we did supplier, can we do customer). An attribute someone forgot is requested (we need a payment-terms field, can you add it). A new downstream consumer wants a feed (the warehouse team would like the supplier extract, can you publish it).
These requests are good news. They mean the platform is being adopted. They are also the moment where the project transitions from "delivered" to "owned," and the absence of an intake process becomes visible. Without one, requests get answered ad hoc, by whoever the requester knows, and the operational team loses the ability to say no, or even to say later.
The fix is a simple intake form with a triage cadence, owned by a single person who can decide. It can live in Jira or a Teams channel. What matters is that there is one place where every request lands and a public answer for each one. The platforms that scale past go-live have this in place by week eight. The ones that stall have a backlog spreadsheet nobody opens.
The four metrics that show what is happening
None of these appear on a vendor scorecard. All four predict whether the platform is healthy or drifting, weeks before anyone calls a meeting about it.
| Metric | Healthy | Drifting | Owner |
|---|---|---|---|
| Steward queue age | Oldest pending < 3 days | Oldest pending > 14 days | Data steward lead |
| Publication freshness | Downstream sees changes same day | Lag > 48 hours | Integration engineer |
| Writeback rejection rate | Under 1% of attempts | Above 5%, climbing | Source-system owner |
| "This is wrong" tickets | Under 5 per week, all resolved | Backlog growing each week | Business sponsor |
Track them weekly. A spreadsheet is fine. Put the numbers on a wall if it helps. The point is that someone has to be looking, because the moment one of them starts climbing is the moment the next month gets harder, and the moment to act is then, not in month five when the controller calls.
What to budget for before cutover
Four line items, none of which the vendor will put on the SOW unless you ask.
- Sixty days of partner availability. Not a full team. One person, available a few hours a day, who knows the build. They triage the tickets, document the patterns, and quietly transfer knowledge to the operational team.
- Steward time at 60%, not 20%. The day-job rebound is real. For the first two months stewards need to be carved-out time, not "as available." Tell their managers in writing, before cutover, what hours are protected.
- An intake process for new requests. A form, a triage cadence, a named owner who can decide. Set it up the week before go-live so that when the first "can you add a field" request arrives in week six, it lands somewhere.
- A weekly metrics review. Twenty minutes. Four numbers. One slide. The first time you skip it is the week the queue starts climbing and nobody notices until month three.
Three questions to ask before you sign "project complete"
The three questions below are the ones that separate the cutover that holds from the cutover that quietly unravels in month two. Ask them before the steering committee declares victory.
Who owns the steward queue on day eight?
If the answer is "the steward team," ask which specific person, which time of day, and what the escalation path is when they are out. A queue without a named daily owner accumulates for a month and then nobody wants to open it. The platform should make it easy to see queue age at a glance, not just queue size.
What does the integration team see when a writeback fails?
A vague "sync error" is not enough. The platform should show the row, the target system, the exact response from the target, and a button to retry once the cause is fixed. Without that, every writeback failure becomes a 45-minute Slack thread, and the team stops investigating after the third one.
How does the platform handle a request to add a new attribute in week six?
This will happen. Operations will discover a field they need, and the platform that requires a schema deploy and a four-week change-control process for every new attribute will quietly become "the system that takes a month to add a column." Look for a platform where adding an attribute is a steward action with an audit trail, not a developer ticket.
What MDS taught everyone the hard way
Most MDS deployments hit the same wall around month three. The Excel add-in was the only steward UI, the change history was thin, and the moment a real "this is wrong" investigation started, the team ended up writing T-SQL against the staging schema to figure out what had happened. The platform did not stop them. It just did not help.
The lesson is not that MDS was bad at this. The lesson is that the first 90 days were never designed into the product, and the burden landed on the operational team to invent a workflow on top of a tool that did not know they existed. A modern MDM should have the daily-queue view, the change-history-with-unmerge story, the intake form, and the four metrics built in. If those things are not in the demo, you will end up building them yourself.
For more on what the cutover itself looks like, see the earlier post on the initial data load, and on the political side of operating an MDM, the post on who actually owns your master data.
What to do this week
If you are scoping a project, add the four budget lines above to the SOW now. They cost less in advance than in panic-mode in month two, and the conversation with the partner about who covers what is much easier before the contract is signed.
If you are already live and the queue is climbing, the answer is almost always the same: a daily 20-minute review at a fixed time, two named owners, starting tomorrow. It is the smallest possible intervention and the one that consistently turns a drifting platform around inside two weeks.
And if you are still on MDS and thinking about a cutover, the operational gap is the part that does not show up on the comparison matrix. Run the four metrics against your current setup. The honest answer to "how would we even know the queue is backed up?" is usually the most useful thing you will write down all month.
Common questions
What happens in the first 90 days after MDM go-live?
Week one is integration tickets that only surface at production volumes. Weeks two to four are the steward queue compounding faster than anyone reviews it. Weeks five to eight bring the first "this is wrong" reports from business users. Weeks nine to twelve are scope creep: new domains, new sources, new reports. Plan for all four phases or the platform stalls.
Why does the steward queue back up after go-live?
Real usage produces ten to fifty times more change requests than the test phase did. Stewards are part-time again after the project ended. Approval criteria are still being calibrated. The fix is a daily 20-minute review cadence from day one, not a weekly meeting that gets canceled twice.
How do I know whether the go-live is succeeding?
Four metrics. Steward queue age, publication freshness, writeback rejection rate, and count of "this is wrong" tickets from business users. If any of them is climbing in week six, you are drifting into an operational hole. None appear on a vendor scorecard.
Should the project team stay involved after go-live?
For at least 60 days. The Friday-after-cutover handover is an accounting fiction. The implementation partner should keep someone available for at least two months to triage tickets, document the decisions that get made under pressure, and answer the questions the operational team did not know to ask.
The first 90 days, on your real data
Primentra ships with a daily-queue view, a full change history with unmerge, an intake-style request log, and an audit trail wired into every approval. The 60-day trial runs against your real data, long enough to put one full operational cycle through the platform before the contract conversation.