Every PLM programme has a line called data migration. It is usually costed by volume — so many parts, so many documents, so many CAD files — and it is usually wrong by a factor nobody plans for.

The public record on this is unusually clear, because the failures are large enough to have been reported.

What the record actually shows

Ericsson set out in 2016 to replace legacy systems for around 25,000 R&D users, with the new platform expected to be running after about fourteen months. Three years later the programme was halted. The detail that matters is not the delay but its cause, reported at the time: "Every time we have tested the migrated data, all use cases failed." The programme was eventually recovered, going live roughly three years late on a reset five-year schedule, by which point most of the original team had moved on (Engineering.com).

A PTC implementation partner, writing from project experience rather than marketing, describes migration as an extract-transform-load exercise covering parts, CAD files, documents and "the entire history of modifications" — and reports one migration of 1.6 million objects taking roughly five months. Their advice is blunter than anything a vendor will tell you: "Don't blindly trust any in-advance estimates." (TT PSC)

An independent consultant recounts a migration estimated at two months that took nearly two years, the overrun caused not by volume but by mapping relational legacy structures onto a new model where attribute values conflicted. His conclusion — that a hybrid landscape keeping legacy data readable is often better than a full migration — is worth more than most methodology (Voskuil).

Three sources, three different scales, one pattern: the estimate misses because it prices the wrong thing.

Volume is not the cost driver

Loading a million clean records is a solved problem. It is fast, it is scriptable and it is not where your money goes.

The cost is in ambiguity — every record where the source data does not answer a question the target system requires. A part with two conflicting material values. A document with three revisions and no clear indication which was released. An assembly referencing a part that no longer exists. A CAD file whose internal reference points at a filename that was renamed in 2014.

Each of those needs a decision. Decisions need someone with the authority to make them, and that person has a day job. This is why migrations slip: not because loading is slow, but because a thousand small judgements queue behind three busy engineers.

So the useful estimate is not how many records but what proportion of records require a human decision, and who is available to make them.

The four decisions that set the real cost

1. How much history comes across.

The instinct is all of it. Consider carefully. Current revisions of active parts is a fraction of the archive and covers nearly all daily work. Full revision history is dramatically more expensive, because history is where the ambiguity is concentrated — old records were created under rules that have since changed, by people who have left.

The middle path is usually right: migrate current state fully, migrate history selectively for what is regulated or contractual and keep the legacy system readable for everything else. A read-only legacy archive is cheap. Recreating its contents faithfully is not.

2. Whether you migrate the mess or fix it first.

Migrating dirty data gives you a clean system full of dirty data, plus a permanent excuse — "that came across in the migration" — that will outlive everyone in the room.

Cleansing first is better but slower, and it competes with the go-live date. The workable compromise is to cleanse the categories that matter and explicitly accept the rest, with the accepted mess documented so nobody spends 2029 wondering what happened.

3. What "the same" means for a CAD file.

This is the one that surprises people. Metadata migration is tractable. CAD is harder, because a CAD file is not a record — it is a record plus a web of references to other files. Migrate the files and lose the references, and the assembly opens with components missing.

The failure mode is delayed, which is what makes it dangerous. As one consultancy puts it, "a broken assembly reference doesn't always surface immediately — it often shows up weeks later when an engineer tries to open a model and half the components are missing" (Hagerman). By then the migration is signed off and the team has dispersed.

4. Whether revision history has to be legally intact.

If you are audited — aerospace, medical, automotive, defence — losing lineage is not an inconvenience, it is a compliance failure. That single requirement can double the migration cost, and it must be established at the start rather than discovered during validation.

How to find out before you commit

Do not estimate. Measure, on a sample, before anyone signs anything.

Take 500 real records spanning your best and worst data — including the assembly everyone apologises for.

Run them through the actual transformation into the actual target system. Not a spreadsheet mapping exercise. The real thing.

Count three numbers. How many loaded cleanly. How many needed a human decision. How many could not be resolved at all without going back to someone who may no longer work there.

The second number is your true cost driver. If 8% of a 500-record sample needs a decision, and you have 60,000 records, you are looking at roughly 4,800 decisions. At even five minutes each with no queueing, that is over four hundred hours of senior engineering time — and it will not be five minutes, and there will be queueing.

That arithmetic, done in a fortnight, is worth more than any vendor estimate. It is also the same discipline as testing a platform on your own data rather than in a prepared demo.

Validate against use, not against counts

The most common validation is a record count: 60,000 in, 60,000 out, sign here. That proves nothing about whether the data works.

Ericsson's programme was stopped because the use cases failed, not because records were missing. Validate the same way:

  • Open the ten most complex assemblies. Do they resolve completely?
  • Take five recently closed changes. Is the affected-items list still correct?
  • Run where-used on twenty parts. Do the answers match the legacy system?
  • Pick three released documents. Is the approval history intact and readable?
  • Ask a real engineer to do a real task unaided, and watch.

A migration passes when people can work, not when the counts agree.

The option nobody offers you

You do not have to migrate everything, and you may not have to migrate at all.

Keeping the legacy system running read-only, and migrating on demand as parts become active, spreads the cost over years instead of concentrating it into one high-risk programme. It is unglamorous, it does not produce a completion milestone anyone can celebrate, and it is frequently the right answer — as Volvo Group demonstrated when it committed to a new platform and kept its legacy product database as the heart of its PLM logic rather than replacing it.

Ask whoever is proposing a full migration what specifically breaks if the oldest 70% of the archive stays where it is. Sometimes there is a real answer. Often there is only the assumption that migration means everything.

Working paper. If you are scoping a migration and want the sample exercise run before the estimate is committed, get in touch.