A useful SaaS data export preserves enough information to rebuild a working customer journey: records, relationships, files, permissions and references to connected services. Prove that with an isolated import rehearsal before planning the final cutover. A large CSV download or a completed database backup is evidence of extraction, not evidence that the product can move.
This checklist uses a fictional studio-management SaaS with organizations, projects, attachments and subscriptions. It is for founders evaluating vendor lock-in, changing a supplier or commissioning a migration. It does not assume that every platform can export the same data or that billing and identity credentials can be moved by copying database rows.
Key takeaways
- Define the customer workflow the export must restore before selecting a file format.
- Include relationships, attachments and permission rules in the acceptance scope.
- Keep external identity and billing references distinct from local records.
- Plan changes during migration and rehearse the decision to roll back.
Choose one journey the destination must demonstrate
For the fictional studio SaaS, a customer signs in, opens the correct organization, finds a project, downloads its drawing and sees the appropriate subscription features. An administrator can find the same project and explain who may edit it. That journey defines what must survive.
Create an inventory of the data and configuration behind it. Include inactive records, archived projects, audit history needed for the product and files referenced by database rows. Decide which history is intentionally excluded and why. Do not silently classify difficult-to-export information as unnecessary.
Ask the current provider about actual export capabilities, limits and access requirements. Keep a distinction between 'available now', 'requires provider assistance' and 'cannot be exported in the required form'. That record is more useful than a general claim that you own your data.
Prepare a manifest for the export package
Give the package a version, capture time and an agreed scope. Describe record identifiers, relationships, file locations and transformations. State units and time-zone conventions explicitly. For a shared international product, a bare date or an unexplained monetary number can change meaning during import.
Keep an ID mapping when the destination generates new identifiers. A project attachment must still point to the correct project, and a membership must still point to the intended organization. Validate that mapping rather than assuming equal row counts imply equal relationships.
The manifest below is a planning example. Its purpose is to make omissions and acceptance criteria reviewable, not to prescribe one archive format for every SaaS.
| Package item | Information to preserve | Acceptance exercise |
|---|---|---|
| Organizations and memberships | Stable source IDs, member relationships and role meanings. | A Cedar member reaches Cedar records and cannot reach Harbor's private records. |
| Projects and archived records | Ownership, status, revision references and intentionally retained history. | Open a current and an archived project with expected state. |
| Attachments | Actual file bytes, names, content types and source-record linkage. | Download representative files and verify their integrity and owner. |
| Identity linkage | Approved mapping to the destination identity system. | Complete the supported sign-in or recovery journey without granting extra access. |
| Billing linkage | Provider customer/subscription references and internal plan meaning. | Resolve the existing billing relationship without creating an unintended new subscription. |
| Configuration and exclusions | Versioned fields, units, time zones and declared omissions. | Review transformations and confirm every exclusion with its owner. |
Separate database extraction from product restoration
PostgreSQL documents pg_dump as an internally consistent snapshot of the database at the start of the dump and describes the corresponding restore tools. That is useful when your source permits this form of database access. It does not include every external file, identity configuration or connected account your product depends on.
Restore to an isolated environment with the intended destination schema and permissions. Keep production notifications, scheduled jobs and billing mutations disabled for the rehearsal. Confirm the appropriate tool and database-version compatibility before choosing the restore procedure.
Inspect sample relationships and important edge cases after import: an organization with several roles, a project without attachments, an archived project and a record containing non-ASCII text. Compare agreed counts and checksums where appropriate, then complete the customer journey. Use synthetic or appropriately protected data for the review.
Can your export restore the customer journey?
Share the source platform, destination and workflow that must survive. We can define an export manifest and an isolated import rehearsal.
Keep identity and billing under their actual owners
Do not assume that credentials can be extracted or that a new identity system accepts the old representation. Confirm the supported migration or recovery route for the systems involved. Verify that mapping an identity does not accidentally merge separate customers who happen to share an email address.
Billing has its own lifecycle. Stripe's subscription documentation describes recurring billing objects and their relationship to the customer and product. If your product uses Stripe, preserve and verify the appropriate linkage rather than treating a local 'paid' field as the subscription itself. Other providers need their own documented process.
For the studio example, the new application should identify the existing billing relationship and apply the intended plan permissions. Recreating subscriptions simply to fill a missing database column can introduce unintended billing. Include a reviewable billing exercise in the rehearsal and keep payment actions controlled.
Plan the changes that arrive after the first export
Customers may continue creating projects and uploading files during the rehearsal. Decide how the final migration includes those changes: a controlled write freeze, a supported incremental export or another validated synchronization approach. Record the cutoff and the system that owns each new write.
A short freeze may be simpler for a small application, but its duration must come from a measured rehearsal and the business's tolerance. Do not promise a zero-downtime migration without a design and evidence that supports it. A database delta also needs corresponding file and relationship changes.
Rehearse rollback. If customers write new data in the destination before you return to the source, explain how those writes are retained or reconciled. Restoring yesterday's source snapshot is not sufficient if it discards today's accepted work.
Approve the move with evidence and a handover
Keep the export manifest, transformation decisions, verification results, cutover procedure and rollback limits together. Mark unsupported or untested parts explicitly. Acceptance should identify which customer journeys worked and which exceptions remain.
Define who keeps the export, who can access it and when it is removed under the agreed retention process. Keep real customer information out of public migration documents. A rehearsal package can be sensitive even when it is stored outside production.
MUBBITS can help scope the extraction, import and application changes around the product you need to preserve. Share the source platform, a sanitized data model and the critical journey first; actual export access and destination constraints determine the work.
Frequently asked questions
Is a database backup the same as a portable SaaS export?
No. A database backup may support database recovery while omitting external files, identity configuration, connected-service references and application behavior. Demonstrate the required journey after an isolated restore or import.
Do equal source and destination row counts prove success?
They are one useful check. Also verify relationships, ownership, file integrity, transformations and the behavior the customer needs. Equal counts can still contain mismatched records.
Can we keep accepting changes during migration?
Only with an agreed method for capturing and reconciling those changes. Test the incremental or synchronization approach, including attachments, and document the cutover and rollback boundaries.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.