PIM implementation: from contract to go-live

Why are most failed PIM implementations decided during selection?

Most failed PIM implementations were decided during selection, months before the first configuration sprint. The implementation then executes decisions that were never made properly. PIMvendors sees four of them repeatedly.

1. The data model was never defined. Design workshops reopen every requirement, and scope grows each week.
2. The partner was chosen on day rate. The team knows the software and lacks data model or integration depth.
3. Scope was set by the vendor demo. Requirements that mattered to the business surface during testing.
4. The contract lacked named key staff, acceptance criteria and change control. Every dispute becomes a negotiation.

Each of these is cheaper to fix during selection. The hub's thesis applies: most PIM selections fail before the first demo, because buyers compare software before they define their data model. The why PIM selections fail page covers the selection side.

This pillar starts where the contract is signed. It covers the phases to go-live, the governance that must exist before go-live, and the guides for each step. If you are still in selection, the PIM contract checklist is the place to secure the conditions this pillar assumes.

What are the phases from contract to go-live?

A PIM implementation runs through seven phases, with migration and integration running alongside build. Each phase ends with a signed-off output. Durations below are PIMvendors estimates for a mid-sized scope.

Two rules keep phases honest. First, no phase starts on an unapproved predecessor output: build on an unapproved data model guarantees rework. Second, migration rehearsals start early, during build, because they reveal data model gaps while they are still cheap to fix.

Large scopes split into releases. A first release covers one brand, market or channel, and later releases add scope on a working base. The implementation timeline page gives ranges by scope.

What governance must exist before go-live?

Data governance must be working before go-live, because a PIM without owners and rules fills with inconsistent data within months. PIMvendors uses the sequence Data, Process, People, Tooling; the PIM is the tooling.

1. 1DataThe model, the attributes and who owns each attribute group
2. 2ProcessHow products are created, enriched, approved and published
3. 3PeopleOwners, data stewards and the capacity to do the work
4. 4ToolingThe platform that runs the first three

The minimum governance at go-live has seven elements:

• A product data owner with authority over definitions and priorities.
• Stewards per product domain, with time allocated in their roles.
• An attribute dictionary: definition, type, unit, allowed values and owner per attribute.
• Completeness rules per channel and market.
• A change request process for the data model, with a decision forum.
• Quality measures with a baseline taken at go-live.
• Supplier data rules: formats, required fields and acceptance checks.

Regulatory data raises the stakes. PPWR applies generally from 12 August 2026. Packaging data managed in the PIM therefore needs an owner and an audit trail from the first day of production. The compliance pillar explains which regulations apply.

These elements belong in the implementation plan as deliverables, with owners and dates. A partner can configure workflows. Only the company can appoint owners and stewards and give them time. The product data governance page describes the model in detail.

How do you choose the implementation partner?

Choose the implementation partner on data model expertise, team continuity and relevant references, with day rate as one factor among seven. The partner shapes the data model, the integrations and the habits your team adopts.

Partners come in three types: the vendor's own professional services, global system integrators and specialist boutiques. Each type has strengths. Vendor teams know the product roadmap. Integrators bring scale and ERP depth. Boutiques often bring the most PIM-specific experience per consultant.

PIMvendors evaluates partners on seven weighted criteria:

Run partner selection with the same discipline as vendor selection. Ask shortlisted partners to run a short design workshop on one of your product families. The choosing a partner guide explains the process, and the partner scorecard provides weights and scoring anchors.

Why is data migration the critical path?

Data migration is the critical path because every other phase depends on real data arriving in the new model. Testing on sample data hides problems that surface only at full volume.

Migration has five stages:

1. Profiling: measure what the source data contains, field by field.
2. Cleansing: fix, enrich or retire records before they move.
3. Mapping: link every source field to a target attribute with conversion rules.
4. Rehearsals: run full migrations into a test environment and reconcile results.
5. Cutover: freeze changes, run the final migration and verify.

Migration effort is easy to underestimate. Source data lives in ERP fields, spreadsheets, old PIMs, webshops and shared drives. Each source has its own codes, units and gaps. Profiling turns that uncertainty into numbers before the plan is fixed.

Rehearsals are the most important control. A plan with at least three full rehearsals catches mapping errors, performance problems and missing values while there is time to fix them. The data migration guide covers each stage with checklists.

Ownership matters as well. The partner runs the tooling; the business owns the decisions about which data to keep, fix or retire. Put those decisions on the governance agenda from the first month.

How long does a PIM implementation take?

A PIM implementation takes about 3 to 18 months, depending on scope, as a PIMvendors estimate. Scope here means products, languages, channels, integrations and data quality together.

Four factors stretch timelines more than any other. Undefined data model decisions reopen design. Poor source data extends migration. Slow decisions on the client side stall every phase. Integrations with older ERP systems take longer than planned.

Timelines also compress for good reasons. A data model designed before selection, a dedicated product data owner and clean source data can shorten design and migration considerably.

Deadlines driven by regulation or by a contract end date need a fallback. Plan a minimum viable release that meets the hard date, with further scope after it. Define that release by channel and product family, so everyone knows what goes live first.

Challenge any plan that shows design and build overlapping without a signed data model. In PIMvendors selections, that overlap is the most common source of rework and of disputes about change requests. The timeline guide explains how to build and challenge a plan.

What happens after go-live?

Go-live starts the period in which the business case is won or lost. The first 90 days decide whether users adopt the PIM and whether data quality improves or slides back.

Three workstreams run after go-live:

• Stabilisation. Hypercare fixes defects, tunes performance and clears the backlog of migration issues.
• Adoption. Users move their daily work into the PIM, and shadow spreadsheets disappear.
• Governance. Owners and stewards run the change process and measure quality against the go-live baseline.

Adoption needs deliberate work. The Prosci ADKAR model describes individual change in five elements: Awareness, Desire, Knowledge, Ability and Reinforcement. Training addresses knowledge and ability. Awareness, desire and reinforcement need management attention, clear reasons and visible results.

Measure outcomes from the business case, such as time to market for new products or completeness per channel. Logins and training attendance say little about value.

The first 90 days, user adoption and governance after go-live guides cover each workstream in detail.

What changes when you replace an existing PIM?

Replacing an existing PIM adds contract exit, data portability and parallel running to the standard implementation. The new system has to absorb years of configuration, history and integrations from the old one.

Three issues dominate PIM replacements:

1. Contract exit. Notice periods, renewal dates and export rights in the old contract set the latest start date for migration.
2. Data portability. Products, attributes, relations, assets, translations and history must leave the old system in a usable format.
3. Parallel running. Channels move one by one, so both systems run for a period, with licence overlap.

The EU Data Act adds rights for customers of cloud services. According to Maples Group's overview, switching notice periods are capped at two months and a transition period of 30 calendar days applies. Switching charges are banned from 12 January 2027. Whether and how these rules apply to a specific PIM contract is a question for counsel.

A replacement also brings an opportunity. The data model can be redesigned with the lessons of the first implementation. The replacing your PIM guide explains how to plan the exit and the move.

Which implementation guide should you read next?

Read the partner guides first if you are about to contract, and the migration and governance guides if you have already signed. Each guide in this pillar covers one step with checklists you can reuse.

• Choosing a PIM implementation partner: partner types, selection process and contract points.
• Implementation partner scorecard: seven weighted criteria with scoring anchors.
• Realistic PIM implementation timelines: ranges by scope and the factors that stretch them.
• Product data migration: profiling, cleansing, mapping, rehearsals and cutover.
• Replacing an existing PIM: contract exit, data portability and parallel running.
• The first 90 days after go-live: hypercare, stabilisation and the first value measures.
• Driving PIM user adoption: roles, training and adoption measures.
• Governance after go-live: the operating model that keeps data quality improving.

PIMvendors supports buyers from selection into implementation, including partner selection with the same scenario-based method used for vendors. The hub's selection process describes that method.