What to do with old company data: delete, archive, migrate or license

What are the options for old company data?#

The options for old company data are delete, archive, migrate and license, and most companies end up using more than one for the same system. A help desk being retired might see recent tickets migrated, its full history archived, a licensable subset prepared for AI developers and everything past its retention period deleted.

The common mistake is treating the choice as purely technical. Each option carries a legal, operational and financial consequence that becomes hard to reverse once a vendor subscription lapses or a server is wiped.

It also helps to separate the system from the records. Retiring a system is an IT decision; what happens to each record family inside it is a legal and business decision. A single ERP may hold invoices that must be kept, order notes worth assessing for licensing and marketing lists that should be deleted, and each deserves its own answer.

The four options compared#

The four options compare most usefully on when each fits and what can go wrong. Read across each row before deciding, because the cheapest move today is sometimes the most expensive one to undo.

Licensing is the only option that depends on someone outside the company. Deleting, archiving and migrating run on your own timetable, while licensing needs a buyer whose request matches your records, so it works best as a layer on top of a good archive rather than a substitute for one.

Which triggers point to which option?#

Specific events usually force the decision, and each trigger points to a different first move. Naming the trigger keeps a team from deleting what it should have archived, or migrating a slice of what it should have kept whole.

Several triggers often arrive together. An acquisition can bring a system retirement, a downsizing and a legal hold at the same time; when that happens, the hold sets the outer boundary and every other move happens inside it.

In what order should you decide?#

The order of decisions matters more than any single option. Work from legal constraints to operational needs to opportunity, so that no step removes a choice you may still need later.

Write the decisions down per record family, with an owner, the reason and the date. A short decision log answers the questions auditors, acquirers and buyers tend to ask later, such as why a record set was deleted or where the full history now lives.

• 1Confirm with counsel whether any legal hold, litigation or audit covers the system.
• 2Check the retention schedule for each record type in the system, including tax, employment and contract records.
• 3Inventory the system: record families, date coverage, attachments, custom fields and integrations.
• 4Decide what operations need in the new system, and migrate only that.
• 5Export the full history, with attachments and audit trails, in open formats before cutover.
• 6Assess whether a subset could be licensed, using metadata before any files leave the company.
• 7Delete what is past retention and not needed, and keep a record of the deletion.

Why export before you migrate#

Exporting before you migrate protects the history that a migration leaves behind. Migration projects are scoped around what the new system needs on day one, so they often carry over open tickets, active customers and current price lists but not closed work orders, internal comments or attachments.

That lost layer is often the most useful part for later analysis or licensing, because it records how problems were actually resolved. A closed ServiceTitan job with technician notes, or a solved Zendesk ticket with its internal thread, says far more than the summary field that survives a migration.

Check each vendor's export options and plan terms before giving notice. Some tools limit export formats, cap API access or remove access soon after cancellation, so read the vendor documentation and ask your account manager early. As one dated example, Box's 2013 service agreement gave customers 30 days after termination, on prior written request, to retrieve their content, after which Box would delete it unless legally prohibited. Your current contract may say something different, which is exactly why it needs reading before notice is given.

Illustrative: a distributor retires its old ERP#

Illustrative: a fictional industrial distributor is moving from an on-premises ERP to NetSuite. The migration plan carries open orders, active customers and current item masters, and the old server is scheduled for decommissioning shortly after go-live.

The CTO pauses the decommission to work through the decision order. Counsel confirms no holds apply. The retention schedule requires invoices and tax records to be kept, so those are archived read-only. Order exception notes, returns with reasons and backorder decisions are exported in full before cutover. A metadata fit check suggests the exception and returns history could merit a licensing review once customer names are removed.

Old marketing lists past their retention period are deleted with a documented record. The company ends up with one archive, a lean migration and a licensing option it can pursue or drop without pressure.

How SourceX fits into the old data decision#

SourceX covers only the license option, and only once holds and retention duties are respected. The first conversation is a metadata-only fit check about systems, record families and years of history, so no files leave the company while it decides.

If records proceed, Supply, Rights, Preparation, Approval and Delivery, the steps of the SourceX five-step transaction, run in order with the company approving each one. Large archives can stay in the company's own storage or ship on encrypted drives, so licensing does not require moving the archive to a new host.