5 Questions to Ask Before a Legacy System Goes Dark

Enterprises are retiring legacy ERP systems at a pace the compliance function has never seen before. Vendor support deadlines, cloud migrations and delayed modernization programs have converged, and systems that ran the business for 15 or 20 years are being scheduled for shutdown on project timelines measured in months.

The transformation program celebrates go-live, and the steering committee tracks cutover milestones. What almost no program tracks with the same discipline is the other half of the event: what happens to the old system, and everything inside it, when it goes dark.

Having spent more than 15 years inside ERP implementations and migrations, I have come to believe decommissioning is the most under-governed moment in the entire system lifecycle. The new system gets a program, a budget and a governance board. The old system gets a shutdown date. And between those two facts sits a set of compliance obligations that do not end just because the software does.

Retention obligations outlive the system

The first and largest exposure is the simplest to state: Records retention requirements attach to the records, not to the system that holds them.

Financial records that support tax positions must generally be retained for years after filing. Public companies carry audit workpaper and financial record obligations under Sarbanes-Oxley. Regulated industries stack sector rules on top: pharmaceutical manufacturers carry predicate rule obligations for batch and quality records under 21 CFR Part 11, and broker-dealers face strict format and duration requirements under SEC Rule 17a-4. Employment, environmental, safety and contract records each carry their own clocks, and for organizations operating in Europe, retention must also be balanced against storage limitation duties under GDPR Article 5.

None of these clocks resets at go-live. The uncomfortable question for compliance leaders is whether anyone has mapped which record types in the dying system carry which obligations, for how long and where they will live once the system is gone. In most programs I have observed, that mapping either does not exist or was produced by the migration team as a data exercise, without legal and compliance review of what the law actually requires the organization to keep.

This points to the second exposure, and the one most often misunderstood inside transformation programs: Migrating data is not the same as preserving records.

Data migration is selective by design. Programs migrate open items, active master data and a limited window of history, because carrying two decades of closed transactions into a new system is expensive and operationally pointless. That logic is sound for operations but dangerous for compliance because the records that matter in a dispute, an audit or an investigation are very often the closed, old and inactive ones that migration deliberately leaves behind.

Audit trails deserve particular attention. A transactional record without its change history, approval log and posting trail is a weaker record. Regulators and auditors increasingly expect not just the document but the evidence of who created it, who changed it and when, an expectation reflected in the SEC’s electronic recordkeeping amendments. 

In major ERP platforms, those change logs and posting trails live in structures separate from the documents themselves, and a complete picture often requires correlating events that began in satellite systems, an order captured here, a shipment confirmed there, before ending as postings in the core ERP. Reconstructing that chain means deliberately joining those sources; standard migration extracts do not. 

The stakes are not theoretical. Revlon’s troubled ERP rollout led the company to disclose a material weakness in its internal controls over financial reporting in its SEC filings, followed by shareholder litigation. That case involved an implementation rather than a shutdown, but the lesson transfers: When system transitions and financial records collide, the consequences surface in disclosures, audits and courtrooms, not in IT status reports.

Litigation readiness compounds the problem. If matters are pending or reasonably anticipated, shutting down a system that holds relevant electronically stored information walks directly into preservation duties, and courts have shown limited patience for evidence lost to routine IT projects under Rule 37(e). Every decommissioning plan should pass through a legal hold check before anyone schedules the final backup.

I have sat through many cutover weekends, and to be fair, the data that moves is treated with enormous care. Client and vendor teams audit the migration loads together, run end-to-end simulations with test data, verify that postings and accounting entries generate correctly across functions and check every interface, phase by phase in a planned sequence. It is disciplined, impressive work. 

And that is exactly what makes the contrast so striking: I have never seen the same ceremony applied to what stays behind. The migrated slice gets simulated, reconciled and signed off. The remaining history gets a backup job and a shutdown date.

Governance

Is Legacy Infrastructure Holding Your Company Back?

by Jim DeLoach

March 26, 2024

Best practices to overcome technical debt

Read moreDetails

The questions to ask before a system goes dark

The good news is that this exposure is manageable with a short list of disciplined questions, asked early. Compliance leaders do not need to run the decommissioning project, but they need a seat at it, and they need answers to five things in writing.

• First, what is the record inventory? Which record types exist in the system, which carry legal or regulatory retention obligations and what are the longest applicable clocks, jurisdiction by jurisdiction?
• Second, what is the preservation design? For records that must survive the system, where will they live: an archiving platform, a read-only environment or extracted files and does that destination preserve enough context, including audit trails, to keep the records usable and defensible?
• Third, who can still read it in Year 8? Formats age, and a perfectly preserved archive nobody can open is a compliance failure with extra steps. Accessibility across the full retention horizon is a requirement, not a nice-to-have and the principle anchoring ISO 15489.
• Fourth, has legal signed off on holds? Are any matters pending or anticipated that touch the system’s data, and has the shutdown plan been cleared against active and foreseeable legal holds?
• Fifth, what is the destruction story? Records past retention should be defensibly destroyed, not accidentally kept forever in a forgotten backup. An unmanaged archive is discovery risk and privacy risk in equal measure. In practice, live systems often hold only a short residence window while the legal retention clocks run for decades in whatever archive receives the rest, and over the years those horizons tend to shrink on storage economics and IT judgment, a copy trimmed here, a downstream system synced there.

There is also a forward-looking reason to get this right. Enterprises are beginning to train and ground AI models on their historical business data, and the archives created at decommissioning will become tomorrow’s training material and retrieval sources. Decisions made during a shutdown weekend — which years survive, which trails are kept joinable, which context is flattened away — will shape what future models can accurately learn about how the business actually operated. An archive built merely to satisfy a checkbox produces an AI that reasons over a partial past with full confidence. Preservation quality, in other words, is no longer only a compliance question; it is becoming a data strategy question, and the two now deserve the same seat at the decommissioning table.

Nobody’s milestone, everybody’s problem

The structural reason these questions go unasked is familiar to anyone who has watched a large program up close. Decommissioning sits at the seam between functions. IT owns the shutdown task, the program owns the timeline, records management owns a policy and compliance finds out at the end. The old system is nobody’s milestone, so its obligations become everybody’s problem, usually years later, when a regulator, auditor or opposing counsel asks for something that went dark with the server.

The fix costs little. Put decommissioning on the compliance agenda the day the transformation program is approved, not the month before shutdown. Require the five questions above as a gate before any legacy system is retired. And treat the retirement of a system of record with the same seriousness as its implementation, because the obligations it holds will outlive it either way.