Fusion Cloud PLM is Oracle’s path forward for Agile customers, and for most it is the right destination. The decision that matters more is not which platform but how much of thirty years of engineering history goes into it.
Oracle has said Premier Support for Agile PLM ends after December 2027. That is a support milestone rather than a shutdown, but it makes the direction explicit and it puts a planning horizon on a decision most Agile customers were already circling.
Four options exist in practice: stay on Agile without Premier Support, buy third-party support, move to Oracle Fusion Cloud PLM, or move to a different PLM platform. For organisations already invested in Oracle, Fusion is the natural destination, and Oracle documents import paths for the core of a product record: items, revisions, manufacturer parts, AML, structures, attachments and change orders.
But the platform question is the easier half. The expensive half is how much history follows. Carrying every superseded revision, closed change and retired product into a cloud PLM costs licensing, extends the programme and slows the system for every user afterwards. Most organisations are better served moving current operational product information and preserving the rest in an archive that stays searchable.
Whichever destination is chosen, the data work is broadly the same: extraction that preserves relationships, versioned mapping, dependency-ordered loading, attachment handling, and reconciliation that proves the result. Only the target format changes.
The differences that matter operationally, beyond the platform badge.
Quarterly updates rather than upgrade projects, and no application or database estate of your own to patch.
Product data alongside the rest of the Oracle Cloud estate, rather than integrated to it through interfaces you maintain.
Only the history that has a purpose moves, so the new system is not born carrying thirty years of accumulated noise.
What does not move stays searchable in the archive, which is usually faster to query than the old system was.
Security fixes and support continue, which an unsupported Agile instance on your network stops receiving.
Subscription in place of licences, servers, storage, backup and the specialist effort behind them.
Six to nine months for a single instance, most of it before any data moves.
Fusion Cloud PLM against the alternatives, judged on fit, existing Oracle investment and the documented import path for your object mix.
Profile the Agile instance: configuration, volumes, flex-field usage, data condition and vault size, measured rather than estimated.
Agree what migrates and what is archived, with volumes on each side, and record it so it is not reopened mid-build.
Mapping, extraction, trial migrations, reconciliation and a rehearsed cutover, in that order and more than once.
Preserve the remainder with evidence, stand up access, prove it during a parallel run, then decommission Agile.
For most Agile customers Fusion Cloud PLM is the natural answer, and for some it is not. The difference is usually visible from six questions asked early, before a platform decision hardens.
Working through them honestly is cheaper than discovering the answer during a mapping phase.
What each one means in practice.
The software keeps running and stops receiving fixes. Viable briefly, progressively harder to defend to an auditor.
Buys time and does not change the destination. Useful when the migration cannot start yet, not as an answer in itself.
Oracle's documented path, with import processes for items, revisions, manufacturer parts, AML, structures, attachments and changes.
For most Agile customers, particularly those already running Oracle applications elsewhere, Fusion Cloud PLM is the natural destination: it is Oracle's forward path for Agile and it has documented import processes for items, revisions, manufacturer parts, AML, structures, attachments and change orders. That said, the right answer depends on your product complexity, your existing estate and how well your object mix maps to the Fusion model, and there are cases where a different PLM platform fits better. We would rather help you test that than assume it.
Agile PLM keeps functioning. What stops is Premier Support, meaning no further patches, fixes or Oracle support coverage. The practical consequence is that an unsupported application and its database continue to sit on your network without security updates, which becomes progressively harder to justify to auditors, insurers and your own security function. It is a risk that grows over time rather than an event on a date.
Less than most organisations first assume. Current released revisions, live structures, current approved sources and open changes need to be in the operational system. Superseded revisions, closed changes, retired products and their documents generally do not, and carrying them costs cloud licensing, extends the programme and slows the new system daily. The usual pattern is a smaller migration paired with a larger archive that answers historical questions for a fraction of the cost.
Yes, and the data work is substantially the same. Extraction that preserves relationships, profiling, versioned mapping, dependency-ordered loading, attachment handling and reconciliation apply regardless of destination; what changes is the target format and the specific object model being mapped into. SyntraETL is not tied to Fusion as a target, and where another platform is the better fit we would rather say so than push the Oracle path.
Six to nine months from decision to decommissioning for a single instance, of which the technical migration is twelve to twenty-four weeks. The remainder is the decisions: destination, the migrate-or-archive boundary, flex-field meanings, retention obligations and item numbering. Larger estates with several Agile instances or heavily customised configurations run longer, and profiling is what turns that range into a date.
It is archived and then decommissioned. The history that did not migrate is preserved with its relationships intact and made searchable, completeness is proved through reconciliation against the source, and users answer real enquiries from the archive during a parallel run while Agile is still available. Only then are access, application servers, database, vault storage, backup, DR and licences withdrawn, in that order.
Book a call. We will work through the destination decision, how much history genuinely needs to move, and what the programme and the archive would each cost against your own instance.