A “CSV export” checkbox is not a complete SaaS exit plan. Customers need to know which entities are included, how relationships are represented, whether attachments and audit events are delivered, how dates and Arabic text are encoded, how the package is transferred, and when retained copies are deleted. The only reliable specification ends with a restore test.
Write the export contract before procurement or before a major architecture commitment. It protects both customer and vendor by defining scope, responsibility, limits, and acceptance. It also makes routine customer-requested exports easier because the product team is not inventing a package during cancellation.
Inventory entities and ownership
List every customer-owned domain: accounts, users, roles, clients, transactions, catalog, bookings, notes, messages, configuration, files, and generated documents as applicable. Mark excluded platform telemetry, secrets, derived aggregates, and data owned by another party.
For each entity, identify the tenant key, stable record key, human label, lifecycle state, and parent relationships. Do not rely on database row IDs without documenting them. A receiving system needs keys that remain stable across files.
Define files and schemas
Choose formats based on structure and portability. CSV works for flat tables, while JSON or another structured format may preserve nested data. Provide a manifest listing files, version, generation time, locale, encoding, row count, checksum, and schema reference.
Document every column, type, null behavior, enum, unit, currency precision, timezone, and escaping rule. Keep the specification versioned. Adding a column is different from changing the meaning of an existing one.
Preserve relationships
Include foreign keys that let the recipient reconnect parent and child records. Validate that every referenced parent exists in the package or is declared as an external reference. Report orphaned records rather than dropping them silently.
Provide an entity-relationship summary and examples using fictitious data. Test repeated human names, deleted parents, archived records, and many-to-many relationships. A set of readable files can still be unusable if its links are ambiguous.
Package attachments and generated documents
Store attachments under non-sensitive internal paths and include a mapping file with record key, original display name, media type, size, checksum, creation time, and retention status. Do not expose private storage paths, signed URLs, or object-store credentials.
Decide whether generated invoices, receipts, certificates, and previews are included as files, reproducible source data, or both. Verify checksums and scan the export process for missing or duplicate objects. A database-only export may omit the evidence users care about most.
Handle audit events and history
Define whether the package includes current state only, change history, and security audit events. Some audit data may contain platform-sensitive details or third-party personal data and needs a reviewed boundary. Explain what is retained by the vendor for legal or security reasons.
Use actor references that remain meaningful after account deletion without exposing credentials. Record timestamps in a consistent timezone and include event type and target keys. Avoid exporting raw logs as a substitute for a structured history.
Preserve dates, numbers, and Arabic text
Use UTF-8 and test Arabic names, mixed-direction text, diacritics, and spreadsheet import. State the delimiter, quote, newline, and byte-order policy for CSV. Provide a sample and an automated parser test rather than assuming every spreadsheet interprets the file correctly.
Keep timestamps machine-readable with timezone, and use exact decimal or integer representations for money and measurements. Do not allow spreadsheet software to turn phone numbers, identifiers, or dates into different values.
Secure package generation and delivery
Generate exports in an isolated job with tenant context, least-privilege access, bounded memory, and failure cleanup. Store the package on private encrypted storage, issue a short-lived authorized download, and audit generation and access.
Never email a large unencrypted package or place it on a public link. Define expiration, retry, cancellation, and what happens when generation fails halfway. Notify the customer without including package contents in the message.
Specify retention and deletion
State how long the generated package remains available, when temporary files are removed, which production records remain under contract or law, and how deletion is confirmed. Cancellation of a download should not accidentally delete the source data.
Distinguish account closure, export package expiration, and data erasure. They are separate events with different approvals and evidence. Include processor and subprocessor responsibilities where applicable.
Add counts and checksums
The manifest should include row counts per entity, attachment counts, byte sizes, and checksums. Compare counts to scoped source queries at generation time. Record rejected or omitted items with reason instead of returning a “successful” incomplete package.
Provide a verification command or small open script that checks archive integrity, checksums, required files, headers, and relationship references. The recipient should not need the original application to know the package is internally consistent.
Run a neutral restore test
Load the export into an empty neutral database or analysis environment using only the schema documentation. Reconnect relationships, open sampled attachments, verify Arabic text, and reproduce representative totals. Measure time and note manual transformations.
The restore test is not a promise that every competitor can import the package directly. It proves the data is understandable and usable outside the source application. Repeat it after material schema or export changes.
Put the export in procurement and release gates
For buyers, add the specification and sample to the contract, including frequency, cost, delivery window, format version, and exit assistance. For builders, add automated export coverage and a periodic restore drill to the release program.
Review the SaaS build-or-buy worksheet, the multi-tenant SaaS development service, and the published terms for available Tek products. Ask for an example package before data volume or cancellation creates urgency.
Conclusion: an export is complete only when it can be used
A useful SaaS export has an inventory, stable keys, schemas, relationships, files, history boundaries, correct encoding, secure delivery, retention rules, counts, checksums, and a neutral restore result. Define those elements early and test them repeatedly. Data ownership becomes operational when the customer can verify and use the package without depending on the original interface.
