About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A hosted software customer's exit needs two separately evidenced outcomes: a usable handover of the agreed information, and an accurate account of what has been deleted or retained. Define the scope and acceptance criteria before freezing writes, revoking access or deleting records.
For a multi-tenant application, the export must contain the departing customer's authorised information without exposing another tenant's data. A database dump is appropriate only where its scope and permissions satisfy that boundary; it is not the default answer for a shared database.
Agree what the customer is receiving
Create an export catalogue covering the contracted records, attachments, relationships, relevant history and configuration. Specify formats, character encoding, field definitions and any software needed to interpret them. Decide whether audit records or integration configuration belong in the handover, and handle secrets through an appropriate separate process.
Document exclusions and why they apply. For example, platform-wide security logs may require a carefully scoped extract rather than delivery of the original shared log. Do not silently omit an object because it is difficult to export, or include other customers' information to make the export convenient.
Our recommendation is to agree an acceptance pack before the final transfer:
| Item | Suggested acceptance evidence |
|---|---|
| Structured records | Counts by object type, schema/data dictionary and representative queries |
| Attachments | File inventory, integrity hashes and sampled opening of expected formats |
| Relationships | Checks that parent/child and document references resolve |
| Business meaning | Customer-approved sample totals or transactions |
| Destination usability | Import or consumption test in the intended replacement environment |
Equal row counts alone cannot prove that relationships, encodings or business meaning survived the transfer. A hash can verify byte integrity against a known file, but cannot establish that the correct records were selected.
Plan the final changes and write freeze
Agree when the old application remains authoritative and when the replacement takes over. Identify any initial export, delta transfer, final reconciliation and write-freeze window. Explain how integrations and queued jobs will be handled so they do not create unaccounted-for changes during the handover.
For an illustrative appointment system, an initial export might be tested before the final cutover. The final transfer would then include agreed changes since that export, followed by checks of appointments and attachments. This is an example planning pattern, not a tested procedure or customer story.
Set a decision owner and failure conditions. If acceptance fails, follow the agreed continuation or recovery plan; do not proceed to deletion simply because an export file was produced. Any period of parallel operation must have explicit write ownership and reconciliation rules.
Deliver through a controlled route
Use an approved encrypted transfer route and tenant-scoped access for the authorised recipient. Verify recipient identity and authority through the existing business process. Do not email unprotected production exports or place them on an unlisted public URL.
Record which export version was delivered, its inventory and integrity hashes, who received it and the acceptance result. Give temporary export access an expiry and an owner. Revoke it after the agreed acceptance window, while preserving any separately authorised access needed to complete unresolved issues.
Protect the working copies made during export preparation. Include temporary archives and staging directories in the exit inventory; otherwise the formal production deletion may leave an overlooked copy behind.
Determine retention obligations before deletion
Confirm whether the Australian Privacy Principles apply to the relevant entity and information, and obtain qualified advice for legal holds, retention duties or disputed ownership.
OAIC chapter 11 requires reasonable destruction or de-identification steps when covered information is no longer needed for a permitted purpose, subject to stated exceptions including certain legally required retention and Commonwealth records. Its guidance treats destruction as irretrievability and describes tightly constrained circumstances for putting information beyond use. A convenient retention setting does not automatically satisfy those conditions.
Where a third party performs deletion, the guidance includes verification in the reasonable steps to consider. The exact duties depend on the facts; this article does not certify compliance.
Track copies and exceptions individually
Our recommended register separates active application storage, attachments, search indexes, caches, analytics stores, support material, temporary exports and backups. For each, record the owner, applicable authority, planned action, evidence and any unresolved exception.
Immutable or shared backup storage can make selective removal difficult. That is a condition to assess and document, not an automatic exemption from obligations. Obtain an approved plan for access restrictions, retention expiry, eventual destruction and any restoration handling. Do not claim that retained information is beyond use unless the applicable requirements are actually met.
If a retained backup is restored for an authorised purpose, the plan should address whether previously removed tenant information would become active again and how to prevent that outcome. This is a control-design recommendation, not a validated recovery procedure. Test a suitable implementation with synthetic data before relying on it.
Avoid ad hoc deletion commands in a shared production database. A tenant-scoped removal process needs reviewed selection rules, dependency handling and protection for other tenants. This article supplies no destructive commands or instructions to bypass retention controls.
Issue a qualified completion record
The exit statement should distinguish completed work from exceptions. Record the accepted export, revoked access, systems cleared, verification dates, retained categories, reasons and the next required action. Include a named owner for unfinished obligations.
“Active application data removed; restricted backup copies remain under the documented retention plan” is a different claim from “all copies destroyed”. Use whichever statement the evidence actually supports. Do not issue an unconditional deletion certificate while relevant exceptions remain unresolved.
Keep business acceptance of the handover separate from destruction evidence. The customer's confirmation that an export is usable does not prove that the provider removed every residual copy, and deletion does not prove that the export was complete.
Software vendor hosting is the related service area for discussing these requirements. No NetLeverage exit timescale, export feature or legal guarantee is asserted.
Limits and sources
This is source-researched planning guidance, not legal advice or a tested migration/deletion procedure. Product-specific tooling, contract scope and qualified review are required before implementing destructive operations. The example workflow is an editorial recommendation for an ISV's departing customer, rather than a guide to moving the ISV's entire infrastructure between clouds.
- OAIC chapter 11: APP 11 Security of personal information, updated 3 October 2025; accessed 14 November 2026. See the retention exceptions and guidance on destruction, third-party verification and putting information beyond use.
- OAIC chapter B: Key concepts, version 1.4, published 21 December 2022; accessed 14 November 2026. Applicability should be assessed for the actual entities involved.
Learning notes
A usable export needs tenant boundaries and business validation. Deletion needs evidence for each copy and a qualified record of exceptions. Neither a delivery receipt nor a generic certificate proves both outcomes.
This article was originally published on .