A lot of SaaS teams say they believe in customer ownership of data.
The real test is what happens when a customer wants to leave.
Can they export the right data without raising three support tickets? Can another provider understand the format? Can the customer see what is portable, what is not, and what will happen during the handover? Or does the whole thing quietly depend on a senior engineer, a one-off database script and a nervous Friday afternoon?
That question is becoming much harder to dodge.
The EU Data Act has been applicable since September 2025 and includes rules designed to make it easier for customers to switch between data processing services. That phrase sounds narrow, but it can include cloud, edge, IaaS, PaaS and SaaS services where they meet the definition. For UK companies serving customers in the EU, the point is simple enough: portability and switching are moving from nice-to-have product polish into commercial, contractual and operational reality.
This is not legal advice. It is a product argument.
If your software creates friction when a customer needs to export, migrate or run a sensible exit process, the problem is no longer confined to the terms and conditions. It lives in the product.
Why this matters to UK SaaS companies
It is tempting for UK teams to look at an EU regulation and file it under “probably someone else’s problem”.
That would be optimistic, which is one of the more expensive forms of engineering strategy.
Like several recent EU digital rules, the Data Act can matter beyond companies physically established in the EU. If a UK SaaS provider serves EU customers, it may need to understand whether its services fall within scope and what obligations follow. Addleshaw Goddard has described the Act as a major change for SaaS contracts, including switching rights, maximum notice periods, migration obligations and transparency requirements for providers serving EU customers.
The practical direction of travel is clear even before you get into the legal edge cases: customers should be able to move their exportable data and digital assets with less friction. Providers should not build commercial, technical or organisational obstacles that make leaving unnecessarily difficult. Switching charges are being phased out, with broader removal of switching and egress charges due from January 2027.
For product-led teams, that changes the tone of the conversation.
Data export stops being a low-priority settings page. Contract wording, customer success playbooks, support processes, data models, API design and pricing decisions all need to line up.
Portability is not just a CSV button
Most SaaS products technically have an export feature somewhere.
That does not mean they have portability.
A CSV download might be useful for a spreadsheet. It may be almost useless for a customer trying to move a live workflow, preserve historical context, rebuild integrations, or demonstrate continuity to their own stakeholders.
A more serious portability model asks better questions:
- What categories of customer data can be exported?
- Which metadata is needed to make the export intelligible?
- Which system-generated records belong in the customer’s operational history?
- What is excluded because it is genuinely proprietary, sensitive or security-relevant?
- How will the customer know the difference before they start the process?
- Can the export run reliably for a large account, not just a demo tenant?
That last point matters. A feature that works for a 20-row test account but collapses under a real customer’s data is not an exit strategy. It is theatre with a progress bar.
The European Commission’s own materials emphasise the goal of reducing barriers to switching between data processing services and preventing vendor lock-in. That means the user experience around exportability matters just as much as the legal statement that export is available.
The product work hiding inside the regulation
The useful way to read this is not “what is the minimum wording we need in the contract?”
The useful question is: “what would a calm, supportable switching process actually require from the product?”
For many SaaS teams, the answer will cut across several areas.
1. Data maps need to become real artefacts
If only one engineer knows where customer data lives, the business does not have a data map. It has folklore.
A portability-ready product needs a maintained view of the data it stores and generates. That does not have to be a hundred-page compliance shrine. It does need to be good enough for product, engineering, support and commercial teams to answer basic questions consistently.
For each major data type, teams should know:
- where it is stored
- who owns it conceptually
- whether it is customer-provided, system-generated, derived or internal
- whether it can be exported safely
- what format makes sense
- what dependencies or relationships must be preserved
This is useful beyond compliance. It improves onboarding, incident response, migrations, analytics and security reviews. Boring documentation earns its keep eventually. Usually at 2am.
2. Export design needs proper product thinking
Good export design is not just a back-office engineering task.
Customers need confidence before they start. They should be able to see what will be exported, how long it is likely to take, what format they will receive, and whether any parts of the service will be affected. If the export is too large for a simple download, there should be a sane delivery mechanism. If the process needs support involvement, that should be explicit rather than discovered through failure.
This is where product teams can turn a regulatory burden into a trust signal.
A clear export centre, documented schemas, API-based access, status updates and audit history all say the same thing: “we are not afraid of your data leaving, because we have built a product good enough for you to stay by choice.”
That is a much healthier retention strategy than making the exit route unpleasant.
3. Contracts and UI cannot contradict each other
One common SaaS failure is letting the contract promise something the interface cannot support.
If the terms say customers can export data within a defined process, the product should not hide that process behind vague support language. If the sales team says migration assistance is available, customer success needs a playbook. If switching timelines are part of the commercial promise, engineering needs enough automation to avoid every request becoming bespoke work.
The EU Data Act discussion has focused heavily on contract terms, notice periods and migration support. Those are important. But in a product-led company, the contract should describe a process that actually exists.
Otherwise the gap becomes operational debt.
4. Exit work should be rehearsed before it is urgent
A switching process is one of those things that looks fine until a real customer, under real pressure, tries to use it.
Run internal drills. Pick a representative account. Export the data. Rebuild enough of the customer state somewhere else to prove the format makes sense. Time the process. Note where someone had to use undocumented knowledge. Fix the worst friction.
This does not need to become a huge programme. It does need to be more than “we think it should work”.
The best teams will treat this like backup restoration. The existence of a backup is not the same as the ability to restore. The existence of an export button is not the same as the ability to switch.
Why this is also a commercial issue
Portability work can feel uncomfortable because it appears to make leaving easier.
In practice, customers already know when they are locked in. Procurement teams know it. Technical buyers know it. Regulated customers definitely know it. If your product makes exit planning feel impossible, that can make the initial purchase feel riskier.
A credible portability story can help sales rather than harm it.
It gives buyers confidence that they are not stepping into a black box. It makes security and governance reviews easier. It supports enterprise conversations where exit plans, continuity and supplier risk are now normal buying criteria.
This matters especially for UK SaaS teams selling into Europe, financial services, healthcare, public sector-adjacent organisations, or operationally mature SMEs. The buyer is not only asking “does this feature work?” They are asking “can we trust this vendor as part of our operating model?”
Good portability is part of that answer.
What to do next
A sensible first pass is not complicated.
Start with a short scope review. Which products, modules and customer groups might be affected? Do you serve EU customers? Are you providing something that could be treated as a data processing service? Where the answer is unclear, get proper legal advice rather than guessing from a blog post, including this one.
Then do the product work:
- map the main categories of customer data and metadata
- document what is exportable, excluded, and why
- review the current export experience from the customer’s perspective
- test exports on realistic accounts, not toy data
- align contract wording, help docs, sales promises and support playbooks
- identify engineering gaps in APIs, file formats, background jobs and audit logs
- decide how switching requests will be owned internally
None of this is glamorous. That is fine. The most valuable product work often looks unglamorous until the day it saves a renewal, passes a procurement review or prevents a painful escalation.
The bigger lesson
The EU Data Act is part of a broader shift: software companies are being asked to prove they can operate responsibly, not just ship quickly.
That does not mean every small SaaS team needs a heavyweight compliance department. It does mean product decisions need to carry more operational maturity than they did a few years ago.
Data portability is a good example because it reveals how the company thinks. A messy export process usually points to deeper issues: unclear ownership, weak data modelling, undocumented assumptions, fragile background jobs, and a culture that treats customer trust as a slogan rather than a system.
A clean switching process says something better.
It says the product is understandable. It says the team knows where the data lives. It says the company is confident enough to let customers leave without turning it into a hostage negotiation.
For BPS Designs, that is the interesting angle. Portability is not just regulatory admin. It is a product quality signal.
And in 2026, that signal is getting harder for serious buyers to ignore.