Decommissioning is a data problem before it is an infrastructure problem. Preserve the product record, prove it matches the source, give the people who need it a way in, and only then switch off the licences, the servers and the vault.
Almost nobody decides to keep running a retired PLM. They postpone switching it off because the question of where the history goes was never answered, and the postponement becomes permanent.
The blockers are consistent. Quality will not sign off while design history lives only in the system. Legal is uneasy about anything that looks like destroying records. Engineering wants to be able to look up an old structure. Procurement needs to know which manufacturer was approved on a part three years ago. Each objection is reasonable, and none of them is solved by an infrastructure plan.
They are solved by an archive with evidence behind it. Once the record is preserved with its relationships intact, once the reconciliation pack shows the archive matches what Agile held, and once the people who need the data have used it for real enquiries during a parallel run, the objections resolve and the shutdown becomes routine.
After that, decommissioning is what it should have been all along: reclaiming licences, servers, vault storage, backup and DR capacity, and removing an unsupported platform from the estate.
The cost of a dormant PLM is spread across six budget lines, which is why it is easy to overlook.
Application and database licences carried for a system that has no active users.
Application servers, database hosts and the virtualisation or hardware underneath them.
Production-grade storage holding files whose last read was years ago, plus the copies behind it.
Backup windows, media and replication capacity for a system nobody would notice going down.
Patching, certificate renewals, access reviews and the specialist time that keeps an unsupported stack alive.
An unpatched application server and database, reachable on the network, with credentials nobody has rotated.
The switch-off is the short part. Everything before it is what makes the switch-off possible.
Which records must be retained, for how long, and under whose authority. Get quality, legal and compliance to state their requirements early rather than discover them at sign-off.
Objects and vault extracted with counts, checksums and a signed source baseline, then structured so the relationships stay queryable.
Reconciliation by object family, per-file checksum verification and a sign-off pack circulated to the people whose objections would otherwise block shutdown.
Real enquiries answered from the archive while Agile is still up, so gaps surface while the fallback still exists.
Access withdrawn, then servers, database, vault storage, backup and DR decommissioned and licences released.
Decommissioning programmes rarely fail on technology. They stall because a stakeholder cannot sign, and the reason they cannot sign is usually evidence rather than principle.
Each objection below has a specific artefact that resolves it. Producing them early is what turns a stalled retirement into a scheduled one.
Only one of them ends with the environment actually switched off.
The system stays up 'for now', unsupported and unpatched, and the cost quietly recurs every year with no owner.
Backups taken, environment dropped, and the first audit or warranty claim afterwards turns into a restore project nobody budgeted.
The record is preserved and evidenced, access is replaced before it is withdrawn, and the shutdown is a routine change rather than a leap.
Four stages in order. Preserve the product record, extracting items, revisions, structures, manufacturer and AML data, change orders with their redlines, and the vault, with counts and per-file checksums against a signed source baseline. Prove it, by reconciling the archive to the source by object family and publishing a pack that quality, legal and audit can sign. Provide access, standing up role-scoped search and proving it against real enquiries while Agile is still running. Then retire the stack: application servers, database, vault storage, backup, DR and the licences.
No. What changes after December 2027 is that Agile PLM no longer receives Premier Support. The software keeps functioning, so this is a support and risk milestone rather than a shutdown date. It matters because an unsupported platform stops receiving fixes while still sitting on your network, which is why most organisations use the date as a planning anchor for migration or archival rather than as a deadline to panic about.
By giving them evidence rather than assurances, and by involving them at the start. The reconciliation pack shows counts matching by object family between source and archive, the checksum record shows every vault file arrived intact, and the hash-signed extract establishes chain of custody. The parallel run then lets them answer their own real enquiries from the archive while Agile is still available. In practice that sequence, rather than any single document, is what converts an objection into a sign-off.
User access first, which is reversible and surfaces anyone who was still quietly relying on the system. Then application servers, then the database, then vault storage, then the backup and DR footprint that stood behind all of them. Licences are released last, once nothing is running that would need them. Keeping a cold copy of the environment for a short defined period after shutdown is a cheap insurance policy and is usually worth doing.
Fifteen to eighteen weeks is typical for a single Agile instance, and the schedule is dominated by vault extraction and by how quickly quality, legal and compliance state their retention requirements. The switch-off itself takes days. Programmes that overrun almost always do so at the front, because the obligations were not established before the archive was designed.
That is what the archive is for, and the whole design assumes the question will be asked. Historical enquiries are answered by searching the archive rather than by restoring anything. In the rare case where archived data has to be re-loaded into a live system, the structured archive can be transformed back into import format, carrying the original checksums and extract evidence so the reloaded data has a provable chain of custody.
Book a decommissioning discovery call. We will map your retention obligations, size the archive, and give you a switch-off plan your quality and legal teams can actually sign.