When a customer cancels: data export, retention and deletion

A useful export holds everything the customer entered or uploaded: records as CSV or JSON, files in their original formats, user lists, settings and the change history.

Keep relationships intact, because an invoice export that drops the customer ID, or a ticket export without its comments, is a file nobody can load into another system. Add a short readme. It names each file and column.

Leave out internal notes, other tenants’ data and your own pricing logic, since none of it belongs to the departing customer or can be exported safely.

During the grace period the account is read-only, so the customer can log in, export and reactivate, but nobody can add records, and deletion waits for the end date. Write the length into the terms.

Some data has its own clock. Invoices may need to stay for the period the tax authority requires, support chats rarely do, so keep a retention table with each data type, period and reason.

Ask your accountant or lawyer which periods apply, because software only enforces the rule you choose and cannot pick one for you. Get that answer in writing.

Deleting the database row is easy. Copies also sit in file storage, the search index, caches, analytics tables, email logs, error trackers and the tools your support team uses. Give every copy a deletion step.

Backups are different, since you rarely edit one, so let each expire on a fixed cycle and purge deleted tenants again after any restore. State the cycle in your privacy notice.

Where a tenant has its own schema, deletion is one drop, while shared tables need a job that removes rows by tenant ID and checks the count reaches zero.

If you serve customers in Europe, the GDPR gives people rights to access, to portability and to erasure of their personal data. Your product often acts as processor for the business that signed up, so the business decides and you carry out the instruction.

That has design consequences. You need an export a customer can run unaided, a deletion request that someone can trigger and a way to confirm completion. Whether a given case is covered is a legal question for your adviser, and the software cannot answer it for you, however well the export button works.

An end user’s deletion request becomes a ticket. It goes to the account owner.

Give cancellation a status page inside the account that walks through four states: export ready, grace period ending on a date, deletion scheduled and deletion complete. Customers stop emailing to ask.

On your side, the operator console shows the same states and writes a deletion certificate: tenant ID, timestamp, systems cleared and the backup expiry date. Keep that record after the data goes.

Run a dummy tenant through the whole flow this week, then read the certificate and check that every location in your runbook shows as cleared.