Composite pattern: a multinational replacing a legacy PIM

Situation: a legacy PIM shared by several business units

This is a composite pattern built from several PIMvendors selections, and it names no client or vendor. It describes a multinational group with several business units in different European countries. The group ran a PIM that had been in place for many years.

The legacy PIM was hosted on premises and heavily customised. Each business unit had added its own attributes, workflows and exports. Upgrades had stopped because each one broke a customisation. The vendor's roadmap had moved to a new platform.

The cases overview lists the other composite patterns. The guide to replacing an existing PIM covers the wider programme.

Complication: the customisations had become the requirements

The first draft of the RFP described the old system's customisations as requirements. Business units listed every feature they used, including workarounds for limits that newer platforms no longer have. The result was a long requirements list that only the legacy platform could meet.

Governance was a second problem. Each business unit had changed shared attributes for its own needs. The same attribute meant different things in different countries. Nobody had authority over the group-wide model.

Migration risk worried the board. A failed migration would stop product launches across several markets at once.

What the selection did differently

The selection rebuilt the requirements from the business need, then checked which customisations still served one. The order followed Data, Process, People and Tooling.

1. The team inventoried every customisation and traced it to a current business need or retired it.
2. A group data model was defined, with global attributes and clearly marked local extensions.
3. A federated governance model was agreed: a global owner for shared attributes, local owners for market content.
4. Requirements were tagged by domain, with Platform and vendor weighted for scale, security and exit terms.
5. The RFP included a migration scenario based on an extract of real legacy data.

The data migration guide describes the migration planning that followed.

Which scenarios decided the selection?

The decisive scenarios tested migration, federation and integration at group scale.

Vendors also had to explain how they would exit the platform. Data export formats and contract terms were scored under Platform and vendor.

Outcome patterns

Retiring customisations narrowed the requirements more than any vendor demo did. Many legacy customisations served needs that the business no longer had. Others turned into standard configuration on modern platforms.

The global and local attribute scenario separated the shortlist clearly. Some vendors handled inheritance and permissions natively. Others needed custom development, which recreated the problem the group was trying to leave.

The migration scenario changed the implementation plan. Data quality issues in the legacy extract surfaced during demo preparation, early enough to plan a cleansing phase.

Where this pattern goes wrong

The pattern fails when every business unit holds a veto over the group model. Selections that tried to satisfy each unit's full wish list rebuilt the legacy complexity on a new platform. The group model then carried as many exceptions as the old one.

Underestimating migration is a second failure point. Teams that treated migration as a technical copy found the legacy data inconsistent across units, and cleansing work arrived late. A third risk is ignoring exit terms. A group leaving a platform because of lock-in should score how easily it could leave the next one.

Lessons for multinationals in a similar position

Derive every requirement from a current business need. Four lessons recur across the engagements behind this pattern.

• Trace every legacy customisation to a current need before writing the RFP.
• Agree federated governance before testing it in demos.
• Use a real legacy data extract in a migration scenario.
• Score exit terms and data export formats alongside features.

Groups facing regulatory deadlines during replatforming can compare this pattern with the packaging compliance pattern. The manufacturer pattern shows the same data model discipline at smaller scale.