Keep the engineering record without keeping the engineering system. Items, superseded revisions, historical structures, closed change orders, redlines, AML and the drawings behind them preserved in queryable, retention-locked storage with the relationships between them intact.
A backup answers one question: can we restore the system. An engineering archive has to answer a different one: what did this part look like at revision C, who approved the change, and where is the drawing.
Restoring an Agile instance from tape to answer a single audit question means standing up a database, an application server and a vault, finding someone who remembers the admin password, and then navigating a system nobody has used in three years. Organisations that try it once usually decide not to try it twice, which is how Agile environments end up running long after anyone logs into them.
An archive inverts that. The product record is extracted while the system is still healthy, held as structured data with its relationships preserved, and made searchable directly. Finding the revision history of a part, the BOM as it stood on a date, or the ECO that changed it becomes a query rather than a restore project.
Retention is enforced at the storage layer rather than by policy documents. Immutable storage with retention locks means the archive cannot be altered or deleted inside the regulated window, including by administrators, and read access is logged so there is evidence of who looked at what.
Configured per retention regime rather than assembled per request.
Immutable object storage with retention rules enforced for the regulated window, so neither a user nor a storage administrator can alter or remove the record.
Find an item, a revision, a change order or a drawing by number, attribute or date without restoring anything.
Item to revision, revision to structure, structure to component, change to affected object, file to revision. The graph survives the move.
Hash-signed extract evidence, per-file checksums and run records, so the archive can be shown to be what the source held.
Read access scoped by role and recorded, which is what turns an archive into admissible evidence rather than a shared folder.
Frequently queried recent history on warm storage, deep history on cold, with the same query surface across both.
Eight to fourteen weeks from scoping to a signed, retention-locked archive.
Which objects, which date ranges, and which retention regime applies to each slice. Quality records, export-controlled data and general engineering history rarely share a retention period.
Objects and vault files pulled with counts and per-file checksums, producing a signed source baseline.
Data organised so the relationships are queryable, partitioned for the access patterns that actually occur, with master-data snapshots so historical records stay interpretable.
Role-scoped search across items, revisions, structures, changes and documents, with the reports audit and quality actually ask for.
Retention rules applied, reconciliation pack produced against the source baseline, and access logging switched on.
Preserving the data is the easy half. An archive earns its name only if the questions people ask can still be answered from it, and those questions are almost always about relationships rather than about single records.
The six properties below are what separate an archive somebody uses from an export somebody stores. Each is a design decision taken before extraction, not a feature added afterwards.
What each option really costs once the system is no longer in daily use.
Licences, database, application servers, vault storage, patching and the specialist who still knows it. All of it carried so a handful of enquiries a year can be answered.
A backup restores a system, eventually. It does not answer a question, and the restore path decays quietly until the day you need it.
Flattening the record to PDFs loses the structure. You can read a drawing but you cannot query a where-used, compare two revisions, or trace a change.
It is the practice of moving the Agile product record out of the live application into structured, queryable, retention-locked storage so the system itself can be retired. The archive holds items and every revision, the structures as they stood over time, closed change orders with their affected objects and redlines, manufacturer and AML data, and the drawings and specifications bound to the revisions they document. The point is that the record stays answerable without the application being available.
A backup preserves a system so it can be restored; an archive preserves a record so it can be queried. Answering an audit question from a backup means rebuilding the database, application server and vault, which is slow, expensive, and quietly gets harder every year as the platform ages. An archive answers the same question with a search. Backups also do not enforce retention immutability or log who read what, and both of those are usually the reason the archive exists.
It depends on the sector, and most manufacturers carry more than one. Quality-management records under ISO 9001 and IATF 16949, device history and design history records under FDA 21 CFR Part 820, electronic record and signature requirements under 21 CFR Part 11, aerospace records under AS9100, and export-controlled technical data under ITAR or EAR all carry their own periods and handling rules. Retention is mapped per data slice during scoping and enforced by storage-level retention locks rather than by policy alone.
That is the usual shape, and it is the cheapest one. Current operational product information moves into the new PLM, and superseded revisions, closed changes, retired products and their documents go to the archive. The new system stays fast and clean, the history stays available, and you avoid paying cloud PLM licensing to hold a decade of records nobody edits.
Yes, and that is the test of whether it is an archive at all. Users search by item number, revision, change order, manufacturer part, date or attribute, view a historical BOM as it stood at a revision, compare two revisions, trace where a component was used, and download the drawing attached to a specific revision. Access is scoped by role and every read is logged.
Through the reconciliation pack produced at sign-off. Counts are compared by object family between the Agile source and the archive: items, revisions, structure headers and components, manufacturer parts, AML entries, change orders and attachments. Every vault file carries a checksum recorded at extraction and verified in the archive. The extract itself is hash-signed, so the chain of custody from source to archive is evidenced rather than asserted.
Book a discovery call. We will review your Agile version, item and revision volumes, change history depth, vault size and the retention regimes that apply, and give you an archive footprint and timeline.