Can the Customer Use Your Enterprise Tenant Export?
Define a tenant exit package by business records, attachments, relationships and receiver checks. Separate usable data return from AWS account handover and...
An enterprise tenant has a usable exit when the receiving owner can interpret the agreed data, recover required attachments and verify their relationships at the accepted cut. A downloadable archive is only a delivery format. Define its schema, manifest, exclusions and receiving checks before promising portability. Keep data return, account administration and deletion as separately accepted tasks.
This matters before the first dedicated deployment. A customer-owned AWS account can contain the infrastructure while the vendor still controls the only usable export process. Conversely, a customer can receive a portable business dataset without taking over the vendor's application. Decide which outcome the customer bought. The worked package below is fictional and contains no customer data or executed export.
Choose the handover outcome before the file format
There are at least three different outcomes. Data return supplies records and supporting files for another system to use. Application continuation supplies the artifacts, configuration, access and operating knowledge needed to run the product. Archive custody preserves records for later inspection under an accepted retention policy. One package may contribute to several outcomes, but acceptance should name each one.
A CSV can be suitable for data return while omitting the runtime needed for application continuation. A database snapshot can preserve a database while requiring an engine, keys, tooling and a reader who understands its schema. A copied bucket can preserve objects while losing the mapping from business records to attachments. Select formats from the receiving task rather than choosing the most convenient existing backup.
The enterprise tenant operating paper owns the commercial duties and separate delivery and retention tracks. This narrower review produces an export acceptance manifest. It does not promise license transfer, assign intellectual property or determine a retention period. Those boundaries belong in the actual agreement with the responsible owners.
Ask the receiving owner what they will do first: import records into a replacement, answer an audit question, or run the existing application. Specify the fields, relationships, timestamps, encodings and supporting files that task requires. A format is not portable merely because a developer can open it on the supplier's laptop.
Write a manifest that describes meaning as well as bytes
The manifest should identify package revision, tenant scope, accepted cut, schema revision and every delivered file. Record counts, sizes and selected integrity checks with their units and algorithms. Define null values, deleted records, timezones, decimal representation and identifier relationships. Include a readable explanation of omissions and the receiving test.
S3 Inventory can supply scheduled object listings and metadata, with current-only or all-version scope. AWS notes that the first report may take up to 48 hours. It is useful inventory evidence, not a synchronized application export across a database and its files. Establish your own cut and reconciliation rules. S3 Inventory
| Manifest field | Receiving question |
|---|---|
| Tenant and cut | Which tenant and business state does this package represent? |
| Schema and identifiers | How do records, attachments and history join? |
| Population | Which records are included, excluded or unresolved? |
| Integrity | Which file bytes and algorithm does each check cover? |
| Interpretation | Which units, timestamps, null rules and codes are used? |
| Acceptance | Who runs the receiving checks and records the result? |
Keep secrets outside the package unless a separately approved handover explicitly requires a protected transfer. Export configuration references without embedding working API credentials. Identity records may require a mapping to a new system rather than portable passwords or sessions. An administrator's ability to read a field is not enough reason to disclose it to every recipient.
Reconcile a small package exactly
Suppose tenant T4 has three accepted orders at cut C4: O1 is USD 40.00, O2 is USD 60.00 and O3 is USD 25.00. Store their teaching amounts as 4,000, 6,000 and 2,500 cents. The expected total is 12,500 cents, or USD 125.00. No exchange rate, tax or price is inferred from these invented amounts.
The required attachment set contains A1 for O1 and A2 for O2. O3 legitimately has no attachment. The manifest states three order records and two attachment objects, with a relationship for each delivered attachment. A receiver must check both the set of identifiers and the amounts. Three records alone cannot show that all three intended orders arrived.
Package A contains O1, O2 and another copy of O2. Its count is three, but its distinct order count is two and its total is USD 160.00. It fails the identity set and amount checks. Package B contains the correct three orders and both attachment objects, but points O2 to A1. Counts, total and individual object checks can all pass while the relationship is wrong. It fails the order-to-attachment check.
| Package | Orders and total | Attachments | Receiving disposition |
|---|---|---|---|
| A | Three rows, two distinct orders, USD 160.00 | Not sufficient to rescue missing O3 | Return for correction |
| B | O1, O2, O3; USD 125.00 | Correct objects, wrong O2 relationship | Return for correction |
| C | O1, O2, O3; USD 125.00 | A1 to O1; A2 to O2; O3 explicitly none | Candidate for the remaining checks |
Package C still needs interpretation and permitted-recipient checks. The table establishes the stipulated relationships, not successful ingestion by a real replacement system. If the receiver expects whole currency units while reading the integer cents as dollars, it can import USD 12,500.00 from otherwise intact files. Put scale in the schema and test the imported meaning.
Test with the receiving tool and identity
Begin with authorized read-only review of the existing manifest and receiving contract. Before any rehearsal, obtain separate authorization for an isolated receiving target, synthetic or approved sanitized data and scoped test identities. Make downstream actions, integrations and notifications inert or disconnected, and bound runtime, storage and spend. Stop if a path can create live effects or expose out-of-scope data. Actual source exports and any deletion require separate approval.
Agree a safe rehearsal using synthetic data and the receiving owner's intended tools. Confirm the recipient can decrypt and read the package, join its records, interpret its values and detect an intentionally missing attachment. Record the package revision and receiving result. A supplier-side unpack operation does not answer whether the customer can use it.
AWS documents checksums for checking uploaded and downloaded S3 object integrity. Record the algorithm and relevant object representation rather than assuming every ETag is a whole-file MD5. Integrity checks can detect changed bytes; they cannot establish that the export selected the right tenant or preserved a business relationship. S3 object integrity
Include an interrupted transfer and a corrected package. The receiver should withhold acceptance of a partial package and identify which revision replaces it. Do not overwrite the manifest while leaving old download links presented as current. If the archive contains unexpectedly sensitive fields, stop distribution and follow the approved incident and replacement process.
For ongoing writes, decide how the final cut is established. A frozen export window, a supported snapshot mechanism or a baseline plus reviewed changes can be valid candidates. Each needs a design for concurrent updates and deletion. This article does not prescribe one universal transaction boundary across S3 and a database. The reconciliation paper addresses the wider invariant and cut design.
Keep account control and retained copies visible
If the customer will operate the application, list additional handover requirements: build artifacts, infrastructure definitions, configuration, domains, monitoring, access, licenses, keys and open incidents. Verify the supported operating path without relying on the departing team's personal access. Do not embed those duties into a data-export acceptance checkbox.
Data return also does not establish deletion. Retained backups, logs, support attachments and permitted archives have their own custodians, access and expiry. The agreed closure process may intentionally keep some copies after the active service ends. Record that state accurately without keeping ordinary application access alive solely to make an archive readable.
An inaccessible encryption key can make intact exported bytes unusable. Establish permitted receiving access before ending the source service or removing the transfer path. Restoring access later may be impossible under the chosen lifecycle. Do not disable protection to make an export convenient; select an approved delivery method and verify it before closure.
Next action: Bring the receiver into the launch agreement
Choose the format and scope before promising exit dates. A narrow documented data-return format can be enough when the customer has an importer and does not need application continuation. A richer open schema can reduce later interpretation work but creates an ongoing compatibility obligation. A native backup can preserve more technical state while making the receiver dependent on a specific engine and recovery path.
For the next tenant proposal, fill one manifest for three synthetic records, two attachments and one deliberately absent relationship. Ask the intended receiver to identify the bad package and explain the corrected import. Keep the first unresolved field or access dependency assigned to an owner before deployment is approved.
An enterprise SaaS engineering review can scope that export contract alongside the actual product and receiving constraints. The useful starting material is the proposed outcome, schema and failure case. Private tenant data, account identifiers and credentials are unnecessary for that first scoping discussion.