After the migration, the questions keep coming. Revision histories, historical BOMs, change orders, approved manufacturer lists and drawings stay searchable and reportable from the archive, with no Agile licence and no restore.
Field failures, warranty claims, supplier disputes, recalls and audits all reach back into product history, and they do not stop arriving because the PLM was retired.
A returned assembly needs the BOM as it was built, not as it is now. A supplier dispute needs the AML as approved at the time of the order. A quality investigation needs the change order that introduced a tolerance and the redline that shows what it replaced. A customer audit needs the drawing that was current when a batch shipped.
None of those are current-state questions, which is why an operational PLM does not necessarily answer them either once history has been trimmed on migration. The archive is where the as-was record lives, and reporting is how people get at it without learning the Agile object model.
Search covers the whole record with relationships intact, so a lookup can start from a part number, a change number, a manufacturer part or a date and move outward. Results are scoped by role, and every read is logged.
The set that covers most enquiries without anyone writing SQL.
Find the full archived product record from a part number, including every revision and the documents on each.
See what changed between two revisions of the same item, at attribute, structure and AML level.
Reconstruct the structure as it stood at a revision or effectivity date, expanded to the level you need.
Trace a component across archived structures to find every assembly it appeared in.
List the changes that affected an item with their sequence, effective dates and status.
Download the drawing or specification attached to a particular revision, with its original association intact.
Reporting is configured around the enquiries you actually receive.
Warranty, field failure, supplier dispute, recall, audit and due diligence each ask a different question. The list shapes everything else.
Which keys people start from: part number, change number, manufacturer part, product line, date. Those become the indexed entry points.
Revision history, as-was BOM, revision comparison, where-used, change history and document retrieval, configured rather than coded.
Engineering, quality, procurement and legal see what they are entitled to, with export-controlled data restricted and reads logged.
Real historical enquiries run against the archive and checked against the Agile source before Agile is switched off.
It is worth writing down the enquiries before designing the reporting, because the list is usually shorter and more specific than people expect, and it determines what has to be indexed.
These six account for the overwhelming majority of post-migration questions in a manufacturing business, and each maps to a standard report rather than to an ad-hoc query.
Three common arrangements, and what each one costs per question.
A full environment, licensed, patched and supported, so a handful of people can run a handful of queries a year.
Days of effort per enquiry, a restore path that decays untested, and a dependency on whoever still remembers the platform.
Fast, free and inadmissible. It also leaves with them.
It is search and reporting over archived Agile product data after the system has been migrated away from or decommissioned. Users retrieve item and revision histories, reconstruct the bill of material as it stood at a given revision or date, compare two revisions, trace where a component was used, list the change orders that affected an item, view the approved manufacturer list as it was at a point in time, and download the drawing attached to a specific revision. None of it requires an Agile licence or a restored environment.
Yes, and it is one of the most common reasons the archive exists. Because the archive holds revisions, structures and change effectivity rather than just current state, the structure can be resolved as it stood at a revision or an effectivity date, with quantities, reference designators and substitutes as they were then. That is what a warranty claim or a field-failure investigation on an older build actually needs.
No, and it is important not to position it that way. This is historical access and reporting over a retired system's record. Live product development, change authoring, workflow routing and approvals belong in the operational PLM, whether that is Oracle Fusion Cloud PLM or another platform. The archive answers questions about the past; it does not manage the present.
Quality and regulatory teams handling investigations, complaints and audits. Engineering answering field-failure and design-history questions. Procurement and supply chain checking what manufacturer was approved on a part at the time of an order. Legal and compliance responding to disputes, litigation holds and due diligence. Each group needs a different slice, which is why access is scoped by role rather than opened to everyone.
Ordinary lookups return in seconds, because the archive is indexed on the keys people actually start from: part number, change number, manufacturer part, product line and date. The exception is documents that have aged onto a cold storage tier, where retrieval takes minutes rather than milliseconds. Either way it is a query, not a project, which is the substantive difference from restoring an environment.
Yes. Access is scoped by role, so users see the product lines and document classes they are entitled to, and export-controlled technical data is restricted further by region or nationality where the regime requires it. Every search, view and download is logged with identity and timestamp, which is both a control and a source of evidence when someone later asks who saw a record.
Tell us the enquiries you receive and who receives them. We will show you how each one is answered from the archive and what it takes to stand the reporting up.