Legacy system decommissioning checklist

What does decommissioning a legacy system involve?#

Decommissioning a legacy system means retiring an application while keeping the records the company still needs, then ending its licenses, integrations, access and infrastructure. The work is half technical and half record-keeping, and the record-keeping half is where most problems surface later.

In a mid-size company the legacy system is rarely a large ERP program with a dedicated team. It is more often a hosted helpdesk replaced by a new service desk, a CRM left behind after a merger, an on-premise order system running on one server, or a project database that only a few long-tenured staff still open. The subscription renewal date or the end of server support usually sets the deadline.

That deadline is the risk. A team racing a renewal notice tends to export only what the new system needs, such as open tickets or active customers, and lets the rest disappear with the old account.

Phase one: inventory the system and name its owners#

The inventory phase records what the legacy system holds, who depends on it and which contract governs it. Without that record, nobody can say later what was kept, what was deleted and why.

Build the inventory in a spreadsheet the business can read, not only in an IT ticket. Department heads often know about record types that never appear in a schema diagram, such as internal escalation notes or photos uploaded by field staff.

• 1System name, vendor, hosting model, contract end date and renewal notice period.
• 2Record families held: for example tickets, customer accounts, orders, jobs, estimates, comments and attachments.
• 3Date coverage: the earliest and latest records that still exist and can be exported.
• 4Integrations that feed the system or read from it, including reports and spreadsheets built on its exports.
• 5Admin accounts, the active user list and single sign-on connections.
• 6A business owner who decides on retention and a technical owner who runs the export.

Phase two: decide what to keep and why#

The keep decision starts from retention obligations and then asks whether anything else is worth preserving. Retention rules set a floor, not a ceiling; the company can choose to keep more when records still have business use.

Ask finance, HR and counsel which record types carry legal or tax retention duties, and check for legal holds before anything is deleted. Then ask operations and product leaders which history they would miss: past resolutions, warranty patterns, project decisions, root causes.

Assess records for value before anything is deleted#

Assessing records for value before deletion is the step most decommissioning checklists leave out. Old helpdesk archives, CRM histories, dispatch logs and quality records can interest AI developers, who license real operational records that show how work was requested, decided and resolved.

The value depends on how the records are kept. A ticket that links a customer question to an internal discussion, an engineering fix and a closing reply is far more useful than the same ticket exported as one row with the notes stripped out. Once the old system is gone, those links usually cannot be rebuilt.

A first assessment needs only metadata, not files. Answer these questions before the export plan is final, so the export can be shaped to keep what matters.

Use a simple decision rule. If the first two answers are yes, shape the export to keep the links, notes and attachments, and hold off on vendor deletion until the fit check is done. If they are no, a standard retention archive is enough, and the value question is closed in writing rather than left open.

• 1Do records connect a request to the decision and the outcome?
• 2How many years of that history can still be exported with notes and attachments?
• 3Are the records predominantly in English and written by your own staff?
• 4Do customer contracts, vendor terms or client ownership limit how the records can be used?
• 5Who could approve a license, and does any lender or investor consent apply?

Phase three: export, verify and archive#

The export phase produces an archive the company controls and can still read after the old system is gone. A complete archive keeps record IDs, timestamps, authors, internal notes, attachments and audit trails, because those fields carry the relationships between records.

Verification is the step teams skip under deadline pressure. Open the archive in a different tool from the one that produced it, reconcile record counts against the old system's own reports, and spot-check records end to end, including attachments.

Write down where the archive came from as you build it. The Data & Trust Alliance's Data Provenance Standards group dataset metadata into Source, Provenance and Use; an archive manifest that records the source system, how the export was made and what the records may be used for is far easier to rely on later.

• 1Request a full export, including any deleted-item recovery the vendor offers.
• 2Prefer open formats such as CSV or JSON for records, and keep original files for attachments.
• 3Keep native IDs and foreign keys so tickets, accounts, orders and comments still join.
• 4Document the schema, export date, export method and the person who ran it.
• 5Store the archive in company-controlled storage with access limited to named people.
• 6Reconcile counts and spot-check records before anything changes in the source system.

Phase four: shut down and close out#

The shutdown phase removes the system only after the archive is verified, and leaves a paper trail for each step. Auditors, acquirers and future counsel will ask what happened to the data, and a short evidence file answers them.

Read the vendor's termination clause before cancelling. Many vendors limit how long customer data stays available after an account closes, and some charge for bulk exports, so confirm the export works first and cancel second.

Illustrative: a distributor retires its helpdesk and order system#

Illustrative: a fictional industrial distributor is moving from an on-premise order system and a hosted helpdesk to NetSuite and a new service desk. The original plan exports open orders, active customers and unresolved tickets, then lets the helpdesk subscription lapse at renewal.

The CTO adds a value check to the plan. The inventory shows that the helpdesk holds years of order exception tickets, each linked to a customer, an order number and a resolution note written by the inside sales team. Exported as a flat list, those links would be lost.

The team changes the export to keep ticket IDs, order numbers, internal notes and attachments, stores the archive on company-controlled storage and reconciles counts before cancelling. Counsel flags a few key accounts whose contracts restrict reuse. The distributor then runs a metadata-only fit check on the archived exception records with those accounts excluded. The value check changed how the export was shaped, not the date the helpdesk was cancelled.

How SourceX fits into a decommissioning plan#

SourceX can review a legacy archive before shutdown, starting with a fit check that collects metadata, not files. That check sits at the Supply step of the SourceX five-step transaction (Supply, Rights, Preparation, Approval and Delivery) and can run in parallel with the export plan, so it does not have to delay the cutover.

The archive does not need to move for the review. It stays in company-controlled storage, and if a buyer later needs a large set it can travel on encrypted drives, because SourceX never hosts multi-TB datasets. If a license goes ahead, the export log and archive manifest from phase three become the starting point for the SourceX Evidence Packet, which documents provenance, licensing rights, permitted use, the privacy record and release authorization, with the company approving each step.