Leaving Duro

What comes across cleanly

Duro models components, assemblies and revisions in a way that maps onto Manufacturing PLM's object model without violence, which is not true of every source system.

• Components and their attributes, including the category-driven specification fields, which land on classification attributes here rather than as free text.
• Assemblies and their structure, with quantities and reference designators intact. Designators survive because both systems model them as line-level data rather than as a note.
• Revisions with their history, including who released what and when. The dates and actors come across as recorded history rather than being flattened to an import timestamp.
• The component library's manufacturer entries, which become AML entries — subject to the duplicate decision described below.

The three decisions

How much history. Everything is possible and rarely correct. The useful question is what you would need to answer about a product you shipped four years ago, and for most teams that is released revisions and their approvals rather than every intermediate working state. Bringing everything means bringing every abandoned draft, which makes search worse permanently.

What to do about library duplicates. Every component library accumulates them — the same part entered twice under different manufacturer part number spellings. Import is the one moment when merging them is cheap, because nothing downstream has been built yet. Manufacturing PLM proposes matches on classification attributes with the differences named, and a person accepts or rejects each one.

Who owns identity afterwards. Duro issues part numbers. So can Manufacturing PLM, and so can your ERP. This has to be decided before the run rather than discovered during it, because the answer determines whether numbers are carried across as-is or reissued — and reissuing after go-live is a change to every reference in every system.

The failure this avoids

A team migrates everything, resolves nothing, and goes live in a fortnight. The speed is real and so is the cost, which arrives about four months later.

The library duplicates came across as duplicates. Where-used now returns partial answers, an obsolescence check misses a product, and the fix requires merging items that four months of structures now reference. What would have been a review of two hundred proposed matches before go-live becomes a structural change with an impact analysis attached to each one.

Migration is the only cheap moment to fix data quality. Everything is provisional until go-live and permanent afterwards, and a fortnight spent on the duplicate review is the highest-return work in the whole project.

How the run actually works

Extraction runs against Duro's API rather than against a file export, which means the run is repeatable. That matters more than it sounds: a migration is never one run, it is five or six, each one revealing something the last did not.

Every run is a dry run until you say otherwise, and it produces a report rather than a tenant — counts by object type, proposed merges, and errors that name the specific record and field rather than reporting a total. An error that says forty-one records failed validation is not a report, it is a rumour.

Runs land in a sandbox first, always. You look at your own data in the real product, run the queries you actually care about, and find the things a report cannot tell you — usually a classification that felt right in the mapping spreadsheet and is wrong when you search with it.

There is no mandatory services engagement. Migration is a product feature with a documented mapping, not a consulting deliverable, and a team that wants to run it themselves can.

How it meets your ERP

If your ERP already holds items for the same parts, the migration is where identity gets reconciled, and it is worth doing then rather than later. Imported items are matched against the ERP item master and the matches are proposed rather than applied.

That matching produces the most valuable artefact of the whole project: a list of parts that exist in one system and not the other. Most teams have never seen that list, and it is usually longer and more interesting than anybody expects.

The system-of-record matrix is decided as part of the migration rather than after it. Which system issues numbers, which owns cost, which owns the MBOM — answered before the first publication rather than discovered when two systems disagree.

Where the boundary is

Nothing is imported silently. Every proposed merge, every identity match and every classification mapping is reviewable before it is applied, and the review is the work rather than an optional step.

Manufacturing PLM also does not migrate what it cannot model faithfully. Where a Duro concept has no honest equivalent here, the import reports it rather than approximating it into the nearest field, because an approximation that looks like data is worse than a gap somebody can see.