What Would It Take To Leave?

From 12 January 2027, the EU Data Act bans switching charges for cloud services, contact centre platforms included. In a contact centre, the fee was never most of what kept you there.

Beyond The Dial Tone · Architecture Note · September 2026

On 12 January 2027, a clause in the EU Data Act that few contact centre buyers have read takes full effect. From that date, providers of cloud services, software as a service included, may no longer impose switching charges on customers in the EU. No fee for the switching process. No egress charge on the data as it leaves.

It will be reported as the end of lock-in. It is nothing of the sort.

The Act removes a real cost. For an estate with years of recordings and transcripts, egress is not a trivial one. But the larger cost of leaving a contact centre platform was never on an invoice. It sits in the logic you built inside one vendor’s designer, in the behaviour you inherited from that vendor’s defaults and, increasingly, in AI agents whose instructions move far more easily than their behaviour.

The useful question is what it would take to leave and have the contact centre still work the next morning.

What the law actually gives you

Credit where it is due. The switching provisions have applied since 12 September 2025, including to contracts signed before that date, and they are more concrete than most people realise. The fee ban is the next milestone, not the start of the regime.

A customer can start a switch on no more than two months’ notice, whatever the contract term says. The move itself should complete within a transition period of 30 calendar days, during which the provider must give reasonable assistance, keep the service running and support the customer’s exit strategy. If 30 days is technically unfeasible, the provider has 14 working days from the request to say why and propose an alternative of up to seven months, and the customer may extend the transition once. After it ends, the customer has at least 30 calendar days to retrieve its data.

Until 12 January 2027, providers may still charge for switching, but only at cost. From that date, switching charges are prohibited outright.

Two exceptions are worth knowing. The fee ban does not reach services where most of the main features were custom-built for one customer and the provider does not sell them at scale from its catalogue, and the whole regime skips non-production versions supplied for a limited time for testing. A catalogue platform that you configured heavily is still a catalogue platform.

The law also forces something onto paper. The contract must carry an exhaustive specification of the data and digital assets that can be ported. It must also carry a second exhaustive list: the categories of data, specific to the internal functioning of the service, that the provider will withhold because exporting them would risk its trade secrets. The Act adds that those exemptions must not impede or delay the switch.

Read both lists carefully, and the second one twice. It is the vendor’s written statement of what it keeps. What neither list gives you, on its own, is an inventory of what you depend on. A category like “configuration” is the beginning of that conversation, not the end of it.

Machine-readable is not machine-runnable

The Data Act does contain a test for whether a switch has worked. It calls it functional equivalence: re-establishing a minimum level of functionality in the new service, such that the destination delivers “a materially comparable outcome in response to the same input” for the features both services share.

That is the best description of a successful contact centre migration I have seen written into law. Same caller, same reason for calling, comparable outcome.

The obligation to facilitate it applies to infrastructure. Article 30 requires providers of infrastructure services, meaning servers, networks and the virtual resources that run them, to take all reasonable measures to help a customer achieve functional equivalence. Providers of everything else, SaaS included, must make open interfaces available free of charge, with enough information to let software be written against them. Where no common interoperability specification or harmonised standard has been published for the service type, the fallback is an export of the customer’s data in a structured, commonly used and machine-readable format. And no provider is required to develop new technology, or to hand over anything protected as intellectual property or a trade secret.

Those are real obligations, and a working interface is worth more than a download. Neither promises that what comes out will run anywhere else. In practice, for most of what a contact centre is made of, you will get it back as files.

Your routing flows, IVR logic, queue definitions, skills model, schedules and bot designs are configuration expressed in one vendor’s designer. The Act’s recitals treat configuration metadata as a digital asset, so much of it should come out, subject to rights of use and the trade-secret carve-out. What comes out describes the settings without the machinery that gives them meaning. Another platform may import some of it. The rest has to be re-expressed in a different engine with different primitives, and somebody then has to establish what each journey is supposed to do and test the replacement against it.

Being able to read a file is not the same as being able to run it.

What a contact centre is made of

It helps to be precise about what actually has to move, because the Data Act helps with some of it a great deal and with the rest hardly at all.

Data. Recordings, transcripts, contact history, quality evaluations, workforce management history. Portable, free of switching charges from January, and the part the law actually fixes. Getting the records out is one task. Preserving the relationships between them is another.
Numbers and carriers. These move under telecoms porting rules older than the Data Act, and carrier contracts have terms of their own. Plan them separately. A switching-charge ban was never going to solve them.
Configuration. Flows, routing rules, queues, skills, dispositions, bot designs. Portable as files, not as function. The law helps you read it. It does not help you run it.
Behaviour. Everything the platform does that you never configured. How the routing engine breaks a tie between two eligible agents. What happens when a timeout fires. How the intent model scores an ambiguous utterance. What a bot falls back to when it loses the thread. Little of this is in the export, because little of it was ever yours, and much of it is precisely the provider intellectual property the Act excludes.
Knowledge. Why flow 14 has a branch for bank holidays. Which queue is really a workaround for a CRM defect. Who agreed the callback rule, and why. This lives in people, and it rarely survives the change of team that comes with a change of platform.

The fourth item is the one that catches people. In Who Turned This On? the problem was a default nobody chose, running quietly for years. At exit, defaults become the problem again, in reverse. The export contains what you configured, not what you inherited. Replicate every setting you ever touched on a new platform and the contact centre will still behave differently, because the defaults underneath are different and nobody wrote down which ones you were relying on.

Some of those differences will be harmless. Some will be improvements. Others will change who gets help, how quickly and with what information. The export alone will not tell you which is which.

This is also why capability parity tells you so little about exit risk. In the 60-capability benchmark, 36 of the rows score every platform identically. Two platforms can both route on skills, both offer callback and both hand over from a bot to a person, and still send the same caller to different places, at different times, for different reasons. A capability matrix tells you whether a feature exists. It does not tell you what happens when your customer uses it.

The agent you cannot export

AI agents make all of this considerably worse.

An AI agent in a contact centre is assembled from parts that look portable: instructions, prompts, tool definitions, knowledge sources, guardrails, escalation rules. Most of those are text or configuration. Most of them could, in principle, be exported.

Its behaviour is not assembled from those parts alone. It emerges from them running on one vendor’s model, orchestration runtime and retrieval implementation, with that vendor’s way of calling tools and handling their failures, shaped by months of tuning against your real traffic. Move the parts to another platform and the same instructions will produce different conversations. A request that used to be escalated gets answered. A refusal arrives a turn too late. A tool failure produces a different recovery. Different things get said to a vulnerable customer.

The containment rate you spent a year earning does not come with you. It has to be earned again, and where it gets earned is a choice. Offline, against a test, and then in a controlled rollout is one option. With real customers on the line is the other, and it is the one you get by default.

You can export the prompt. You cannot export the behaviour.

Conversation logs describe what the agent did. They do not recreate the system that produced it. The Act is not blind to this: Article 35 lists application behaviour portability among the things future interoperability standards should address. No such standard exists for contact centre software, and until one does, the fallback is the machine-readable export of your data. The instructions are yours and should be portable. The model underneath belongs to your vendor or, increasingly, to a third party, and the Act does not require either to hand over a trade secret. What your agent actually does sits between the two.

And you do not have to leave to meet this problem. Your vendor will bring it to you at the next model upgrade. The same instructions on a new model version can produce different conversations. Whether the new behaviour is materially comparable to the old is a question that arrives whether you switch provider or not. Exit readiness and change control turn out to need the same evidence.

Write the test the law won’t

If the law only writes a functional equivalence test for infrastructure, write your own for everything else.

The most portable asset a modern contact centre can own is an evaluation suite: a maintained set of representative scenarios, each with the conditions it runs under, the actions the agent may and may not take, and the outcome that should follow. Was the issue resolved? Was the right action taken, or correctly refused? Was the case escalated, to whom, and with what context? Was the required disclosure made? Was a vulnerable customer recognised and treated as one?

Build it from real interactions, with personal data removed, and add constructed cases for the situations that are rare and expensive. Complaints. Bereavement. Financial difficulty. Failed identity checks. Unavailable tools. Requests at the edge of what the agent is allowed to decide, which is the ground covered in Who Is Allowed To Say Yes? A suite that only contains happy paths will certify a replacement that fails exactly where failure is expensive.

A financial-difficulty scenario, for instance, might require the agent to recognise the situation, stay inside its authority and transfer the case with the relevant context attached, and prohibit it from promising a repayment arrangement it cannot authorise. That expectation survives a change of platform even when every technical object underneath it changes.

Routing deserves the same treatment. Describe the caller’s circumstances, the time, the skills and capacity available, and the destination and priority the business requires.

One discipline matters more than the rest. Do not make “the old platform did it” the acceptance criterion. Comparable outcomes are the goal, not identical behaviour, and an exit is a good moment to discover that an inherited default was never an approved policy.

Four properties make the suite an exit asset rather than another piece of vendor configuration:

It lives outside the platform. In a neutral format, under your own version control, owned by the business rather than by whichever team administers the vendor’s tooling.
It speaks the business’s language. Teams, permissions and outcomes, not any platform’s queues, intents or objects. Keep the mapping to the vendor’s names in a separate file.
It specifies conduct, not just results. The steps that must happen and the actions that must not. A correct answer reached through an unauthorised action is a failure.
It runs constantly. Against every model upgrade, every major release and every candidate replacement. For AI, run each case several times and look at the spread, because one good conversation proves nothing. A suite that is only run at exit will be out of date at exit.

Built properly, it turns “a materially comparable outcome in response to the same input” from a phrase in a regulation into a test you can run on a Tuesday afternoon. It will not prove every future interaction safe. It is the evidence you will want in hand when a board asks whether the new platform works as well as the old one.

Before 12 January

The fee ban arrives in under four months. Before it does:

Read the export terms against a real journey. Every in-scope contract should now specify what can be ported and what is withheld as a trade secret. If yours does not, ask why. If it does, ask which flows, routing rules, knowledge, bot configuration and evaluation records you can obtain, in which formats, with which limitations. Where something cannot move, ask what dependency prevents it.
Separate the switching charge from the cost of leaving. The ban covers charges for the switching process. It does not remove early termination penalties, which the Act expects to be disclosed before signing and which remain open to challenge under the usual rules on unfair terms. Nor does it cover assistance beyond the legal minimum, such as converting data into a specific format, which legal commentary expects to stay chargeable where separately agreed. That is precisely the service a contact centre would need to make its configuration useful elsewhere. A fee that disappears from one line of a contract rarely disappears from the contract.
Run an export drill. Take one complete journey: the flow, the routing, the bot, the knowledge and a week of interactions. Export it. Give the files to somebody who did not build it and ask them to reconstruct what the journey does. Time it. Note what was missing, ambiguous or only meaningful on the original platform. That gap is your real exit cost.
Start the evaluation suite now. The best time to write down how your contact centre behaves is while the people who understand it are still there and nobody is arguing about a deadline.

Then put one question to your vendor, in writing, before the renewal: if we left, what would not come with us? A good vendor can answer it specifically and without defensiveness, naming assets, rights, dependencies and limitations. “Your data is portable” does not finish the conversation, and a vendor who cannot get past it has told you something about the relationship you are in.

Where the Act does not reach

The Data Act’s switching provisions protect customers in the EU, wherever the provider is established. For a multinational, that turns on which entity is the customer under each contract and where the service is supplied, so check contract by contract rather than assume one group company’s location settles it. A UK-only operation is outside it.

The UK has taken a different route. On 31 March 2026 the CMA decided not to prioritise strategic market status investigations into the cloud businesses of AWS and Microsoft, accepting actions from both on egress fees and interoperability instead, with the Board to review progress in six months. That review falls due as this is published. On 14 May it opened a separate investigation into Microsoft’s business software ecosystem, with a designation decision due by February 2027. None of that is a contact centre exit regime: the cloud commitments concern infrastructure, and they are undertakings rather than statute. For a UK buyer of a contact centre platform, the rights at exit are the ones in the contract, read alongside whatever general law applies, and there is no Article 25 to fall back on.

That is an argument for negotiating the Act’s terms anyway. Brussels has written a decent checklist: a notice cap, a transition period, assistance obligations, a retrieval window, two exhaustive lists and, since 19 November 2025, a draft set of non-binding model clauses for cloud contracts that includes clauses on switching and exit. Use it, even where Brussels does not reach.

Write down what it does

Leaving exposes the work the platform was quietly doing for you. Some of it belongs to the vendor’s technology. Some of it comes from decisions your organisation made and forgot to record. Some of it survives only because a few people know why the system behaves as it does. That is the pattern this series keeps arriving at from different directions, and an exit is the same test applied to the platform itself.

Lock-in, as I argued in There Is No Best Platform, is a price rather than a sin. What the Data Act changes is where the price sits. Less of it is on the invoice. More of it is in whatever you never documented.

The law will make leaving cheaper. It will not make the replacement work. That part was always yours.

Write down what your contact centre does. Make it a test. Run it while you are happy, and you will know what it would take to leave long before you need to.

Mark McLeish writes about contact centre architecture, enterprise AI and customer experience. Views are his own. Not Accenture’s. Practitioner signal. No vendor PR. Not legal advice; confirm the Data Act’s application to your own contracts with counsel.

Evidence note. Data Act provisions from Regulation (EU) 2023/2854, checked 26 September 2026: Chapter VI switching provisions applicable from 12 September 2025, including to existing in-scope contracts; Article 25 contract terms (maximum two-month notice, 30-calendar-day transitional period, alternative of up to seven months where technically unfeasible with notice within 14 working days, the customer’s right to extend the transitional period once, reasonable assistance and exit-strategy support, at least 30 calendar days for data retrieval, and exhaustive specifications of portable data and digital assets and of withheld internal-functioning data); Article 29 switching charges permitted at cost until 12 January 2027 and prohibited from that date, with pre-contractual disclosure of early termination penalties under Article 29(4); Article 30 functional equivalence obligation limited to infrastructure services, free open interfaces for other services, structured machine-readable export where no common specifications or harmonised standards have been published, and no obligation to develop new technology or transfer assets protected by intellectual property or trade secrets; Article 31 disapplying Article 23(d), Article 29 and Article 30(1) and (3) for custom-built services not offered at broad commercial scale via the provider’s catalogue, and the whole chapter for time-limited non-production test versions; Article 35(2) listing behavioural interoperability and application behaviour portability among the aspects that interoperability specifications and harmonised standards should address; Article 2(37) and 2(38) definitions of functional equivalence and exportable data; Recital 83 on configuration metadata as a digital asset; Recital 86 on functional equivalence. Chargeable services beyond the legal minimum, and the survival of early termination penalties, from legal commentary of September 2025, which notes the boundary with switching charges is not yet settled. Commission draft recommendation on non-binding model contractual terms and standard contractual clauses for cloud computing contracts, including switching and exit clauses, published 19 November 2025. Proposed Digital Omnibus amendments to the Data Act (procedure 2025/0360(COD)), which are separate from the Digital Omnibus on AI discussed in Who Turned This On?, were still in the legislative process at the time of writing and are not relied on. CMA announcement of 31 March 2026 (actions from AWS and Microsoft on egress fees and interoperability, Board review of progress in six months, business software investigation to commence in May) and of 14 May 2026 (strategic market status investigation into Microsoft’s business software ecosystem, to complete within nine months, designation decision by February 2027). The “36 of 60” figure is from the CCaaS 60-Capability Benchmark as discussed in Who Turned This On? No contact centre platform’s export capability was tested for this piece; AWS and Microsoft are named only as parties to the CMA commitments.