Leaving Fusion Manage

Data is the easy half

Items, bills of materials, changes and attachments extract through the API and map onto Manufacturing PLM's object model with ordinary effort. Workspaces become object types, picklists become typed attributes, and BOM views become structure resolutions.

The half that takes the time is that a mature Fusion Manage tenant is not really a data set. It is an application somebody built — configured workspaces, scripted behaviours, calculated fields and workflow transitions that together encode how the company works.

Much of that process was never written down anywhere else. It exists as configuration, and the person who configured it has frequently moved on. Migrating the data without recovering the intent produces a tenant that holds everything and behaves like nothing.

So the first real task is not extraction. It is reading the existing configuration and asking, for each piece, whether it encodes a genuine rule of the business or an accommodation to a limitation that no longer applies.

The three decisions

Which scripted behaviour is a rule. Fusion Manage scripts do everything from field validation to cross-workspace updates. The validation becomes a declarative rule here; the cross-workspace updating usually turns out to be a data model that wanted normalising. Re-implementing scripts as scripts is the failure mode, and Manufacturing PLM deliberately has no scripting to make it available.

How many object types you actually need. Configurable systems accumulate workspaces, and a tenant with forty is common while a business genuinely distinct in forty ways is not. Migration is the moment to consolidate — but consolidating something that is genuinely distinct is worse than carrying it across, so this is a per-type conversation rather than a target number.

What to do with calculated fields. A stored calculated value is a resolution frozen at a moment. Here, most become live resolutions and stop being stored at all, which is better — but it changes what a report reading that field will see, and downstream consumers have to be found before go-live rather than after.

The failure this avoids

A team migrates by replicating its Fusion Manage configuration as closely as the new system permits. Every workspace becomes an object type, every script becomes a rule or a workaround, and the result is faithful.

It is also a reproduction of eight years of accumulated accommodation. A validation that exists because a 2019 integration needed a field populated. A workspace that exists because two teams could not agree on a naming convention. A calculated field nobody has been able to explain since 2022.

Faithful replication carries the debt across intact, and the moment to shed it is the only moment when nothing has been built on top of the new arrangement yet. A migration that questions nothing has spent the budget and kept the problem.

How the run actually works

Extraction is API-based and repeatable, and a configuration audit runs alongside it — an inventory of workspaces, scripts, calculated fields and transitions, each annotated with how much it is actually used. Usage data settles arguments that opinion cannot.

That inventory is the working document for the three decisions. A workspace with four hundred records and daily activity is a different conversation from one with eleven records last touched in 2021, and both exist in every mature tenant.

Runs are dry runs producing reports, land in a sandbox first, and report errors that name the record and the field. The sandbox stage matters more here than in most migrations because the questions are behavioural — does this workflow feel right, does this consolidation lose something — and those cannot be answered from a report.

There is no mandatory services engagement, though this is the migration where teams most often want help, because the configuration archaeology benefits from somebody who has done it before.

How it meets your ERP

Fusion Manage tenants frequently carry an ERP integration built over years, and its behaviour is often the least documented thing in the estate. Reading what it actually publishes, rather than what it was designed to publish, is part of the audit.

The system-of-record matrix is rebuilt explicitly during migration. Most mature tenants have an implicit one that nobody has written down, and reconstructing it from integration behaviour is genuinely useful work regardless of which PLM you end up on.

Imported items are matched against the ERP item master with matches proposed rather than applied, and the list of parts existing in one system and not the other is produced as an artefact — usually longer and more interesting than anyone expects.

Where the boundary is

Scripts do not come across, because there is nowhere for them to go. Manufacturing PLM has declarative rules and no scripting language, deliberately. Behaviour that cannot be expressed declaratively belongs in the connector SDK or an agent evaluation, and some of it turns out not to be needed at all.

Manufacturing PLM also does not approximate. Where a Fusion Manage concept has no honest equivalent, the import reports it rather than mapping it into the nearest available field, because a value in a field it does not belong in is a defect that outlives everyone involved.