Leaving Arena
Arena exports cleanly, which removes the usual first obstacle. What remains is three decisions — how much history, what to do about duplicates, and who owns identity afterwards — and none of them are about file formats.
What comes across cleanly
Arena's data model is close enough to Manufacturing PLM's that most of the mapping is mechanical rather than interpretive, which is the main reason this path is a named one rather than a generic CSV import.
Items map to parts with their attributes and classification. Bills of materials map to structures with quantities and reference designators intact. Documents and their revisions map into the vault. Suppliers and approved manufacturer entries map to the supplier and AML model. Change records map to change objects with their affected items and approvals.
Revisions map, and this is the part that matters most. Arena distinguishes released revisions from working ones, so the released history survives — which means the question a PLM exists to answer, what a unit shipped with, remains answerable after the move.
What needs a decision
Effectivity. Arena's model is date-oriented. Where an effective date was recorded on a change it maps directly; where a phased cutover was managed by a note in a description, somebody has to decide what it meant. That is engineering judgement, not a mapping rule, and it is the single most common thing this migration surfaces.
Custom fields. Attributes that were added over the years carry meaning nobody has written down. The mapping stage reports every unmapped field rather than dropping it silently, because the one you have never heard of is reliably the one somebody depends on.
Duplicates. Every migration surfaces more than expected. Import them, surface them as candidates with evidence, and consolidate afterwards through change control — where a consolidation has an impact set, an approver and a rollback. Merging during import is irreversible in a way importing is not.
The failure this avoids
The common way this goes wrong has nothing to do with Arena. A team exports, imports, and discovers at cutover that the new system holds a parallel item master — because identity was reconciled with the ERP afterwards rather than during.
Now there are two numbers for the same physical part in two systems, purchasing is transacting against one and engineering is designing against the other, and untangling it takes a quarter of somebody's attention. The migration technically succeeded.
Matching identity on the way in — manufacturer part number first, internal number second, unmatched surfaced for a person — converts that quarter into a finite list worked through before go-live. It also forces the ownership conversation at the right time.
How the run actually works
Five stages, and nothing commits until the last one. Extract through the Arena-specific path. Map fields to types, with unmapped fields reported. Validate against the target model, with errors naming rows: not “4,412 errors” but “row 4,412, part 510-0090, quantity 8 EA in a numeric column, three reference designators listed”.
Deduplicate on manufacturer part number then internal number, never on description similarity. Commit as one transaction — the run lands completely or not at all, and the whole run reverses in one action afterwards.
Rehearse it at least twice into a sandbox, reviewed by the people who will use the result, then run a delta close to cutover. The data changes little between rehearsals; the mappings and the duplicate decisions change a great deal, and that is the rehearsal doing its job.
How it meets your ERP
If Arena was already integrated with your ERP, the integration is where most of the institutional knowledge lives — which fields sync, in which direction, and what somebody decided years ago about the part number.
So the first artefact of this migration is the system-of-record matrix: object by object, which system masters the field, which direction it moves, what triggers it, and what happens on conflict. That is published per connector rather than discovered during implementation, and filling it in is how the existing arrangement gets written down before it is replaced.
Item identity matching runs against your live ERP during the import, not against the Arena export. Items originating in purchasing or sales — packaging, freight, consumables, services — keep their ERP identity rather than being pulled into engineering's namespace.
Where the boundary is
Some of what Arena does, Manufacturing PLM does not. FDA design controls with a device history file, ISO 14971 risk management, formulation and recipe management, and artwork or label control are out of scope — not roadmap items. If you rely on any of them, this migration is the wrong project and we would rather say so before you export anything.
There is also no automatic reconstruction of things Arena did not record structurally. A phased cutover managed in a description field becomes structured effectivity only when a person decides what it meant.
And nothing here reconstructs relationships that only ever lived in prose. A part connected to a requirement by a sentence in a specification is not a relationship any extraction can find; it becomes one when somebody records it as an object, which is work worth doing but not work a migration can do for you.
Facts
| Path | Named and Arena-specific — not a generic CSV import |
| Maps cleanly | Items · BOMs · documents · suppliers · AML · changes |
| Released revisions | Survive — the history question stays answerable |
| Needs judgement | Effectivity recorded as prose · custom field meaning |
| Errors | Name rows, never a count |
| Duplicates | Imported and surfaced; consolidated through change control |
| ERP identity | Matched during the import, not reconciled after |
| Services | Optional and fixed-scope — never mandatory |
| Out of scope | Design controls · DHF · formulation · artwork |
Frequently asked
Will we keep our revision history?
Yes, for released revisions and the changes that produced them — which is what keeps the what-did-this-unit-ship-with question answerable afterwards. Arena already distinguishes released revisions from working ones, so that distinction survives the move rather than being flattened into a single version field on import.
What happens to our custom fields?
Every unmapped field is reported rather than dropped silently. Attributes added over years carry meaning nobody wrote down, and the one you have never heard of is reliably the one somebody depends on. You decide what maps and what is deliberately left behind.
Do we need to clean up duplicates first?
No, and you should not try. Import them, let the system surface them as candidates with evidence, and consolidate afterwards through change control where each merge has an impact set and a rollback. Merging during import is irreversible in a way importing is not.
How long does it take?
Weeks rather than quarters for a single product line, and the long pole is decisions rather than data movement. Rehearse twice into a sandbox with the people who will use it, then run a delta close to cutover so the gap is days rather than months.
Do we have to buy professional services?
No. Migration is built as product rather than sold as an engagement, and most teams complete it without help. Where you do want assistance it is a fixed-scope, optional quote rather than a line item that appears after the contract is signed.
What about our Arena to ERP integration?
That is where the institutional knowledge lives, so the first artefact is the system-of-record matrix: which system masters each field, which direction, and what happens on conflict. Filling it in documents the existing arrangement before it gets replaced by a new one.
Is there anything Arena does that you do not?
Yes. FDA design controls with a device history file, ISO 14971 risk management, formulation and recipe management, and artwork or label control are all out of scope rather than planned. If you depend on any of them, this is the wrong project.