The usual reason an Agile instance is still running is that a few people occasionally need to look something up. Give them role-scoped search over the archived record instead, and the environment stops being the price of access.
Most retired PLM systems are not retired. They are left running, unsupported and unpatched, because nobody could answer the question of where engineering would look things up afterwards.
The cost of that decision is rarely visible in one place. It is the licence line, the database, the application servers, the vault storage, the backup and DR footprint, the patch cycle that keeps slipping, and the one person who still knows how the thing is configured. Against that sits a genuine need: engineering, quality and procurement really do have to reach the historical record.
Legacy data access separates the two. The record is preserved in the archive with its relationships intact; access is delivered through role-scoped search in a browser; and the environment goes away. The people who needed the data still have it, and in most cases they find it faster than they did in Agile.
Read-only is a design property rather than a permission setting. There is no write path into the archive, so historical data cannot drift after the fact and the retention lock has nothing to fight against.
What changes about day-to-day access once the record is in the archive.
No client install, no VPN to a legacy network segment, no account on a system nobody administers any more.
Indexed on the keys people actually start from, so the common enquiries return in seconds.
Read-only by construction. Historical data cannot be edited after the fact, deliberately or accidentally.
Access through your current identity provider, so leavers lose access automatically instead of lingering in a forgotten user table.
A drawing is retrieved against its revision and change, rather than found by guessing at a file name.
Nothing to patch, no unsupported database, no application server exposed because it cannot be upgraded.
Run both in parallel briefly, then switch off with confidence.
Access logs and a short round of interviews usually reveal a much smaller user population than the licence count suggests.
The handful of questions those users ask, which determines what has to be searchable and what merely has to be retained.
The record extracted, structured with relationships preserved and indexed on the access paths that matter.
Users answer real enquiries from the archive while Agile is still available, and any gap is fixed before it becomes urgent.
Agile access removed, then the environment decommissioned once the parallel period has passed without issues.
The decision to keep an Agile instance running for lookups is rarely costed, because the cost is spread across teams that each see only their share of it.
Totalling the six lines below is usually the moment the conversation changes, because the number is larger than any single owner expected and it recurs every year.
Three ways to keep the door open, with very different running costs.
Still a full environment: licences, database, servers, storage, patching and the specialist. Read-only changes the risk, not the cost.
Every enquiry becomes a ticket and a hand-written query, answered by someone who does not know the product data.
Findable only if you already know the file name, with no revision context and no access log.
Through a browser, using your existing identity provider, against the archived record rather than the retired application. They search by part number, change number, manufacturer part, product line or date and navigate outward through the preserved relationships to revisions, structures, AML, changes and documents. There is no Agile client to install, no legacy network segment to reach, and no account to maintain on an unsupported system.
Yes, by construction rather than by permission. There is no write path into the archive, so historical records cannot be edited after the fact by a user, an administrator or an integration. That is what makes the archive trustworthy as evidence, and it is also what allows retention locks to be applied without conflicting with day-to-day use.
Yes. Access is scoped by role, so engineering, quality, procurement and legal each reach the slice of the record they are entitled to, and scoping can go further by product line or document class. Export-controlled technical data is restricted by region or nationality where the regime requires it. Every access is logged with identity and timestamp regardless of role.
They are not carried across, and that is usually an improvement. Long-lived Agile deployments accumulate accounts for leavers, contractors and integrations that nobody has reviewed in years. Archive access is granted through your current identity provider against current roles, so joiners and leavers are handled by the process you already run rather than by a user table somebody has to remember to prune.
Typically eight to twelve weeks from first connection to the point where users are answering real enquiries from the archive, with the archive extraction and vault transfer dominating the schedule. The parallel-run period at the end is short but worth protecting: it is where you find the one enquiry type nobody mentioned during scoping, while Agile is still available to fall back on.
In practice most find it easier, for two reasons. The archive is indexed on the keys people actually start their enquiries from, whereas navigating to the same answer in Agile often meant knowing which tab held it. And the population that still uses a legacy PLM is small and expert, so the enquiry set is narrow and can be made explicit rather than general-purpose.
Tell us who uses it and what they ask. We will show you how each enquiry is answered from the archive and what the environment is costing you to keep the door open.