Every migration plan describes what will be moved: how the data gets extracted, mapped, validated, and loaded. It is a technical document and it usually gets written well. What almost none of them contain is a section on what will not be moved, and that omission is the single most reliable predictor of whether the new system will be trusted a year after go-live.
The reason is not carelessness. It is that “move everything” is a decision nobody has to make, defend, or sign. Every other option requires somebody to say out loud that a particular set of files is not worth carrying forward, and that is a sentence with a name attached to it.
Why migrating everything wins by default
Watch how the decision actually gets made. Someone asks in a meeting what the migration scope should be. There is a pause. Then somebody says that it is safer to take everything, and that we can always clean it up later.
Nobody objects, because objecting means proposing that specific data be left out, which means being the person who was wrong if it turns out to be needed. The default is not chosen on its merits. It wins because it is the only option that carries no personal risk.
The clean-up afterwards does not happen. It never has an owner, a budget, or a deadline, and by the time anybody thinks about it again the data has been in the new system long enough to look official.
“Migrate everything” is not a data strategy. It is a liability avoidance strategy.
It is a rational response to a decision structure where being wrong about a deletion is punished and being wrong about the volume is not.
What that decision actually costs
The cost does not show up as a line item. It shows up as three symptoms that get attributed to the new system.
Search stops being useful
A search for a part number returns eleven results: the current revision, four superseded revisions, two variants for products discontinued in 2019, and four duplicates created under an old numbering convention. The user now has to determine which one is correct, every time, and there is nothing in the system that tells them.
Within a few months they stop searching and start asking a colleague, which is exactly the behaviour the system was bought to eliminate.
Nobody trusts what they find
Trust in a data set is not built gradually. It is lost the first time someone acts on a result that turns out to be an obsolete revision. After that, every result gets verified against something else, and the verification step becomes permanent.
The old habits come back
An engineer who cannot reliably find the current version in the system will keep a folder of the files they know are correct. That folder is a workaround, and it is a rational one. It exists because the migration made the official route unreliable.
A part with four numbers
A bracket, still in production, still selling. In the legacy system it exists as four separate part records.
The original from 1998, under the numbering scheme in use at the time. A second created in 2007 when the numbering convention changed and somebody re-entered rather than migrated. A third created in 2014 by an engineer who could not find the existing one and made a new one. A fourth from 2019, created deliberately as a variant for a customer who then cancelled.
Three of the four have drawings attached. Two have BOMs. One is linked to a live ERP item. All four have revision history.
Migrated wholesale, the new system inherits all four, and every engineer who searches for that bracket for the next decade has to work out which one is real.
Multiply that by a parts catalogue with several thousand entries. This is not an unusual situation. It is what accumulation looks like in any company that has been designing products for two decades and has changed its conventions at least once.
Three destinations, not two
The decision is usually framed as binary: migrate or delete. That framing is what makes it hard, because deletion feels irreversible and most of the data has some conceivable future value.
There is a third option, and introducing it resolves most of the deadlock.
| Destination | What goes there | Why |
|---|---|---|
| Migrate | Current revisions of active parts, live BOMs, documents referenced by production, anything under active change | Has operational value. Someone will need it to do their job this year. |
| Archive | Superseded revisions, discontinued products, records under a legal retention obligation, historical projects | Has evidentiary or historical value. Needs to be retrievable, not searchable daily. |
| Leave | Duplicates, abandoned variants, drafts that were never released, files nobody can identify | Has no value that anyone can articulate when asked directly. |
The middle column is what makes the conversation possible. Almost nobody will agree to delete twenty years of history. Almost everybody will agree that a 2003 revision of a discontinued product does not need to appear in a search result an engineer runs forty times a day.
The distinction that unlocks the decision
There is one confusion that stalls more migration scoping workshops than any other, and clearing it up usually moves the discussion within minutes.
A legal obligation to retain data is not an obligation to have it in the working system.
Regulated sectors have genuine retention requirements: product records held for a defined number of years, evidence of change control, traceability of what was built when. Those requirements are about being able to produce records if asked. They say nothing about where the records live or how quickly they can be retrieved.
An archive that is exportable, readable, and demonstrably complete satisfies a retention requirement. It does not need to be in the PLM system that engineering uses daily, and putting it there does not make compliance stronger. It just makes search worse.
Ask the question precisely: does this need to be retrievable, or does it need to be in the way?
Most of what people insist on migrating needs the first and is being given the second.
Who decides, and why nobody does
The migration scope decision needs a named owner per data domain: someone who can say that a particular category of records is not migrating and who has the authority to be wrong about it occasionally.
In most companies this is never assigned, and the reason is structural. IT owns the migration project but has no basis for judging which engineering data matters. Engineering knows which data matters but is not in the project. Quality has retention obligations but is only consulted when someone remembers.
So the decision falls to whoever is running the project, who reasonably concludes that they are not qualified to make it, and defaults to taking everything.
Assigning ownership is the fix, and it is a Phase 1 decision rather than something to resolve during data preparation. By the time the migration is technically underway, the schedule no longer allows for the conversation.
The uncomfortable part
Running this exercise properly produces a finding that nobody puts in the project plan.
Somewhere between a fifth and a third of what is in a legacy system cannot be identified by anyone currently at the company. Not obsolete, not superseded, simply unattributable. Nobody knows what it was for, who created it, or whether anything depends on it.
That data has been invisible for years and has been costing nothing, right up until someone has to decide what to do with it.
The temptation is to migrate it, because leaving behind something unidentified feels riskier than leaving behind something known to be obsolete. In practice it is the opposite. Unidentified data in a working system is worse than unidentified data in an archive, because it appears in search results and looks equally authoritative alongside everything else.
The workable answer is usually to archive it, note that it is unattributed, and move on. What is not workable is discovering the problem in week eleven of a fourteen week migration.
How to run the decision
Four steps, none of which require the new system to exist yet.
1. Inventory before scoping
Count what is actually there, by category and age. Most companies are surprised by the distribution, and it is difficult to make a scoping decision about a volume nobody has measured.
2. Name an owner per domain
Parts and BOMs, drawings, documents, project records, quality records. Each gets one person who decides. Not a committee, and not the project manager by default.
3. Decide by rule, not by record
Nobody is going to review several thousand parts individually. The decision is made as rules: superseded revisions older than a given date go to archive, parts with no ERP link and no activity in five years go to archive, and so on. Then spot-check the rules against real examples before applying them.
4. Define what archive means before you need it
Where it lives, in what format, who can retrieve from it, and how long it is kept. An archive that nobody can actually read in three years is not an archive, and this is the step most often left as an assumption.
These decisions belong in the blueprint phase of an implementation project, alongside the configuration decisions, and they are cheapest to make there. Made later, they get made under schedule pressure, which is how “migrate everything” wins again.
What if we leave something behind and then need it?
This is the fear that drives the default, and it is worth separating from the reality. If the data is archived rather than deleted, needing it means retrieving it, which is inconvenient rather than catastrophic. Companies that archive properly report this happening a handful of times in the first year and almost never after that.
How long does the scoping decision take?
The inventory is a few days of technical work. The decision itself is typically two or three workshops, once the owners are assigned. What extends it is not the volume of data but the absence of anyone empowered to decide, which is why assigning ownership first matters more than it appears to.
Can we migrate everything now and clean up later?
You can, and it is worth being honest that it almost never happens. Clean-up after go-live has no deadline, no budget, and no visible consequence for skipping it, while everyone involved has moved on to other work. If the plan depends on a phase that follows the project, the plan is that the data stays as it is.
Does this apply to a version upgrade as well?
Less so, because an upgrade carries the existing data forward without a mapping exercise. It is still a reasonable moment to run the inventory, since the effort is small and the finding is often that a meaningful proportion of what is being carried forward has not been touched in a decade.
Who should own the decision if our engineering team is small?
Usually the most experienced engineer, and it is worth protecting their time to do it properly rather than adding it to their existing load. The decision is judgement work rather than volume work, and in a small team that judgement exists in one or two people who are already fully occupied.
Planning a PLM migration?
The scoping decision is cheapest to make before the project starts and most expensive to make during it. Tell us what you are moving and we will tell you where the difficult calls are going to be.