Data Ownership and Portability: Questions to Ask Before Adopting a Platform

Most businesses ask about features, price and support before they adopt a new platform.

Far fewer ask the question that matters most on the day they want to leave: can we take our data with us, and will it still be usable when we do?

That question is easy to skip during a sales process, when everyone is focused on getting started. It gets expensive later, when the platform has become the place where customer records, project history, financial data or internal knowledge actually live, and moving them out turns into a months-long project with an uncertain result.

This article explains the difference between owning data, accessing it and being able to move it, what the law does and does not guarantee, and the specific questions to put to any vendor before you sign. It also covers how to test a platform's exit before you depend on it, and how to keep your own options open once you are in.

Ownership, Access and Portability Are Three Different Things

These terms are often used as if they meant the same thing. They do not, and vendors sometimes lean on the confusion.

Ownership is about rights. Who has the legal claim to the data you put into the platform, and what is the vendor allowed to do with it? Most reputable software agreements say the customer retains ownership of its data. That sentence is common and worth reading, but it settles less than it appears to. Legal ownership of data is a murkier concept than ownership of physical property, and in practice your rights are defined mostly by the contract, not by any universal rule.

Access is about whether you can see and retrieve your data. You may own it on paper and still have no practical way to get a complete copy, or only a partial one, or one that arrives weeks after you ask.

Portability is about whether you can use what you retrieve. A file that contains your records but strips the relationships between them, drops attachments, loses history or uses a format only the original vendor's software can read gives you access without portability. You can hold your data, but you cannot do much with it.

All three matter, and a platform can be strong on one and weak on another. A vendor can promise ownership in its terms while making export so limited that switching is unrealistic. The questions in this article are designed to test all three.

Why This Matters More Than It Seems

It is tempting to treat exit planning as pessimism. You are about to adopt a tool you chose carefully, so why plan for leaving?

Because software relationships change, often for reasons outside your control. Prices rise. Products are acquired, merged, discontinued or redirected. Features you relied on move behind a higher tier. A new regulation, a security incident or a change in your own business makes the platform a poor fit. In each case, your leverage depends on how hard it is to leave.

IT leaders are clearly aware of this. The Parallels 2026 State of Cloud Computing Survey, which polled 540 IT professionals in the United States, the United Kingdom and Germany in November 2025, found that 94% of organizations were concerned about vendor lock-in, with nearly half describing themselves as very concerned. Parallels sells virtualization software and has its own interest in the topic, and the sample is limited to three countries, so treat the figure as a signal of sentiment rather than a precise measurement. Even so, it reflects a pattern many buyers recognize: the cost of switching quietly shapes decisions long after the purchase.

Lock-in also has several layers. Data lock-in arises when your information is stored in formats or structures that are hard to move. Technical lock-in arises when your processes depend on a vendor's particular features or integrations. Skills lock-in arises when your team is trained on one product. The questions below focus mainly on the data layer, because it is the one you can most easily examine, and test, before committing.

What the Law Does and Does Not Give You

Many buyers assume that privacy or data protection law guarantees them a right to take their business data elsewhere. The reality is more limited, and it depends on where you are.

GDPR portability is about individuals, not businesses

The European Union's GDPR includes a right to data portability in Article 20. It lets an individual receive the personal data they have provided to a controller in a structured, commonly used and machine-readable format, and transmit it to another controller. The scope is narrow in several ways. It covers only data the person provided, not data inferred or derived about them, and it applies where processing is based on consent or a contract. It is also a right belonging to individuals about their personal data, not a general right of a business to export everything it has stored in a vendor's system.

So if your company stores customer records in a CRM, GDPR portability does not give your company a claim to a clean export of the whole CRM database. It governs how individuals can obtain their own data. The business-to-vendor relationship is mostly governed by the contract.

The EU Data Act changes the picture for cloud and SaaS in Europe

The EU Data Act (Regulation 2023/2854) is more directly relevant. Its cloud switching rules, which apply to providers of data processing services such as IaaS, PaaS and SaaS, became applicable on 12 September 2025. They are intended to make it easier for customers to move between providers, reducing lock-in. The rules cover input and output data, including metadata, generated through use of the service, and they apply to providers outside the EU that serve customers in the EU.

Several features are worth knowing:

• Providers must allow customers to switch, and contracts must include switching terms. The maximum notice period a customer must give is two months.
• Charges for switching, including data egress fees, were limited to the provider's actual costs during a transition period. From 12 January 2027, switching charges, including egress charges, are banned.
• Standard service fees continue, and proportionate early termination fees can still be included in fixed-term contracts.
• Where a customer uses multiple providers in parallel, providers may still charge egress fees, though only up to their actual costs.
• The switching rules do not apply to services custom-built for a single customer.

This is a significant shift for buyers in or serving Europe, and it gives you a firm basis to ask questions and negotiate. It is not a magic solution. As one commentary on the rules points out, a regulation can ban fees, but it cannot untangle a data landscape that has become locked into proprietary services over years. Legal rights to switch do not make the technical work of migration disappear.

Elsewhere, the contract is what you have

Other jurisdictions take different approaches. Some, such as California under its privacy laws, give individuals certain rights to obtain their personal data. Few give businesses a general right to a complete, usable export of their own data from a software vendor. For most companies outside the EU, the practical position is that the contract and the vendor's product capabilities decide what you can take. This article is general information, not legal advice, so check your own jurisdiction and take counsel's advice on significant contracts.

That is why the questions below matter. They help you establish, in writing and by testing, what the law may not provide.

The Questions to Ask

Ownership and rights

Who owns the data we put into the platform, and does the contract say so explicitly? Look for plain language stating that the customer owns its data, and that the vendor receives only the license it needs to run the service. A vague or missing statement is a reason to ask for clarification before signing.

What counts as "our data"? This is where definitions matter. Records you enter are clearly yours, but what about metadata, usage logs, analytics generated about your account, configurations, workflows, templates and reports you build inside the platform? Some vendors define customer data narrowly, which can leave valuable derived material outside the scope of what you can claim or export. Ask for the definition in writing.

What rights does the vendor have to use our data? Typical agreements allow processing to provide the service. Some also reserve rights to use aggregated or anonymized data to improve products, and some go further. Ask exactly what is permitted, whether you can opt out, and how data is anonymized.

Will our data be used to train AI models? This question was rare a few years ago and is now essential. Ask whether customer content is used to train or fine-tune models, whether that applies to the vendor's own models or those of third parties, whether it is opt-in or opt-out, and whether the answer differs by pricing tier. Get the answer in the contract, not just in marketing material or a help page that can change.

Export: what, how and how often

Can we export all of our data, or only some of it? Many platforms offer an export button that covers the main records but omits attachments, comments, version history, audit logs, user permissions, custom fields or automation rules. Ask for a list of exactly what is included and what is not. If something is excluded, ask whether it can be obtained another way.

Is the export self-service or by request? A self-service export that you can run any time is very different from a request to support that takes weeks and may incur fees. Ask about how long it takes for large accounts, whether there are size limits, and whether you can schedule regular exports rather than only a one-off at the end.

What formats are available? Open, widely supported formats such as CSV, JSON, XML or standard database dumps are far preferable to proprietary formats. Be wary of exports delivered only as PDFs or screenshots, which are readable by people but not usable by systems. European guidance on portability makes the same point: documents in formats that prevent easy extraction of data should not be considered machine-readable.

What does the API allow, and what are its limits? For large datasets, the API is often the practical route to a complete export. Ask about rate limits, whether all objects are accessible through the API, whether API access continues on lower tiers or after you give notice, and whether API usage is charged.

Export quality: will it be usable elsewhere?

This is the question that most evaluations skip and the one that matters most.

Does the export preserve relationships between records? Your data is not just a pile of rows. Customers link to orders, orders to invoices, tasks to projects, comments to authors. An export that delivers each table separately without stable identifiers that tie them together creates a reconstruction job that can take weeks. Ask whether each record has a consistent unique ID and whether related records reference those IDs.

Is there documentation of the data structure? A data dictionary or schema description explains what each field means and how tables relate. Without it, your team or your next vendor has to guess. Ask whether documentation exists and whether it is kept current.

Are attachments, images and files included, and at what quality? Documents attached to records are often the most valuable part of an account and the most easily omitted. Confirm that files are exported in their original form with a clear link back to the records they belong to.

How are dates, currencies, time zones and special characters handled? Small formatting inconsistencies cause large problems at import. Ask for a sample.

Exit process and timing

What happens to our data when the contract ends? Ask how long the platform keeps your data after termination, whether you retain read-only access for a period, how and when data is deleted, and whether you can get written confirmation of deletion. Without clear terms, you may find that your account is shut down on the last day with no time to retrieve anything, or that your data lingers for years without your control.

How much notice is required, and what assistance does the vendor provide? Under the EU Data Act, notice is capped for covered services and providers must support switching, but outside that framework you are relying on the contract. Ask whether transition support is included, what it costs and what the timeline looks like.

What are the fees at exit? Some vendors charge for data extraction, for professional services to assist with export, or for extended access during transition. Ask for these in writing. For covered services in the EU, switching charges are scheduled to disappear from January 2027, but early termination fees on fixed-term contracts can remain, so read the term and renewal conditions closely.

Do contracts auto-renew, and how can we stop that? Automatic renewal with a narrow notice window is a quiet way to extend a relationship you intended to leave. Mark the dates in your calendar on the day you sign.

Integrations, backups and independence

Can we keep our own copy continuously? An exit-day export is useful but risky. Better is the ability to replicate your data regularly to storage you control, such as a data warehouse or secure cloud bucket, through scheduled exports or integrations. That also protects you against the less dramatic risks: accidental deletion, account lockout or vendor outage.

Does the vendor's backup replace ours? Vendor backups exist to restore the vendor's service after a failure. They are not designed to let you recover from your own mistakes, such as a mass deletion by an employee, and they may not be accessible to you at all. Ask what recovery options customers have, what retention periods apply, and whether independent backup tools support the platform.

What happens to connected apps and automations if we downgrade or leave? Integrations built on the platform's API or marketplace may stop working, and the logic you built inside automation tools is rarely portable. Document those workflows outside the platform so they can be rebuilt.

Privacy, location and subprocessors

Where is our data stored and processed, and who else touches it? Ask for the data location, the list of subprocessors, and how changes to that list are communicated. If you operate under data residency requirements, confirm that the platform can meet them in practice, including for backups and support access.

How do deletion requests work end to end? If a customer asks you to delete their data, can you delete it in the platform and in backups, and how long does it take? The ability to honor your own obligations depends on the vendor's capabilities.

Vendor stability and continuity

What happens if the vendor is acquired, changes its terms or shuts down? Ask whether the contract gives you rights if control of the company changes, whether you receive notice of material changes, and whether there is any arrangement, such as data escrow or a guaranteed retrieval period, in the event of discontinuation. For smaller or younger vendors, this is not a theoretical concern.

How have they handled past changes? Product roadmaps shift. Ask how the vendor communicated previous pricing or feature changes, and whether longtime customers were protected. References from customers who have been with the vendor for years are more informative than any brochure.

Test Before You Commit

Answers on a sales call are promises. A test is evidence. The most reliable way to evaluate portability is to run the exit process during the trial or pilot, when you have little data and the stakes are low.

Start by loading a realistic sample of your own data, including the awkward cases: long text, special characters, attachments, records with many relationships and records with missing fields. Then export everything the platform allows, using the standard tools. Look at what you receive and compare it against what you entered.

Check whether every record arrived, whether relationships are intact, whether attachments are included and linked, whether history and comments are present and whether dates and numbers are formatted consistently. Then try to open the export in another tool or import a sample into a different system. The point is not to migrate, but to learn how much work migration would involve.

Also try the API if you plan to rely on it. Pull a larger volume and watch for limits and errors. Finally, ask support a question about exports and note how quickly and clearly they answer. The way a vendor responds when you ask about leaving tells you something about how it will behave when you actually leave.

Write down what you find, including the gaps. If the gaps are serious, ask the vendor to close them or accept them knowingly, with a plan for mitigating them, such as regular exports of the missing elements through other means.

Contract Terms Worth Seeking

If you have negotiating power, even modest, a few clauses are worth asking for. Smaller customers often accept standard terms, but vendors will agree to reasonable clarifications more often than buyers expect, particularly during the sales process when they want the deal.

Look for an explicit statement that you own your data, with a clear definition of what that includes. Look for a right to export in a standard format at any time during the term and for a defined period after termination, at no additional charge or at a stated rate. Look for commitments on retention and deletion after exit, with written confirmation. Look for limits on the vendor's secondary use of your data, including for AI training. Look for notice obligations for changes to terms, pricing and subprocessors, and a right to terminate without penalty if the changes are materially adverse. Look for provisions covering vendor insolvency or change of control. And if you are subject to EU rules, check that switching provisions and timelines match what the Data Act requires for covered services.

Ask a lawyer to review significant agreements, especially where regulated or sensitive data is involved.

Common Mistakes

Trusting the phrase "you own your data." It is usually true and rarely sufficient. Ownership without practical export is a weak protection.

Evaluating export only at the end. By the time you need to leave, the vendor has the leverage, and your team is under pressure. Test early.

Assuming an export button means portability. Check what is excluded and whether the output is usable.

Ignoring derived and configured data. The workflows, templates, dashboards and reports you build often represent months of effort, and they frequently cannot be exported at all. Document them externally.

Letting a single platform become the only copy. When your platform is also your only record, any problem with it is a problem for the business. Keep independent, regular copies of critical data.

Overlooking the people factor. Ask who inside your organization owns the vendor relationship, the admin account and the export schedule. Accounts tied to one person's email or one departed employee are a common cause of lockout.

Skipping the AI questions. New AI features often come with new terms. Revisit data use clauses when a vendor adds them.

Match the Scrutiny to the Stakes

Not every tool deserves a full investigation. A team's whiteboarding app and your customer database are different cases. A reasonable approach is to sort platforms by how critical and how hard to replace they are.

For systems of record, such as CRM, accounting, HR, project and document management, and anything holding customer or regulated data, apply the full set of questions, run the export test and negotiate terms. For important but replaceable tools, ask the main questions about ownership, export and deletion and confirm that you can get a usable copy. For lightweight or experimental tools, a quick check of export options and data use terms is usually enough, plus a rule that nothing irreplaceable lives only there.

This proportionate approach keeps procurement moving while concentrating effort where the consequences of getting it wrong are highest.

Build Habits That Keep You Free

Portability is not a one-time check. It is a habit.

Keep a simple register of your key platforms: what data each holds, who administers it, where the contract and renewal date are recorded, what export options exist and when the last export was taken. Schedule regular exports of critical data, and verify them occasionally by opening them. Store copies somewhere you control, with appropriate security.

Review the register once a year, or when a vendor changes its terms or ownership. As part of any digital transformation program, treat the question "how would we leave this?" as part of the design, not an afterthought. The same attention that goes into choosing a platform should go into making sure you can leave it on your terms.