Moving to Oracle Cloud PLM with only today’s data is like upgrading your phone and skipping the backup: everything works, but your history is gone. For manufacturers leaving Oracle Agile PLM, that history is the engineering record auditors ask for. The way to keep it is to load each item and its latest BOM into Oracle Fusion Cloud PLM first, then rebuild earlier revisions through change orders in date order. This point of view sets out why Agile PLM history deserves proper migration, how Oracle Cloud PLM rebuilds it in three controlled steps, and what regulated manufacturers should decide before they load anything.
Key Takeaways
- History is your evidence. Past revisions, change orders and BOM changes prove why a product looks the way it does. Lose them and you lose your defence in an audit.
- Current state first, history second. Load the latest item and structure so the business can transact on day one, then rebuild the past in order.
- Change orders rebuild the story. Oracle's change order import replays each historical change on its original effectivity date, so users see revisions unfold in the right order.
- Order is everything. Import historical change orders out of sequence and the revision trail is wrong, and a wrong trail is worse than no trail.
- Regulated industries cannot leave this to chance .Medical device, pharma and electronics manufacturers should decide what must be retained, validate it and keep proof of that validation.
- The clock is running. Oracle Agile PLM 9.3.x Premier Support ends on 31 December 2027, so the window for doing this calmly is closing.
Why Agile PLM history matters after the move to Oracle Cloud PLM
Historical product data is the memory of your business, and memory is expensive to rebuild. Every revision of every item carries a decision: who changed what, when, and why.
That history earns its place in three ways:
- It answers the “why” question. Why was COMP2 swapped for COMP4? Why did the description change in 2025? Engineers, quality teams and auditors ask this constantly.
- It protects traceability. When a field issue lands, you need to know exactly which revision and which structure shipped on a given date.
- It supports audits. Regulators expect the trail to be kept and retrievable, and “we did not bring it across” is an answer they won’t accept.
History also feeds better decisions, showing which parts churn and which suppliers cause rework. It keeps manufacturing, planning and procurement working from a product record that makes sense end to end.
The tempting shortcut is to import the latest revision, call it done and switch off Agile. It is quick, and it leaves a hole where the engineering record should be.
Why rushed Agile PLM migrations drop the history first
- The current-state-only trap. Teams load the latest item and BOM, go live and promise to “do history later”. Later rarely comes, and Agile gets switched off first.
- The flattened trail. Revisions are loaded as plain attributes instead of being recreated through change orders. The data exists, but the story is gone: no change numbers, no effectivity dates, no sequence.
- The unvalidated dump. Dirty legacy data goes straight into the new model. Orphaned items, duplicate parts and broken links surface in UAT, or worse, in an audit. Our Agile PLM 2027 point of view covers these data issues in depth.
How Oracle Cloud PLM rebuilds Agile history in three steps
Once data has been extracted from Agile PLM and transformed, it comes into Oracle Cloud PLM in the order Oracle documents for migrating change redlines and historical item data with FBDI. Each step builds on the one before. History can also be loaded after go-live, which keeps the cutover short without disrupting the business.
- Item import with ItemImportTemplate: each item and its latest revision.
- Item structure import with ItemStructureImportTemplate: the BOM for that latest revision.
- Change order import with ChangeOrderImportTemplate: the historical revisions, in date order.
Step 1: Load today’s items and their latest revision
Start with where the business is now. Load each item with its latest revision, and set the revision effective date to the start date of that revision in Agile, not the load date. The item import covers item basics such as number, description, UOM, lifecycle phase and status, along with categories, flexfields, manufacturer and supplier relationships, organisation assignments and attachments. Users can transact on current data from day one while the history is rebuilt.
Step 2: Load the latest effective BOM
Next, import the structure that matches the latest revision: parent items, components, substitutes, reference designators and their flexfields. Every item with a BOM gets its latest structure in this step, so manufacturing, planning, procurement and inventory work from the current product structure. Items whose structures changed across earlier revisions get those changes in Step 3.
Step 3: Replay the history through change orders
Each historical change becomes a change order, imported against its original effectivity date. Oracle then reconstructs the revision trail, so users can see how the item and its structure evolved, in order. The change order import can carry revision progression, attribute and lifecycle changes, BOM additions, replacements and deletions, quantity and effectivity changes, attachment changes, and the change order’s own number, description and implementation dates.
A worked example: ITEM123
Take an assembly created in January 2024 and revised twice since.
| Revision | Effectivity date | End effectivity date | What changed | How it arrives |
|---|---|---|---|---|
| A | 01-Jan-2024 | 31-Dec-2024 | Created with COMP1 and COMP2 | Change order CO-001, after the current state is loaded |
| B | 01-Jan-2025 | 31-Dec-2025 | COMP3 added | Change order CO-002 |
| C | 01-Jan-2026 | None (current) | COMP2 replaced with COMP4 | Loaded first as the current state through item and structure import. Change order CO-003 then records the B to C redline. |
Revision C is live from the start, and the full A to B to C story sits behind it for anyone who needs it.
The rules that keep the migrated revision trail accurate
The approach is simple to describe and easy to get wrong. Hold the line on these rules:
- Import change orders oldest first. Each historical change order goes in the order it was originally implemented, and each revision carries the real date it took effect in Agile.
- Give every past revision two dates. Oracle requires an effectivity date and an end effectivity date for each historical revision, and no two date ranges can overlap.
- Load the latest revision as the current state. The revision on the item load must be the most recent one in Agile, with its true effective date.
- Load the building blocks before the change orders. Upload attachments to Oracle’s content repository (UCM) first and use their document IDs in the change order template. Load manufacturers before AMLs, and import past-revision components and substitutes before the change orders that use them.
- Treat the template as the boundary. Anything the standard templates support can move through them. Anything they don’t support needs a decision before the load.
Most migrations that go wrong break one of these rules. The signs are familiar: a revision trail scrambled by missing dates, old BOMs skipped because “nobody looks at them” until an auditor does, a signed attachment left behind, and no reconciliation to prove what moved. Duplicates, orphaned parts and circular BOMs are far cheaper to fix in Agile than in the target, so cleanse before you load.
What regulated manufacturers should do differently
- Start with a retention decision, and bring quality in early. Ask quality and regulatory teams which records must be kept, for how long, and in what form. Retention rules differ by product, market and regulation, so get a written answer before anyone writes a mapping, and have quality assurance co-own the migration plan from day one.
- Decide what moves and what stays archived. Recent, active revisions belong in Oracle Cloud PLM, where people work with them. Older history you must keep but rarely open can stay in a secure, read-only archive, provided it remains retrievable for as long as your retention rules require.
- Migrate the audit trail with the values. Change numbers, approvals, dates and reasons for change are the evidence. Rebuilding revisions through change orders keeps the sequence intact, which a flat attribute load cannot.
- Protect the links. Connections between changes, risk records, validation evidence, CAPAs and design history files are often the first thing to break. Map them explicitly and test them.
- Be honest about electronic signatures. Historical signatures migrated as data are records of what happened. Going forward, make sure the new platform enforces proper controls for electronic records and signatures under rules such as 21 CFR Part 11.
- Validate the migration itself. Treat the load as a controlled activity, with documented requirements, a risk-based validation approach and signed-off evidence that what arrived matches what left. Rehearse with several trial loads, including full change order history, while Agile is still live. Reconcile in both directions by counting records, comparing revisions and spot-checking structures and effectivity dates. Define who approves effectivity dates, who owns exceptions and how corrections are logged, so the plan shows attributable, accurate, complete and traceable data.
- Keep Agile readable until sign-off. Until validation is signed off, and for as long as your retention rules require, keep a secure, read-only way to reach the original records.
How InspireXT runs an Agile PLM history migration
We measure the Agile estate before anyone maps a field. PLM Insight profiles the data in 2 to 4 weeks, without touching the live system, and shows what the history migration involves. For a sense of scale, this is an illustrative profile of a mid-size Agile estate:
| What PLM Insight counts | Illustrative figure |
|---|---|
| Items | About 10,000 |
| Revisions and changes to sequence | About 200,000 |
| Duplicate parts to resolve | About 500 |
| Circular BOMs | Fewer than 20 |
| Unique error types to fix in the source | About 100 |
PLM Migrate then automates extraction, transformation and validation of the Agile data, which we estimate saves 6 to 8 weeks on an estate of this size. For regulated clients, we document the validation evidence: requirements, reconciliation reports and quality sign-off. After go-live, Test Automate checks item, BOM and change order flows on every quarterly Oracle update.
Three questions every regulated manufacturer should answer before migrating Agile PLM history
- Which Agile records must we keep, and for how long? Get the answer in writing from quality and regulatory teams before any mapping starts.
- Will the revision trail be rebuilt through change orders, or loaded flat? Only change orders keep the sequence, the change numbers and the effectivity dates.
- Who signs off that what arrived matches what left? Name the owner of reconciliation and validation evidence at the start.
The deadline will push many teams to chase speed. A migration that brings only today’s data gives you a platform. A migration that brings the history gives you a record you can stand behind.
Key questions leaders are asking about migrating Agile PLM history
Do we have to migrate every historical revision?
Not necessarily. Retention decisions belong with your quality and regulatory teams. What matters is that the decision is deliberate, documented and based on your obligations instead of what was easiest to extract.
Can Agile PLM history be loaded after go-live?
Yes. Oracle supports loading the latest revisions of items, components and attachments first, then importing historical revisions through change orders in a later phase. That keeps the cutover short while the full revision trail is rebuilt.
Which Oracle FBDI templates are used to migrate Agile PLM data?
Three: ItemImportTemplate for items and their latest revision, ItemStructureImportTemplate for the latest BOM, and ChangeOrderImportTemplate for historical revisions, rebuilt as change orders on their original effectivity dates.
Why not load all revisions as the first step?
Because the history is rebuilt on top of the current state. The latest item and structure go in first, then change orders replay earlier revisions on their original effectivity dates.
What goes wrong if change orders are loaded out of order?
The revision trail and structure evolution become inaccurate. Chronological sequence, starting with the oldest change order, is what keeps the record trustworthy.
Does the structure import include earlier BOM versions?
No. The structure import brings in the latest effective BOM. Earlier structure changes arrive through change orders afterwards.
How much Agile history will you need to move?
A PLM Insight assessment profiles your Agile data in 2 to 4 weeks, including revisions, change orders, duplicates and circular BOMs, without touching your live system.