The EU Data Act quietly hands European software buyers something they have wanted for two decades: the right to leave a cloud service without paying for the privilege. From 12 January 2027, providers serving customers in the EU will no longer be permitted to charge switching fees when a customer moves to a different provider or brings a workload back in house. For anyone running a CRM estate in Europe, this is one of the most useful pieces of regulation to land in years.
The organisations that gain the most from it will not be the ones that rush to change platform in January 2027. They will be the ones that spend 2026 understanding what their CRM would take to move, and then use that knowledge whether they move or not. Portability turns out to be valuable even when you stay exactly where you are.
What actually changes on 12 January 2027?
The Data Act phases its switching rules in over three years. Since 11 January 2024, providers have only been able to pass through the direct costs of assisting a switch, such as data egress and specific transition support. The core switching obligations became applicable on 12 September 2025. From 12 January 2027, switching charges are prohibited outright: a provider cannot bill you for the act of leaving. The rules cover infrastructure, platform and software services, so a CRM subscription sits squarely inside scope, and they apply extraterritorially. A vendor headquartered in California and serving customers in Stockholm or Barcelona is covered in the same way a European provider is.
The Act does more than remove a line item. It sets out the mechanics of an exit. A customer can begin a switch on a maximum of two months’ notice, and the provider must complete it within 30 days of that notice period ending, with an extension available only where the move is genuinely technically unfeasible. Contracts have to state which data and digital assets are portable and which are not. Providers of software and platform services must offer open interfaces so that the exit route is real rather than theoretical, and they must support running the old and new services in parallel during the transition.
That last detail matters more than the headline. Parallel operation is what separates a migration you can survive from one that puts a quarter of pipeline at risk. Having it written into the contractual baseline, rather than negotiated case by case as a concession, changes how a CRM programme can be sequenced.
Why does this matter more for CRM than for infrastructure?
Most commentary on the Data Act has focused on hyperscalers and egress bills, because that is where the visible fees sit. Yet CRM is where the effect will be felt most, for a simple reason: a CRM is not a place where data is stored, it is where a company’s commercial process is encoded. Account hierarchies, quoting logic, approval chains, territory rules, service entitlements and twenty integrations all live in and around it. The subscription was never the thing holding anyone in place.
This is why the fee ban is best read as an invitation rather than an instruction. The regulation removes the artificial part of the exit cost. What remains is the real part, and the real part is entirely within a buying organisation’s own control. Every hour spent making a CRM more portable is an hour spent making it simpler, better documented and easier to change, which is exactly the work that improves performance on the current platform too.
There is a second effect worth anticipating. Vendors know the date as well as their customers do, and commercial teams tend to respond to a change like this before it lands rather than after. Renewal conversations through late 2026 are likely to be more constructive than they have been, particularly for multi-year commitments that run past the deadline. Buyers who walk into those conversations with a clear, evidenced view of their own portability will get considerably more out of them than buyers who raise the regulation as a talking point.
How do you migrate from one CRM to another?
A CRM migration works best in five stages. First, map the commercial process the current system encodes, not the fields it contains, because processes are what users actually depend on. Second, profile and remediate the data while it is still in the source system, since bad data is cheaper to fix before it moves than after. Third, rebuild integrations against a documented interface layer rather than point-to-point, so the next change is smaller than this one. Fourth, run both systems in parallel for a defined period with a single agreed source of truth for reporting. Fifth, migrate users in cohorts with enablement attached to each wave, measuring adoption rather than assuming it.
The order matters. Teams that lead with data and leave process mapping until late tend to migrate their existing problems faithfully into a more expensive system. Teams that lead with process discover that a meaningful share of what they were about to rebuild is no longer used by anyone, which shrinks the project before it starts. It is common for a serious process review to remove a quarter of the customisation from a migration scope, and that reduction compounds through testing, training and support.
The parallel running provision in the Data Act supports this sequencing directly. When both platforms must be available during transition, cohort migration becomes the natural approach rather than an expensive luxury, and the classic single weekend cutover stops being the default risk anyone has to accept.
What does a CRM migration actually cost?
For a mid-sized B2B organisation, a CRM migration is typically dominated by four costs: data remediation and mapping, integration rebuild, process and configuration redesign, and user enablement. Licence overlap during parallel running adds a defined and predictable amount. Vendor exit fees, the item the Data Act removes, have usually been the smallest line of the five. The practical consequence is that the deadline does not make migration cheap, it makes the remaining cost honest, and every element of that remaining cost is work that improves the commercial operation regardless of which platform eventually runs it.
That reframing is genuinely useful in a business case. A board asked to fund a migration will reasonably ask what happens if the decision changes halfway through. Under the old shape of the question, the answer involved sunk exit fees and wasted effort. Under the new shape, the answer is that the data is clean, the integrations are documented, the process is mapped and the organisation is more capable than it was, whichever platform it lands on. Investment that holds its value under either outcome is much easier to approve.
It also changes what is worth measuring. Rather than tracking migration cost against a one-off project budget, the more informative number is how much a given change to commercial process costs to make. Organisations that get their portability position in order routinely find that figure falling, because the same documentation and interface discipline that enables an exit also enables ordinary change.
What is CRM technical debt, and how does portability reduce it?
CRM technical debt is the accumulated cost of past configuration decisions that made sense at the time and now constrain what the organisation can do next: undocumented custom objects, overlapping automation built by different teams in different years, integrations wired point to point, and fields that are required by a validation rule nobody can trace to a current business reason. It is rarely visible on a balance sheet, but it shows up as slower release cycles, higher support load and quoted timelines that surprise everyone.
A portability review is one of the most efficient ways to surface it, because the question it asks is unusually clarifying. Working out what would need to move, and what could not move, produces a precise inventory of where an estate is entangled. Teams that run this exercise generally report that the findings were more valuable than the exit option itself. They arrive with a prioritised list of simplifications, each attached to a concrete benefit, and most of those items can be actioned on the current platform within a quarter.
This is the part that makes the January 2027 date worth acting on now rather than in December. The regulation guarantees a right to leave. It does not do the work that makes leaving, or staying well, straightforward. That work has its own return, and it starts paying before the deadline arrives.
Why use an independent CRM partner to prepare for this?
An independent CRM partner works across multiple platforms and is not compensated on the licence decision, which matters for a portability review specifically. The output of such a review is an honest assessment of what a given estate would cost to move and what it would gain by staying, and a partner whose commercial interest sits on one side of that answer is not well placed to give it. Independence here is a practical requirement for a credible result, not a marketing position.
There is a second, less obvious argument. Preparing for portability requires knowing what good looks like on more than one platform. Understanding whether a Salesforce customisation has a clean equivalent in Dynamics 365, or whether a HubSpot workflow set translates into something maintainable elsewhere, requires genuine hands-on experience of each. That comparative view is what turns a portability review from a theoretical document into a decision a leadership team can act on with confidence.
For European organisations, this also connects to a wider strategic conversation about digital sovereignty. The value is not in leaving a global platform. It is in being able to make that choice deliberately, on commercial and architectural grounds, at a time of your own choosing. The Data Act makes that choice more available than it has ever been.
The Sirocco perspective
We think January 2027 will prove more significant for what it changes in negotiations and architecture than for the number of organisations that actually switch platform. Most of our clients will stay where they are, and they should. What changes is that staying becomes an active decision backed by evidence, rather than a default produced by the cost of leaving.
The advice we are giving through the rest of 2026 is straightforward. Read your CRM contracts now and note the renewal dates that fall either side of the deadline. Ask your provider, in writing, which data and digital assets they consider portable. Run one real export of a critical object into an open format and confirm you can read it. Then treat the gaps that exercise reveals as an improvement backlog for the platform you are on, because that is what they are.
Organisations that do this arrive at 2027 with cleaner data, documented integrations, a clear view of their own architecture and a much stronger hand at renewal. That is a good outcome whichever logo is on the login screen, and it is available to any team willing to start the work this year. If you would like a view on where your estate stands, schedule a consultation and we will walk through it with you.
Get in Touch
If you are reviewing CRM contracts ahead of January 2027, or want to know whether your Salesforce, HubSpot or Dynamics 365 estate could genuinely move if you asked it to, a short conversation about your portability position is a good place to begin.
