Move the Agile product record into Oracle Fusion Cloud PLM without flattening it. Items, revisions, structures, manufacturer parts, AML, attachments and completed change orders load through Oracle’s own FBDI templates and REST resources, in dependency order, with source-to-target reconciliation behind every object.
Agile stores a product as a graph of revision-controlled objects. Export the tables flat and you arrive in Fusion with items that have no history, structures that reference components which do not exist yet, and drawings detached from the revisions they document.
An Agile item is meaningful only alongside its revisions. Attributes, Page Two and Page Three values, the BOM, the Approved Manufacturer List and the attachments can all differ revision by revision. A single extract of current state throws away most of the record, and it is exactly the discarded part that quality and audit will ask for later.
Oracle’s documented path into Fusion Cloud PLM reflects that shape. The item FBDI template carries the latest released revision with its standard attributes, extensible flexfields, AML and attachments. The structure template carries components, substitutes and reference designators for that revision. The change order template then replays completed changes to rebuild the historical revisions and their redlines.
SyntraETL drives all three. Extraction is schema-aware rather than table-by-table, transformation runs from versioned mapping rules, loads are sequenced so dependencies resolve, and DataVault holds the source snapshot, the transformed set and the target result so any record can be traced end to end.
Configured against your Agile instance rather than built from scratch.
Reads the Agile object model through its own relationships: items to revisions, revisions to structures, AML to manufacturer parts, changes to affected objects, files to the vault.
Manufacturer parts before AML, components before parents, attachments before the records that cite them, changes in effective-date order.
Item, item structure and change order templates generated and validated before a single import job runs in Fusion.
Files pulled from the Agile vault, checksummed, staged into the target document store and given stable document identity so revision-specific versions stay distinct.
Counts, control totals and record-level tracing across items, revisions, structures, AML, changes and files.
Every rule is versioned, so rehearsal two runs the same logic as cutover and the difference between them is data, not configuration.
Seven phases, with the trial migration and reconciliation loop repeated until the exception list is empty.
Agile version and configuration, custom subclasses, Page Two and Page Three usage, item and revision counts, structure depth, AML volume, change history and vault size. The output is a scoped object inventory, not an estimate.
Agile classes to Fusion item classes and catalogs, lifecycle phases to statuses, custom attributes to extensible or descriptive flexfields, and an explicit decision for every attribute with no natural target home.
Full extract to a governed staging layer with a signed source snapshot in DataVault, so later cycles compare against a fixed baseline rather than a moving source.
FBDI generation, import jobs run in a Fusion test pod, dependency failures resolved, performance tuned against real volumes rather than a sample.
Source-to-target comparison by object, business validation of representative products, and exception remediation fed back into the mapping rules.
Delta or final extract, sequenced load, reconciliation pack produced and signed, legacy history frozen.
Retained history published to the archive for search and reporting, then the Agile environment is retired.
Fusion Cloud PLM is loaded through a small number of file-based templates and REST resources rather than through a single generic interface, and each one covers a defined slice of the product record. Knowing which slice goes where is what turns a mapping document into a load plan.
The three templates below carry the core of an Agile migration between them. Their interface sheets accept revision-specific state, which is what makes historical revisions and redlines recoverable rather than collapsed into current state.
What organisations actually choose between, and what each costs them.
Works for a pilot of a few hundred items. At production scale the effort is in the rework: no reconciliation, no lineage, and every failed cycle starts from a fresh export.
Fast to start and expensive to keep. Mapping logic ends up spread across scripts nobody owns, and rehearsal three rarely runs the same code as rehearsal one.
Extraction, mapping, FBDI generation, attachment handling and reconciliation as one governed pipeline, versioned so every cycle is reproducible and every record is traceable.
In four movements. Extraction reads the Agile object model through its own relationships rather than table by table, so items stay attached to revisions, revisions to structures and AML, and files to the objects that cite them. Transformation applies versioned mapping rules covering class mapping, lifecycle and status mapping, Page Two and Page Three resolution, item number rules, manufacturer normalisation and effectivity adjustment. Generation produces Oracle's own FBDI payloads, principally the item, item structure and change order templates, or REST payloads where a REST resource fits the object better. Loading runs the Fusion import jobs in dependency order, captures rejections as exceptions rather than silent losses, and reconciles the result against the source snapshot held in DataVault.
Oracle's import processes cover items with their standard attributes and extensible flexfields, item revisions with effectivity, Approved Manufacturer List entries, structure entities including components, substitutes and reference designators, item attachments, and completed change orders carrying redlines. That is the core of a product record and it is what the page is structured around. Objects outside that set, and custom classes specific to your instance, are handled case by case during design rather than assumed to map one to one.
Twelve to twenty-four weeks is the usual range for a single Agile instance, driven far more by data condition and attachment volume than by item count. What stretches a programme is custom subclass discovery, Page Two and Page Three fields whose business meaning nobody documented, duplicate manufacturer records accumulated over a decade, and multi-terabyte vaults. All four surface in profiling, which is why discovery comes first and why the estimate after profiling is worth more than the estimate before it.
They can, subject to agreed scope. Oracle's change order import is the mechanism: completed changes are replayed in effective-date order, oldest first, and each carries the revision-specific attribute, AML, structure and attachment state behind it. Effectivity ranges cannot overlap in the target, so overlapping ranges in the Agile source are resolved during transformation rather than discovered when the import job rejects them.
It goes to the archive. Most programmes move current operational product information into Fusion and retain superseded revisions, closed changes, retired products and their documents in SyntraETL DataVault, where they stay searchable with relationships intact. That keeps the new PLM clean without losing the record, and it is usually cheaper than carrying a decade of history into a cloud system you pay to hold it in.
Through the reconciliation pack. Aggregate reconciliation compares counts and control totals for items, revisions, BOM headers and components, manufacturer parts, AML relationships, change orders and attachments across source, transformed and target stages. Record-level reconciliation traces an individual part number from its Agile source row through transformation to the Fusion record. Exceptions list every object that did not land and why. The pack is the evidence an audit committee signs, not a screenshot of a successful import job.
Book a 30-minute discovery call. We will walk through your Agile version, item and revision counts, structure depth, AML volume, change history and vault size, and give you a scoped object inventory and an indicative timeline.