How to plan a cosmetics PLM migration: what to audit, protect, and decide first

What should you audit before a PLM migration?

Before scoping anything, inventory your product data. Not a summary — a count. Vendors size projects from this, and so should you. 

Work through the ten categories below. For each, record volume, where it lives today, who owns it, and whether it must transfer or can be archived.

What cannot break during a PLM migration?

Some things tolerate a bumpy transition. These four do not.

Regulatory continuity

Your obligations do not pause during a platform change. In the EU, Regulation (EC) No 1223/2009 requires a Product Information File to be kept available and up to date for each product placed on the market, and products to be notified through the Cosmetic Products Notification Portal. In the US, the Modernization of Cosmetics Regulation Act sets facility registration and product listing obligations, and requires safety substantiation.

Ask three questions of any plan:

• Who is responsible for regulatory records during the transition period?
• If a market changes a restriction mid-migration, which system reflects it, and how fast?
• Can you produce a complete dossier for any product, on demand, on every day of the project?

Launches already in flight

Products in development do not wait. Map every launch against the migration timeline and decide, per project, whether it completes in the old system or moves. Split projects are where data quality problems begin.

Supplier connections

If suppliers submit documents, specifications, or certifications through your current platform, they experience the migration as a change to their working day. Tell them early, give them a single point of contact, and confirm nothing expires unnoticed during the switch.

Audit trail and traceability

Establish before you sign what happens to historical audit records. Three common outcomes, in descending order of value: full migration with history intact; migration of current state with history preserved in read-only archive; snapshot only. Know which one you are buying.

How do you decide the scope of a PLM migration?

This is the decision most teams skip. A forced migration is treated as a like-for-like replacement: same scope, new platform, minimum disruption. That is a reasonable instinct and sometimes the right answer. It is worth testing once. 

You are absorbing the cost and disruption of a migration either way. Data has to be mapped, users retrained, integrations rebuilt, processes revalidated. That cost is largely the same whether you replace what you had or replace more than what you had. The question is what you get for it. 

If the migration effort is fixed, what is the widest set of problems it could solve? Answer that before you shortlist, because scope decides the shortlist — not the other way around. 

Work through where product data currently sits outside your PLM:

• Packaging specifications, artwork versions, and approval trails — in a separate system, or in files?
• Supplier documents and certifications — in a portal, or in email?
• Regulatory assessments for markets outside your core — in the platform, or in spreadsheets?
• Portfolio and project reporting — native, or exported and rebuilt monthly?
• Products in adjacent categories — food supplements, home care, personal care devices — managed in the same system, or somewhere else?

Each answer of "somewhere else" is a handoff, a reconciliation step, and a place where a regulatory question takes a day instead of a minute. Count them. Then decide whether the next platform should absorb them or leave them where they are. 

There is no universally correct answer. A single-category business with clean adjacent systems may be right to replace like for like. A business spanning categories, or one where packaging and supplier data have drifted into spreadsheets, is paying a coordination tax that a wider platform would remove.