Every PLM migration reaches the moment when someone proposes leaving data behind. The proposal always sounds reasonable. Older programs are closed, the legacy system is full of records nobody has opened in years, and moving all of it is expensive. A data warehouse or a reporting extract can hold whatever anyone might need later. What that proposal actually does is trade a one-time migration cost for a permanent capability gap, and the gap surfaces exactly when the data matters most.
In 2018, a survey of migration leads by Experian and Data Migration Pro found only 36% of migration projects kept to their original budget and 54% ran late. Cutting scope looks like the obvious way to protect the number. This article, drawn from current migration work, explains why partial migration is the more expensive choice, why “closed” programs are not closed, and how to force the decision into the open before it gets made by default.
Key Takeaways
- Partial migration starts as a small, defensible exception and grows into a second system of record. Only 36% of migrations hold their budget (Experian, 2018), which is why scope cuts look attractive and why they should be resisted.
- In long-lived industries, closed programs come back. The B-52 was planned for 20 years and will fly until 2050 (GAO, 2026). The product record has to outlive any single PLM.
- Every alternative to full migration (a running legacy system, a bare database, or a warehouse) rebuilds a PLM to hold the data the new PLM was bought to hold.
- The migration partner’s job is to put the trade-off in front of leadership, with the lifetime cost attached, before the working level settles it by default.
How a partial PLM migration starts as “a little bit”
Partial migration rarely starts as a strategy. It starts as an exception. Some data genuinely cannot cross from one PLM to another in its native form. Approval histories and workflow records are the usual case. The reasonable answer is to capture them as a report, attach the report to the migrated object, and move on. That is a small, defensible concession, and we make it on most programs.
The trouble is that the concession creates a category, and categories grow. Once the program has a mechanism for leaving things behind, the list of things to leave behind gets longer. It moves from approval histories to closed programs, and from closed programs to a plan where only the active programs migrate and everything else waits in a warehouse until someone asks for it.
At that point the migration has quietly become a fork. The organization now has two systems of record and has committed to maintaining both. CIMdata, writing in 2013 from assessments at hundreds of companies, called the time and cost of migrating legacy data “consistently the most underestimated portions of the implementation project”. Underestimating it is how the pressure to cut scope arrives. The most-cited migration failure studies are old, and it is worth being honest about that. The 2018 Experian figures are consistent with them.
Why the old records are not old
The argument for leaving closed programs behind rests on the belief that closed means finished. In engineering organizations with long-lived products, it almost never does. The B-52 entered service in 1955 with a projected life of 20 years. In 2026, the Government Accountability Office reported that the Air Force now plans to fly it through 2050 and is spending $21 billion across 13 modernization programs to get it there. The F-35’s planned service life was pushed from 2077 to 2088, and its sustainment estimate rose 44% to $1.58 trillion in the process (GAO, 2024). Across weapon systems generally, operating and support costs run to about 70% of total life-cycle cost (GAO, 2026). The product record for these programs has to outlive several generations of PLM software.
The pattern holds well below the level of a bomber. A satellite thruster designed twenty years ago can be exactly the part a new spacecraft needs. When it gets reused, the thruster is not the only thing that comes back. There is a bracket that mounts it, a harness that connects it, a controller that drives it, and a set of relationships that tie all of them together. In a modern PLM, reusing that assembly is a copy operation. In a warehouse of flat records, it is a reconstruction project, because the relationships were the first thing the export dropped.
On a recent PLM consolidation at an aerospace manufacturer, the working-level proposal was to migrate only active programs. Two of the customer’s own engineers argued against it with examples from their floor. One pointed to a vehicle in production today that flies with engines designed for a program retired two decades ago. Another described a flight software update request for a spacecraft that had been in service for many years, with no budget line and no active program.
Updating guidance and navigation code is not a software task. The engineer needs the vehicle’s current mass properties and center of gravity, which have changed since launch: solar panels deployed, propellant spent, possibly an appendage that failed. All of that lives in the product record. If the record is in a system that was retired, the update starts with archaeology.
Reuse is one of the central reasons an organization adopts a modern PLM in the first place. Migrating only the active programs removes the reuse benefit from precisely the parts of the catalog where it has the highest value.
The cost of keeping the old system “just in case”
Every alternative to full migration means paying to keep alive a capability the new PLM was bought to replace, and those costs tend to be left off the comparison. The federal government has measured them at scale. In 2025, the GAO reported that 79% of planned federal IT spending, $83 billion, goes to operating and maintaining existing systems. Of eleven critical legacy systems it examined, aged 23 to 60 years, seven carried known vulnerabilities that could not be fixed without modernization and four ran on unsupported hardware or software. That is what “leave the old system running” looks like once the years accumulate.
Leaving the legacy system running means running unsupported software. Security patches stop. Somebody has to keep the environment alive and understand how it works, for an indefinite number of years, while the skills to do that get scarcer. Keeping only the legacy database is the same problem with a thinner layer of denial. The data is there, but nothing can act on it without rebuilding the capability that used to sit on top.
A data warehouse is the most respectable option and, in our experience, the most expensive. To make legacy records useful, the organization has to rebuild the relationships, the search, the where-used logic, and the reporting that the old PLM provided. That is reinventing a product lifecycle system to hold the data that the new product lifecycle system was purchased to hold. And every option requires training people on two tools and teaching them which tool to consult for which program. Engineers do not think in migration cutoffs. They think in parts and products, and a rule that says “check here for programs after 2019 and there for everything else” is a rule that gets broken every day.
Splitting the product record across two PLM systems is a data quality problem
Splitting the product record across two systems adds cost, and it degrades the data itself. Poor data quality already costs the average organization $12.9 million a year, according to Gartner’s reference-customer research. Tech-Clarity’s survey work has found engineers spend roughly a third of their time on non-value-added work, and 20% of their time working with outdated information (2014). A legacy record that lives in a retired system is outdated information by definition, because nothing downstream can see it change.
The digital thread argument points the same direction. In 2024, a Tech-Clarity survey for Razorleaf found two-thirds of manufacturers rate integrating data across the product digital thread as important or critical, while most still lack fully integrated systems. A partial migration builds a permanent break into the thread at the exact point where the organization’s oldest, most proven designs sit. For more on why that record matters more than the software holding it, see our perspective on where product truth actually lives.
“Always be migrating” is a symptom
Some organizations have gone further and built a permanent migration function, complete with its own team and tooling, on the assumption that data will be moving between systems indefinitely. That infrastructure usually exists because previous migrations were partial. Each one left data behind, so each one required a follow-up, and eventually the follow-ups became a department.
The instinct to keep it is understandable. A standing migration team looks like capability, and it does remove one piece of work from the program. But its existence is evidence of the problem, not a reason to repeat it. When the tooling turns out not to fit the new platform’s configuration, which is common, the program is back to building the migration from scratch anyway, now with an organizational commitment to doing it again later. The goal of a migration is to stop migrating. One complete move, one system of record, and a legacy environment that can be switched off rather than nursed along.
What the tool can and cannot promise
Full migration is a commitment, and the plan has to be honest about where the target platform falls short. Every PLM has gaps against a mature legacy environment, and a customer who has spent years adding capabilities to their old system will find features the new one does not have out of the box.
Most of those gaps close with configuration. Some require building. What none of them justify is leaving the data behind, because the data is the asset. A missing feature is a project. A missing product record is a loss. Our note on de-risking a PLM initiative before it starts covers the readiness questions that surface these gaps early, while there is still budget to close them.
Making the PLM migration case before the decision is made for you
Partial migration decisions tend to get made at the working level, by whoever owns the migration tooling, without ever being escalated to the people who will live with the consequences. End users have plenty of reasons they need the legacy data. Nobody carries those reasons up the chain, so the default wins.
The job of a migration partner in that moment is to force the decision into the open. That means a presentation with numbers in it: what a partial migration saves, what it costs across the life of the platform, and what it means the next time a twenty-year-old product comes back for work. Leadership may still decide to leave data behind. That is their call. But it should be a decision they made with the trade-offs in front of them, rather than a default that happened because nobody asked.
Frequently asked questions
Should you migrate all data when moving to a new PLM?
Yes, with narrow exceptions for records that cannot exist natively in the target, such as workflow and approval histories, which should be captured as attached reports. Everything with a product relationship should move. In 2018, Experian found only 36% of migrations held budget, which is why scope cuts are tempting, but leaving data behind creates a permanent second system of record.
What happens to legacy PLM data that is not migrated?
It ends up in one of three places: a legacy system left running, a bare database, or a data warehouse. Each requires rebuilding the search, relationships, and reporting the old PLM provided. The GAO found in 2025 that 79% of federal IT spending goes to maintaining existing systems, with seven of eleven critical legacy systems carrying vulnerabilities that cannot be fixed.
Why does part reuse depend on full migration?
Reusing an assembly means reusing its bracket, harness, controller, and every relationship between them. A modern PLM copies that structure in one operation. A flat export from a warehouse drops the relationships, so reuse becomes reconstruction. The B-52, planned for 20 years and now flying to 2050 (GAO, 2026), shows how long “closed” designs stay in service.
How do you handle a customer who wants a partial migration?
Build the case and escalate it. Put the lifetime cost of the second system, the reuse and sustainment risk, and the security exposure in front of the leaders who will own the outcome, rather than letting the decision sit with whoever runs the migration tooling. If they still choose partial migration, at least they chose it with the lifetime cost in view.
Is a data warehouse a good home for retired product data?
Rarely. A warehouse holds records, not the where-used logic, configuration structure, or change history that makes product data usable. Tech-Clarity found engineers already spend about a third of their time on non-value-added work, and 20% of their time with outdated information (2014). Records that nothing downstream can see change are outdated by definition.
The bottom line
An organization’s product record is its accumulated engineering judgment. Every part, every relationship, every approval represents a problem somebody already solved.
- Partial migration starts as a small exception and grows into a second system of record.
- In long-lived industries, closed programs come back, and they come back with their brackets, harnesses, and center-of-gravity tables.
- Every alternative to full migration rebuilds a PLM to hold what the new PLM was bought to hold.
- A permanent migration team is a symptom of past partial migrations, not a reason for another.
- The partner’s job is to make the trade-off visible to leadership while there is still time to act on it.
Migrate once, migrate all of it, and switch the old system off. The money saved by doing less is small, and the value lost by doing less is not. If you are planning a consolidation and the scope conversation has already started, our PLM transformation practice can help you build the case while the scope is still open.