When comparing online software, it is easy to focus on the features you will use from day one. It is also worth asking a less visible question: if the system stops working for you, will you be able to retrieve your data in a form you can actually use?
Downloading a file is not always the same as being able to migrate. You might get data without its relationships, attachments, or history; the format might only make sense inside the platform. Portability does not mean that switching providers will be instant. It does mean understanding what you could take with you, what might be left behind, and how much work a move could involve.
A useful evaluation asks not just “Is there an export?” but “Could we use it to continue the work we depend on?”
NIST’s cloud portability roadmap explains that moving data and applications between systems at an acceptable cost is part of the challenge, and that common formats and interfaces can help. That does not guarantee two products will work together directly; it is a reason to test your own case. Read NIST’s roadmap on cloud portability and interoperability.
What it means to take your data with you
A system’s information is often more than its main data file. It may include records, users, permissions, comments, attachments, tags, relationships between items, settings, and change history. An export may include some of these elements and leave out others.
Break the question into four parts:
- Scope: Which types of data are included, and which are excluded?
- Format: Can another system or a common tool read the files?
- Context: Are identifiers, dates, relationships, owners, and attachments preserved?
- Process: Who can start an export, how long does it take, and what permissions or steps does it require?
Microsoft’s official documentation, for example, says export options depend on the product. Some data can be exported in machine-readable formats using APIs, scripts, or portal features, while certain technical settings or proprietary information may not be included. The practical lesson is to review documentation for the specific product, rather than relying on a general platform promise. See Microsoft’s explanation of exporting customer data.
Run a simple test before committing
Ask for a trial or use a small, representative set of information. Avoid uploading real sensitive data just to experiment; create fictional examples that reproduce the structure your team needs. The test should show what comes out of the system and whether you could use it for a real task.
- Choose an important process. For example, a customer record with notes, an owner, a date, and attachments.
- Create varied cases. Include optional fields, special characters, files, different statuses, and relationships between items.
- Run the export. Record each file’s format, the steps involved, required roles, and any stated limits.
- Open the result outside the system. Check that it does not depend on a view exclusive to the provider and that its field names make sense.
- Check what is missing. Compare records, attachments, dates, identifiers, comments, and relationships with the originals.
- Simulate the next step. Import a portion into a test tool or create a table showing how you would continue the process.
An export that opens but does not show which record an attachment belongs to may not be enough for migration. Likewise, a CSV can be useful for analyzing tabular data but may not, on its own, preserve an application’s full behavior. Judge the result by what you need to do next, not by the file extension.
Specific questions to ask the provider
Instead of asking only “Can we export our data?”, request written answers to specific questions:
- Which entities and fields are included? Are attachments, comments, and history included too?
- Which formats are available, and is their structure documented?
- Is there an API or automated process for recurring exports?
- Are there volume limits, special permissions, timeframes, or associated fees?
- Is the export a static copy, or does it reflect later changes?
- What happens to data when an account closes, and how long is it retained?
- How can you confirm that remaining copies have been deleted under the applicable terms?
Answers may vary by product, account type, and configuration. Keep documentation links and provider responses alongside the record of your purchasing decision.
Understand formats without making assumptions
Familiar formats can make data easier to access, but they do not guarantee a complete migration. Google explains that the appropriate format depends on the service, data type, and intended use; it also notes that downloading data does not delete it from the original service. That distinction matters: exporting, transferring, and starting deletion are different actions. Review Google’s official data download options.
If the documentation mentions CSV, JSON, XML, or another format, find out what each file represents and how the pieces relate. If an API is available, check whether it covers the data you need and whether it requires technical skills or ongoing maintenance. If the output depends on a proprietary format, ask which tools can read it without an active account.
Plan an exit that matches the risk
Not every system needs the same level of planning. An auxiliary tool holding information that is easy to recreate needs less preparation than a system supporting operations, critical records, or customer data. Prioritize by impact: what would stop, what information would be difficult to rebuild, and which people would need to help with a migration?
Before signing up, decide who will own the export and validate its results. Document the procedure, required access, and a reasonable schedule for checking that it still works. If the information matters, test restoring or reusing an export; keeping a file that nobody has opened does not prove it is recoverable.
Conclusion: Before adopting online software, run a small export, confirm that it includes the data and context you need, and rehearse how you would continue the process outside the platform. If you cannot yet explain what is exported, in which format, and with what limitations, record that uncertainty as an open risk before committing hard-to-rebuild information or work.
