Can You Still Retrieve Your Old ERP Records? Test how people will find and understand records after shutdown.
Before retiring a legacy ERP system, ask an ordinary authorized user to retrieve and explain a representative historical record using only the proposed replacement arrangements. If the user still needs the old application, an undocumented query, or a departing specialist, the retirement plan has an unresolved dependency.
A successful migration of open transactions does not establish that historical information remains usable. The business may need to explain a past invoice, investigate a correction, answer a customer dispute, or reconstruct the basis of an earlier decision. Those needs can involve attachments, relationships, and meanings that a simple data export does not preserve by itself.
Make decommissioning depend on retrieval evidence. The necessary deliverables are a history disposition register and an acceptance pack that demonstrates how records will be found, interpreted, checked, and supported after shutdown.
Interview the teams that use history: finance, operations, customer service, records management, and any other relevant owners. Ask for actual categories of requests and representative examples, using appropriate access and privacy controls.
For each request, identify who asks, what information starts the search, which period or population is involved, what output is needed, and how quickly the business needs to respond. Someone investigating a customer issue may have only an old reference and a delivery date. Designing an archive around the internal record identifier alone may leave that person unable to begin.
Distinguish frequent operational use from occasional evidence retrieval. The first may justify migrating more usable history or providing a familiar inquiry experience. The second may be served by a controlled archive. The right arrangement depends on volume, complexity, response expectations, access restrictions, and the cost of maintaining it.
Record obligations separately from preferences. Qualified records, legal, privacy, and finance owners should establish applicable retention, preservation, access, and disposal requirements. Requirements can differ by record type and circumstance. Do not adopt a single retention period merely because it appears in a project template.
Create a register organized by meaningful record populations, such as completed transactions, open items, reference data, attachments, approvals, and audit history. For each population, document its owner, business uses, required context, approved retention basis, destination, access method, and proposed retirement dependency.
Choose among four dispositions:
These categories can coexist within one transaction family. Open items might migrate while completed items move to an archive. That split needs a clear boundary and reconciliation so records do not disappear between destinations or acquire conflicting authority.
A temporary retention decision needs an owner, cost, support plan, review date, and exit condition. “Keep it just in case” does not establish which risk the organization is managing or how it will know that the old environment can eventually be removed.
A row of values may be unreadable without its definitions. Preserve the context needed for the intended retrieval uses: field meanings, code descriptions, relationships, relevant units and currencies, date interpretations, and links to supporting documents.
Consider historical changes. A customer may have been renamed, an item code replaced, or an organizational unit closed. If the retrieval view always joins to today's reference data, it may present a historical event with a meaning it did not have at the time. The appropriate treatment depends on the use, but it should be deliberate and documented.
Preserve relationships that support the business question. An invoice may need its lines, related credit documents, shipment references, and approval evidence. Exporting each table successfully does not demonstrate that an authorized user can reconnect them correctly.
Also document transformations made during archiving. Normalizing a code or changing a display format can be reasonable. The business should still be able to explain what changed and trace the archived representation to the source. Technical integrity checks can support this evidence, but they do not by themselves prove that the content is complete or correctly interpreted.
A retrieval test should state the starting request, authorized role, search information available, expected records, interpretation required, reconciliation method, output, and evidence to retain. Set a response expectation based on the actual business need, rather than an arbitrary performance target.
Use a tester who did not build the archive where practical. The tester should follow the proposed support and access routes. If a specialist must intervene, record the intervention and decide whether it belongs in the operating model or indicates a gap.
Test unsuccessful searches too. A user needs to distinguish “no matching record” from “no permission,” “search incomplete,” and “support required.” An empty result without an explanation can create false confidence that no record exists.
Access testing should include both permitted and restricted users, with approved test data and procedures. Confirm that retrieval and export follow the intended permissions. An archive can preserve the records while accidentally making them available to a broader audience than the source system allowed.
Imagine a distributor planning to retire its old order and invoicing environment. In this hypothetical scenario, the migration team has loaded open receivables into the new system and exported older transactions to an archive. File counts and transfer checks appear satisfactory.
The acceptance request asks a customer-service analyst to explain a historical invoice that was partially credited after a delivery issue. The analyst starts with the customer's former name, an approximate month, and a delivery reference. No internal database identifier is supplied.
The analyst finds the invoice but cannot locate the credit document. The archive contains the credit record, yet its relationship to the original invoice is not exposed in the retrieval view. A delivery attachment is also stored separately under an obsolete location code.
The archive team corrects the relationship mapping and adds an approved search route for former names and location references. The business owner then repeats the scenario. The analyst retrieves the invoice, credit, relevant delivery evidence, and a clear explanation of the remaining amount using the intended permissions.
The finance reviewer verifies that the retrieved amounts and relationships agree with the source evidence retained for the test. The customer-service owner accepts the usability of the search and explanation. Neither approval alone covers the complete outcome.
Finally, the team repeats the request using the documented support route after deliberately removing access to the old application from the test procedure. This controlled test establishes whether the replacement arrangement can stand on its own. It does not authorize actual shutdown until the other record populations and retirement conditions have also been assessed.
For each record population, retain the approved disposition, source boundary, extraction or transfer evidence, transformation notes, reconciliation results, retrieval scenarios, access checks, unresolved exceptions, and named acceptance owners.
The pack should distinguish complete coverage checks from representative tests. Counts and control totals may address a whole population. A set of user retrieval scenarios demonstrates selected uses. Neither should be described as proving every possible historical question. Explain the remaining limitations and whether the responsible owner accepts them.
Include the operational instructions: how users request access, search, obtain an export, escalate a problem, and report a suspected missing record. Identify who maintains the archive, the definitions, and the search experience after the implementation team leaves.
The evidence also needs a durable home and an owner. A retrieval design documented only in the migration lead's personal folder can become a dependency of its own. Preserve enough context for another qualified person to operate and investigate the arrangement.
A backup of the old database is not a complete retrieval service. Its usability may depend on compatible software, configuration, supporting files, access arrangements, or expertise. If restoration is part of the plan, test the complete route required to answer the business request.
Likewise, an archive needs a continuity plan. Define how availability is monitored, how a loss or corruption is detected, who initiates recovery, and what evidence demonstrates that recovered content remains usable. Technical owners should verify mechanisms against the chosen architecture; the business should validate the resulting retrieval capability.
Reassess the arrangement when technology, formats, access models, or business uses change. A test passed at retirement does not guarantee permanent usability. Choose review and recovery-test intervals according to the importance of the records and the organization's policies.
The final retirement review should confirm that every material record population has an approved disposition, required retrieval tests have passed, unresolved limitations have an accountable decision, applicable holds and obligations have been checked, and ongoing support is funded and assigned.
Separate removal of ordinary user access, cessation of processing, contract termination, infrastructure shutdown, and authorized data disposal. These actions may have different prerequisites and different reversibility. The decommissioning runbook should state their sequence and responsible approvers.
For the next retirement meeting, bring one representative historical request and its completed retrieval evidence. Ask the business owner to explain the result without opening the legacy application. That demonstration makes the shutdown decision concrete: the organization can see whether it has preserved the ability to answer the questions it will still need to answer.