Can You Get Your Data Back Out? A Data Export Readiness Test for Self-Hosted Applications

Why self-hosting does not by itself guarantee that data is portable

Running an application on infrastructure you control is valuable, but it does not automatically create a usable exit path. Self-hosting can give you access to the deployment and its stored data, yet that is different from being able to understand, transfer or re-create the business state held by the application.

For containerized deployments, persistent data may live in Docker volumes rather than in the container itself. Docker documents volumes as persistent stores that remain when a container is deleted and provides filesystem-level backup and restore examples. A copy of a volume can be essential for recovery, but it may be an application-specific collection of files rather than a portable business export.

Treat portability as a separate selection criterion. The question is not simply, “Can we copy the server data?” It is, “Can an authorised team recover the information we need, interpret it, verify it, and move it into an acceptable replacement process without relying on undocumented assumptions?”

• Hosting control addresses where a workload runs; exportability addresses whether its information can leave in usable form.
• A server, volume or database backup may support recovery of the same application but not migration to another application.
• A user download may support a personal record request but omit shared content, relationships, configuration and administrative information.

Define the data you may need to recover or move

An export test begins with scope. Teams often discover too late that “customer data” or “project data” was not a single thing. Make an inventory of the information and operational context required to continue work, meet retention obligations, investigate an event or transition to a new tool.

The precise categories depend on the application, but the inventory should be written in business terms first. Then map each category to its likely location: database, object or file storage, application configuration, identity provider, integration platform or infrastructure backup.

• Primary records: contacts, tickets, pages, tasks, events, messages, reports, form responses or other business objects.
• Files and binary content: attachments, uploads, images, documents, exports and any external file references.
• Relationships: parent-child links, labels, memberships, comments, activity history, record ownership and cross-record references.
• Configuration: fields, workflows, templates, taxonomies, dashboards, saved queries, notification rules and application settings.
• Identities and access: users, groups, roles, permission assignments and authentication-related configuration.
• Operational evidence: audit trails, logs, job history and error records, where these are needed for your use case.
• AI knowledge sources: source documents, metadata, chunking or indexing configuration where available, prompts or workflow definitions, and the links between source material and outputs.

Separate a user-facing export from an administrator-grade migration export

A user-facing export is designed for an individual to download information visible to that user. It may be appropriate for routine reporting, personal access requests or moving a small set of records. It should not be presumed to represent the whole organisation’s data.

An administrator-grade migration export has a different objective: it should enable an authorised organisation to move or reconstruct a defined scope, with enough identifiers, relationships and supporting assets to preserve useful business meaning. It also needs documented boundaries: what is included, what is excluded, and what changes on import.

Do not equate either kind of export with a backup. GitLab explicitly warns that project export files should not be used as backups, noting that exports do not always work for backup purposes and that not all items are exported. Keep recovery, migration and reporting needs as separate requirements even when one artifact contributes to more than one purpose.

• Ask who can initiate the export: an ordinary user, workspace administrator, system administrator or infrastructure operator.
• Ask whether the export is scoped to a user, project, workspace, organisation or full deployment.
• Ask what it preserves: records only, or also files, history, relationships, permissions and configuration.
• Ask whether import into another instance is supported and whether documented transformations occur during import.

The five export-readiness questions to ask before selecting an application

Use these questions in a product evaluation, proof of concept and annual governance review. Request answers for the application version you plan to run, because inclusion can vary by version and configuration. GitLab’s export documentation, for example, directs administrators to check the applicable export configuration to determine whether particular items are included.

A useful answer is demonstrable, not promotional. It identifies a documented procedure, the responsible role, the resulting files, known exclusions and a way to validate the result.

• 1. Scope: Can we export every data category in our inventory at the required organisational scope?
• 2. Fidelity: Are identifiers, relationships, timestamps, ownership, files, metadata and history retained in a documented way?
• 3. Independence: Can we inspect essential records and files outside the original application using documented formats or tools?
• 4. Recoverability: Is there a documented procedure to restore the complete application state, including the database, persistent data and required configuration?
• 5. Testability: Can we perform a representative export and reimport or restore test before production use, then repeat it on a defined schedule?

Choose formats that remain usable outside the original application

Prefer formats that match the shape of the data and can be read without the original application whenever practical. This does not mean one format fits every need. It means choosing an export whose contents can be inspected, validated and transformed with a reasonable level of independence.

JSON is a standardized, text-based, language-independent interchange format for structured data. It can be well suited to nested records and explicit links between objects, provided the export schema is documented. CSV can be effective for flat, tabular data, but it needs stronger validation when completeness matters: CSV implementations differ, and relationships or nested properties are often flattened, omitted or represented inconsistently.

Database dumps are another important category. PostgreSQL documents that a plain SQL dump contains commands needed to reconstruct the saved database state. Such a dump can be directly inspectable as text, while non-plain archive formats require pg_restore. Database-level access may be highly useful for recovery or technical analysis, but it is not automatically a business-friendly export and may not include external files or cluster-wide identity definitions.

• Use CSV for clearly defined tables, and document encoding, delimiter, headers, date and time representation, null handling and identifier columns.
• Use JSON when nested fields and object relationships must remain explicit; retain schema documentation and example records.
• Use original files for attachments where possible, with a manifest that connects each file to the relevant record.
• Use a database dump as part of a recovery package where appropriate, while documenting required database software, restore procedure and scope.
• Avoid treating an opaque application archive as sufficient evidence of portability unless its contents, import process and limitations are documented and tested.

Check whether attachments, file references and metadata stay linked to exported records

Files are frequently the gap between an export that looks complete and one that supports real continuity. A row that says an attachment existed is not enough if the file itself is absent, inaccessible or no longer associated with the correct record. Conversely, a folder of files without record identifiers, names, timestamps and relationship data can be difficult to use.

Check attachments as their own acceptance criterion. Export behaviour differs by product and feature. GitLab lists project uploads among exported project items, while Mattermost documents that its bulk export tool does not support file attachments. Neither example should be generalized to other applications; it illustrates why attachment handling requires direct verification.

Also inspect file references. Some applications may store a link to external storage instead of the binary file. In that case, your exit path depends on both the application export and continued authorised access to the referenced storage.

• Select records with multiple attachments, different file types and files added by different users.
• Confirm that every exported file has a durable identifier or manifest entry linking it to its source record.
• Check whether filenames, content types, sizes, creation times, authorship and access-relevant metadata are retained where needed.
• Identify whether files are exported, referenced externally or excluded.
• Open a sample of exported files independently and compare counts and sizes against the source scope.

Assess documentation, APIs and database access without assuming they are equivalent export paths

Documentation, APIs and database access can each be valuable, but they answer different needs. Good documentation explains the export’s scope, prerequisites, file structure, known exclusions, import behaviour and validation steps. Without that information, an available button or endpoint may still create an uncertain migration process.

An API can support scheduled or administrator-controlled collection, pagination and incremental workflows. However, API access does not prove that every asset moves with the export. GitLab’s project export API, for example, notes that container registries must be migrated separately and that CI/CD pipelines must be rerun to retrieve build artifacts. Treat related assets and integrations as explicit workstreams.

Database access can support a full technical recovery or custom extraction, but it requires schema knowledge and is not equivalent to a supported migration format. PostgreSQL also distinguishes single-database dumps from cluster-wide definitions: pg_dump does not include cluster-wide roles or tablespaces, whereas pg_dumpall can preserve those global definitions. Your assessment must identify which identity and permission information is needed and where it resides.

• Documentation test: Can a competent administrator follow the export and restore or import procedure without informal vendor knowledge?
• API test: Are scope, authentication, rate limits, pagination, errors and attachment retrieval documented for your planned workflow?
• Database test: Does the dump include the required database scope, and what files, configuration or global definitions sit outside it?
• Integration test: Which linked services, registries, identity systems, queues, storage locations or build artifacts need separate handling?
• Support boundary test: Is the path officially supported, or is it a custom extraction that your team must own?

Run a small export-and-reimport test before placing important business processes in the application

A live test is stronger evidence than a feature list. Before making an application a system of record or placing a business-critical workflow in it, create a representative test dataset and execute the export path. Where a supported import path exists, import into an isolated test instance or equivalent safe environment.

Do not stop when records appear on screen. Compare the source and destination using counts, identifiers and samples. Inspect relationships, attachments, timestamps, permissions, ownership, dashboards or templates where they matter. Then perform realistic work in the destination: search for content, open files, use linked records and confirm that required workflows can continue.

Import is not always behaviorally identical to the source. GitLab documents examples of import-time changes, including owner role changes, some protected-branch access resets and deploy keys not being imported. This is exactly the type of documented difference a test should identify before it becomes an urgent migration problem.

• Build a sample with ordinary records and edge cases: empty optional fields, special characters, deleted or archived items, multiple owners, files and cross-links.
• Record source totals before export and destination totals after import or restore.
• Use a reconciliation sheet for field-level differences, missing objects, inaccessible files, changed roles and excluded integrations.
• Set an acceptance threshold in advance: which losses are acceptable, which require a workaround and which disqualify the application?
• Capture the steps, access roles, elapsed effort, files produced, tool versions and exceptions so the test can be repeated.