Few manufacturers move every product line on one weekend. While some sit in Agile and others in Fusion Cloud PLM, the two have to agree about items, structures and change status — without anyone maintaining the same part twice.
Phased migration is the sensible choice for a large product portfolio. It also creates a window, often a year or more, where the product record is split across two systems and both are live.
During that window a component may be shared between a product line that has moved and one that has not. A manufacturer part approved in Fusion needs to be visible to engineers still working in Agile. A change raised in one system affects items whose master now sits in the other. Left unmanaged, the two records diverge quietly and the divergence is discovered at the worst possible moment, which is the next cutover.
Integration closes the gap, but only if ownership is explicit. Every object family needs a designated master for the period, and the rule has to be enforced by the integration rather than remembered by users. Shared components are the hard case and usually need a single owner with read-only propagation to the other side.
Synchronisation runs scheduled or event-driven depending on how quickly the two sides need to agree, with conflicts surfaced as exceptions rather than resolved silently by last-write-wins.
Coexistence fails on governance more often than on technology.
One master per object family, enforced by the integration rather than by convention, with the rule written down before go-live.
Near-real-time where procurement or production depend on it, batched where a daily position is sufficient.
Simultaneous changes on both sides raised as exceptions with the competing values shown, not silently resolved by whichever wrote last.
A maintained mapping between Agile and Fusion identifiers, so renumbered items remain traceable across both.
Periodic comparison of the shared set, so drift is detected while it is small.
The integration is temporary. Its retirement is planned alongside the final cutover, not left running because nobody owns switching it off.
Governance first, because the technical build depends on the decisions.
Which items, structures, manufacturer parts and changes are genuinely shared across the boundary. It is usually smaller than the first estimate.
One master per object family for the transition, agreed with engineering and procurement and written down.
Identity mapping between Agile and Fusion, which has to survive item renumbering to be useful.
Scheduled or event-driven flows per object family, with conflict detection and exception routing in place from the start.
Continuous reconciliation of the shared set while the transition runs, then planned decommissioning of the integration at final cutover.
The shared set is almost always smaller than the first estimate, and narrowing it is the highest-value hour in a coexistence design. Every object family kept in scope adds synchronisation, conflict handling and reconciliation.
Work through these six questions before building anything, and the integration usually shrinks to something modest.
Three approaches to the same window.
Engineers keep both systems updated by hand. Works for weeks, fails quietly for months, and the divergence surfaces at cutover.
A full re-push on a schedule. Simple to build, slow to reflect change, and it overwrites legitimate edits on the receiving side.
Ownership rules, identity crosswalk, conflict surfacing and continuous reconciliation, with a planned end date.
Because phased migration creates a coexistence window, often a year or more, in which the product record is genuinely split. Product lines that have moved to Fusion frequently share components, manufacturer parts and approved sources with lines still in Agile. Without integration those shared objects diverge, and the divergence is normally discovered during the next cutover, which is the most expensive moment to find it.
It depends on ownership, and ownership is decided per object family rather than globally. A common pattern makes Fusion the master for items already migrated, with read-only propagation back to Agile so engineers still working there see the current state, while Agile remains master for product lines not yet moved. Bi-directional flows are used sparingly, because every bi-directional object family adds a class of conflict that somebody has to adjudicate.
They are surfaced, not silently resolved. If the same object changes on both sides between synchronisation runs, the integration raises an exception showing both competing values and the timestamps, and routes it to the owning team. Last-write-wins is deliberately avoided for product data: silently discarding an engineering change because another system wrote a second later is exactly the failure mode that destroys trust in the integration.
It adds build effort at the start and removes risk throughout, which is usually a good trade for a phased programme. What it genuinely prevents is the compounding divergence that makes each successive cutover harder than the last. For a single big-bang migration with no coexistence window it is unnecessary, and we would say so.
It is decommissioned, and that is planned from the start rather than decided later. Interim integrations that outlive their purpose become permanent infrastructure by accident: they keep running, they keep needing maintenance, and they quietly justify keeping the legacy system alive to feed them. The retirement of the integration is scheduled alongside the final cutover and the archive replaces whatever read access it was providing.
Yes, through the identity crosswalk, and this is precisely why the crosswalk exists as a maintained artefact rather than a one-off mapping file. Where item numbers change during migration, the crosswalk holds the Agile identifier against the Fusion identifier so synchronisation, reconciliation and later historical enquiries all resolve correctly. Without it, a renumbering exercise makes the two records permanently unmatchable.
Tell us how the phasing is structured and which components are shared. We will map the coexistence risk and propose ownership rules and synchronisation flows per object family.