Application retirement vs data migration: what happens to old records

What is the difference between application retirement and data migration?#

Data migration is the transfer of selected records from an old system into a new one, while application retirement, also called decommissioning, is shutting the old application down for good. Migration answers what the new system needs to run the business. Retirement answers what happens to everything else.

The two usually travel together. A company moving to a new help desk migrates open tickets and active customers, then retires the old platform. An industrial distributor re-implementing its ERP brings over open orders, item masters and balances, then decides whether closed orders and exception notes go to an archive, stay in a read-only copy or are deleted.

The gap between the two is where most history ends up. Nobody chooses to lose years of resolved tickets; they fall out of scope because the new system does not need them on day one, and the retirement plan assumes the migration plan handled them.

What moves, what stays, and who can still reach it#

What moves, what stays and who can reach it depend on which path each record family takes at the system change. The table compares the three paths old records usually follow.

Archived is not the same as usable. A database dump with no schema description, or a stack of CSV files full of internal IDs and no lookup tables, can be technically preserved and practically unreadable when someone needs it later.

Which records usually get left behind?#

The records most often left behind are the ones that carry context rather than current state. Migration tools are built to move the latest version of each record; histories and relationships take extra mapping work, and project teams under deadline drop them first.

Those dropped parts are also what makes old records useful outside daily operations. A resolved ticket with its full thread and its link to the bug fix shows how a problem was solved; the same ticket reduced to a subject line and a closed date shows almost nothing.

• 1Closed tickets, cases and work orders older than the migration cutoff.
• 2Comment threads, internal notes and email bodies attached to records.
• 3Status and field change histories, such as who reassigned a ticket and when.
• 4Attachments: photos, PDFs, drawings and log files.
• 5Links between objects, such as a ticket tied to an engineering issue or an order tied to a claim.
• 6Custom fields and retired picklist values that no longer map to anything.

How long can people reach old records after the switch?#

Access to old records after a switch lasts only as long as someone keeps a working copy, which is a budget and contract decision rather than a technical default. A read-only license on the old SaaS plan, an archive platform and exports on company storage each carry different costs and risks.

Vendor terms shape the options. Many SaaS vendors limit what can be exported, how far back exports reach or how long data is kept after cancellation, and the rules can differ by plan, so check the agreement and the vendor's documentation before setting a shutdown date. Two examples show the range. BQE says a CSV backup of a CORE database is available for a fee and must be requested in writing by the company owner, typically taking 1 to 3 working days. Atlassian's August 2023 Data Processing Addendum describes deactivating paid accounts shortly after the subscription ends and retaining data for a limited period before deletion, with timelines that vary by plan and DPA version. On-premises systems carry a different risk: the server is decommissioned, and the database is only as good as the last restore someone actually tested.

A practical pattern is to keep the old system read-only through the first audit or year-end close after cutover, then rely on a documented archive the company controls. Whichever route you choose, test it: ask someone outside the project team to find a specific closed record, with its thread and attachments, using only the archive and its documentation.

When is the licensing window open?#

The licensing window for old records opens when a system change is approved and closes when the old data is deleted, and it is widest before the export is designed. Once the export spec is fixed, anything it omits is effectively gone.

That is why licensing questions belong in the migration plan rather than after it. Adding a few elements to the archive export costs little during the project and is often impossible afterward. The table lists what to add and why.

Illustrative: a freight brokerage retires its old TMS#

Illustrative: a fictional freight brokerage replaces an on-premises TMS with a cloud TMS. The project plan migrates active carriers, customers, rate agreements and open loads. Closed loads, check-call notes, claims and the exception history are left out of scope.

Before the archive export is written, the IT lead adds load-to-exception-to-claim links, note threads with timestamps and a field dictionary to the spec. Finance keeps the archive for audits and disputes, and leadership separately runs a metadata-only fit check on the exception history. The old server is shut down on schedule, and the history of how disruptions were handled survives in a documented archive the company controls. Because the archive keeps role labels as well as dispatcher names, later de-identification does not require rebuilding who handled each load.

How SourceX fits into a retirement plan#

SourceX works alongside the IT team's retirement plan rather than replacing it. The fit check uses metadata about the old system, its record families and its date coverage, so nothing leaves the company while the plan is still being set.

If a package proceeds, preparation and delivery follow the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Large archives stay in the company's own storage or ship on encrypted drives; SourceX never hosts multi-terabyte datasets.