A few years ago, I led the rollout of a master data management platform (Stibo STEP) to replace an aging Product Information Management system at a Fortune 10 company. The implementation itself went relatively smoothly across all three phases — locations, vendor onboarding, and product data. The real lessons emerged afterward: evolving the solution, training a much broader set of stakeholders, and migrating data at serious scale.
These experiences continue to shape how we drive enterprise data quality.
Phase 1 — Locations
Approximately 10,000 sites across retail, pharmacy, and more — launched successfully and delivered exactly what we expected. The wrinkle came later when we extended the model to support mid-day closures, a use case the original design hadn't fully anticipated. Updated hours didn't always propagate reliably downstream to systems like IVR, the website, and third-party map integrations. It was a reminder that even a successful go-live needs flexibility to absorb requirements that weren't on the table at launch.
Phase 2 — Vendor Onboarding
Had its own set of technical surprises. Beyond the adoption challenge of internal teams now supporting vendor logins and credentials, we encountered real issues: onboarding emails not reaching vendors and display problems that affected the vendor-facing experience. Small things, but for an external-facing process, they had an outsized impact on first impressions.
Phase 3 — Item Data
Was the biggest lift by far — hundreds of thousands of items, new workflows spanning teams well beyond MDM, and a migration effort that tested everything we'd built. Here are a few migration issues worth flagging for anyone planning something similar:
- Legacy data doesn't map cleanly to the new model. Attributes that seemed equivalent often had different meanings, formats, or business rules across systems — requiring real reconciliation, not just field-to-field mapping.
- "Good enough" source data isn't. Issues that were invisible or tolerable in the old system — duplicates, inconsistent values, missing attributes — become blockers once a new platform enforces structure and validation.
- Volume creates blind spots. At hundreds of thousands of items, it's simply not possible to manually catch every edge case before go-live. Some issues only surface once the data is live and in use. Plan for a post-launch remediation process, not just a pre-launch one.
- Cutover timing matters. Coordinating when each team's workflows shift to the new system — without breaking what's flowing to production — takes more planning than people expect.
The Biggest Lessons
- Plan for evolution, not just go-live. A successful implementation can still surface new needs once real-world usage stresses the design.
- Map the full impact of new responsibilities. New systems often create internal work that has nothing to do with training. Plan for that operational shift too.
- Treat data migration as its own project. Resourcing, sequencing, and data quality remediation deserve dedicated planning — not just a line item in the broader rollout.