The long PLM interim: one part, two systems of record, no cut-over date

A European mechatronics group is replacing the system that has held its engineering data for two decades - and the hardest part is not the new platform. It is the years in which both platforms are live at the same time. This group prepared the programme by the book, and still walked into it. Almost everyone who migrates engineering data does.

One platform, several engineering cultures, and a librarian nobody can switch off

The group brings together multiple industrial activities with historically distinct engineering cultures, processes and specialised toolsets. Each grew its own design methods, its own CAD environment, its own reference data. For years, product data has been held by an in-house PDM system - effectively a technical librarian for CAD models and drawings - sitting alongside SAP.

The organisation is now deploying a unified, highly adaptable PLM platform to standardise product data management across the entire business. The ambition is the full V-cycle: customer and product requirements, system architecture, verification and validation, engineering and manufacturing bills of material, and a clean interface to the ERP. The governance is exemplary - an independent engineering-systems consultancy brought in early to challenge the requirement and set the target architecture, a specialist integrator for the configuration, agile sprints with measured velocity, and a business referent for each engineering community so that none of them drifts away from the common model. A first release is weeks away.

The programme is working. What it has also exposed is the part of the map nobody drew: the state the company will actually live in for the next several years.

Failure point #1

You cannot big-bang an engineering-data migration

An ERP cut-over can be a long weekend. Freeze the transactions on Friday, load the new core, open on Monday, live with a rough fortnight. Engineering data does not behave that way. A part is not a row - it is a native CAD model with revisions, links to other models, a drawing, a change history, and a place in assemblies that are still being built and sold today. The volume and the technical depth of that data make a clean break impossible.

So the group is doing what every engineering organisation ends up doing: running a bidirectional master-slave replication between the old PDM and the new PLM, and moving product ranges across one at a time. Not for a weekend. For months running into years.

Which quietly makes the interim the real architecture. In it, authority over an object is decided by a date. A part created before its range moved is mastered in the old PDM and replicated into the PLM. A part created after is mastered in the PLM and replicated back. Both statements are correct. The rule that decides which one applies exists in no system at all.

The moment it bites is reuse - and reuse is the whole point of a PLM. A new assembly picks up a component designed a decade ago. That component sits on the legacy side; the assembly is being built on the new side. Which revision is the good one? Which change process governs it? Answer wrong and you release a product against a superseded definition. Ask the two catalogues and both answer with confidence.

An ERP migration is a weekend. An engineering-data migration is an era.

Failure point #2

When a data flow breaks, the first job is finding out whose it is

Count the parties standing on the technical chain between a CAD model and an ERP material: the platform publisher, the supplier of the third-party CAD connectors, the integrator doing the configuration, the consultancy holding the target architecture, internal IT, and the business referents on the operating side. Six organisations, each competent, each responsible for its own component.

Now break one flow. Is the defect in the PLM core, in the CAD connector, in the configuration model, or in the internal setup? Nobody can say from the symptom. So diagnosis happens by elimination, across organisational boundaries, and each boundary has its own ticketing system - an internal tool on one side, a supplier portal on the other, no shared state, no shared clock. The elapsed time on a defect is mostly the time it spends being handed back.

This is not a failure of any supplier. It is structural, and it is worth naming plainly: in a landscape assembled project by project, every party owns a box and nobody owns what runs between the boxes. Integration is treated as a by-product of whichever project needed it last - so it has no owner, no roadmap, no test suite and no lifecycle of its own.

Every supplier owns a box. Nobody owns the arrows.

Failure point #3

Configurable is not the same as architected

The platform was chosen for its openness, and it delivers exactly that. The price of a blank sheet, though, is that you have to fill it. Every object state, every transition, every approval scheme, every lifecycle - the life of a requirement, the anatomy of a change - has to be specified from scratch, in a business that never had to write those rules down before. The team’s own word for it is the feeling of reinventing something that ought to come as standard. Functions that look trivial from the outside take months of configuration and testing.

Access rights are where this bites hardest. Several engineering communities, sites in Europe and Asia, and projects that cut across them: four to five layers of security, around twenty roles, and conditional rules on top - a part attached to a cross-divisional project overrides the restrictions that would otherwise apply to it. Modelling that consumed far more hours and far more testing than anyone forecast, and it still produces errors when new objects are instantiated.

None of that effort is wasted - deciding how your business defines a part, a change and a release is real intellectual work, and it survives version upgrades better than custom code would. But notice where it is being written down. The company’s data model is being encoded as the configuration of one vendor’s platform. It cannot be reused on the ERP side, it cannot govern the legacy PDM during the interim, and it does not travel to whatever comes after.

What the target actually asks for

Ten prices, and only one of them is useful here

The target picture is clear and, in this sector, unremarkable: an unbroken digital thread from customer requirement to final validation; an automated two-way link between the PLM that defines product and process, the ERP that runs purchasing, logistics and cost, and the MES that drives the shop floor; mechanical, electronic and embedded-software design in one place; and useful context surfaced to the engineer - what a part actually costs, whether its qualification test passed - without adding a single field for anyone to fill in.

That last ambition produces the question that decides the whole architecture. SAP holds something like ten different price types for a part. Which one belongs in the PLM? Standard cost? Last purchase price? Planned price for the coming period? Every answer is right for one department and misleading for another - and every answer that involves copying the number is wrong again within a day.

The same question returns for test status held in an in-house qualification database, and again for change: the change process in the PLM and the change orders in the ERP have to line up, and today the bridge between them is still partly a human being.

The problem in one image
A library moving to a new building, one shelf at a time, over years. Both buildings are open. Both catalogues are accurate about their own shelves and wrong about the other’s. Whether a book is in the old wing or the new one depends on when it arrived - and that rule was never written into either catalogue. It lives with the people doing the moving. Ask the catalogue and you get a confident answer. Ask the reader who walked to the wrong building and you get the truth.

The way out

Not a better bridge between two systems - a layer above both

The instinct is to strengthen the replication between the old PDM and the new PLM, then harden the gateway to the ERP, then build a good one to the MES when it arrives. That is the classic n×m problem, rebuilt one project at a time: every new system multiplies the wiring, every platform upgrade threatens it, and when the legacy PDM is finally switched off, the bridges built for the interim are thrown away with it. Years of work, deliberately disposable.

The alternative is to put one integration layer above the systems, owned by the business rather than by any project, doing five jobs:

• One definition of the part, above both systems of record. The legacy PDM keeps its codes, the new PLM keeps its own, and the layer maps them to a single business-level definition. The date rule stops being tribal knowledge and becomes part of the model - readable, testable, and the same for everyone.
• Link, don’t copy. The ten prices stay in SAP. The layer references the one that is meaningful in that context, live, at the moment the engineer looks. Nothing is replicated into the PLM, so nothing goes stale, and the question changes from “which price do we copy?” to “which price do we mean here?”
• Treat time as its own dimension. A landscape mid-migration is a landscape whose structures keep changing. Recording when a definition, a master or a hierarchy changed is what lets an assembly from ten years ago still be read against the structures of ten years ago - instead of being silently reinterpreted by today’s model.
• Connect once, not n×m. CAD, the legacy PDM, the PLM, SAP and the test database each connect once to the layer, not to each other. When the MES arrives it joins the model rather than the wiring - and the interim connections stop being throwaway work.
• Give the flow an owner. Integration becomes a thing with a lifecycle - versioned, tested, documented, owned - rather than a by-product of the last project that needed it. Responsibility drawn around the flow, not around the boxes, is what ends the handing-back.

Nothing here replaces the PLM programme, and nothing gets migrated to make it work. The systems stay exactly where they are; the layer sits above them and starts small - one object, the part, and one flow. The rest grows by need.

What it changes

Half the programme, and a working scope in months

The difference is not architectural elegance. It is calendar time. Wiring systems to each other one project at a time is exactly what turns integration into a decade of work: each new system multiplies the links, each platform upgrade puts them at risk, and the bridges built for the interim are thrown away when the legacy system is finally switched off. Connecting each system once, to a layer that holds the model, removes most of that work before it is ever created.

In comparable landscapes the pattern is consistent. An integration roadmap that would otherwise run for the better part of a decade compresses to roughly half of that - and a first working scope goes live in months, instead of the two to three years a platform-by-platform build needs before anything is usable. The reason is not speed of delivery but sequence: the first object you model is useful on its own, before the second system is connected. These are orders of magnitude from similar programmes, not a forecast for any particular landscape.

This is the work boTec does. Thirty years in the process and production industries, more than a hundred ready-built connectors, and an engagement that starts with your business model rather than with our software: the DataBridge is the layer, and the project is building the model on it together with your own people. Your PLM programme carries on. Your ERP stays where it is. Nothing is migrated to make the foundation work - and both the data and the model remain exportable, so the foundation never becomes the next thing you are locked into.

The interim is not a phase to be endured. For several years, it is the architecture you actually run.

The lesson travels

Four signs your interim has quietly become permanent

The detail here comes from mechatronics, but the shape is the same wherever a core system is being replaced - chemicals, pharma, energy, machinery, food and beverage. Whenever the object is too heavy to move in a weekend, a long coexistence follows, and the same four signs show up in it:

• Two systems of record for the same object, with authority decided by a date rather than by a rule anyone can read.
• Broken data flows diagnosed by elimination across three or more suppliers, in three or more ticketing systems.
• Integration logic that exists only inside one platform’s configuration - and therefore cannot govern the system you are leaving, or the one you will buy next.
• A target architecture with no drawing of the interim beside it - the state you will live in longest is the one nobody designed.

The way through is not to force the interim to be shorter. It is to stop treating it as a temporary inconvenience and give it a model: one definition of one critical object, held above the systems that store it, so the old system can be switched off without ceremony and the new one replaced one day without drama. A foundation that outlives the platforms underneath it is exactly what the boTec DataBridge is built to be.