EU Data Act and the End of Switching Fees: How SaaS Startups Should Prepare Data Exports, APIs and Contracts by 12 January 2027

For a SaaS startup selling to customers in the European Union, 12 January 2027 is more than a billing deadline. From that date, the EU Data Act ends switching charges for the switching process covered by the Regulation, including data egress charges associated with moving a customer to another provider or to its own ICT infrastructure. The wider switching rules are already relevant because the Data Act has applied since 12 September 2025. This means that a startup preparing during 2026 should look at the whole customer exit process rather than simply deleting a migration fee from its price list. Data exports must be usable, open interfaces must support portability, contracts must describe switching rights clearly, and internal teams must be able to complete an exit without creating unnecessary commercial or technical barriers. For most standard SaaS businesses, the practical objective is straightforward: a customer should be able to leave with the data and digital assets it is entitled to take, while the provider continues to protect its own intellectual property, trade secrets and security-sensitive information.

What Changes for SaaS Providers on 12 January 2027

Regulation (EU) 2023/2854, better known as the EU Data Act, expressly treats Software as a Service, Infrastructure as a Service and Platform as a Service as forms of data processing services. The rules can therefore reach a conventional SaaS startup offering CRM software, accounting tools, project management applications, analytics services, HR software or another remotely delivered business application. The provider does not have to be incorporated in the EU: the Data Act covers providers of data processing services regardless of their place of establishment when they provide those services to customers in the Union. A US, UK or Swiss SaaS company serving EU customers can consequently face the same switching requirements for those services as an EU-based startup.

The most visible change arrives through Article 29. Until 12 January 2027, a provider may impose reduced switching charges, but those charges cannot exceed costs directly linked to the particular switching process. From 12 January 2027, switching charges for the regulated switching process must disappear. The definition includes data egress charges, so a startup cannot simply rename an export or migration charge and continue billing it when the work forms part of the provider’s mandatory switching duties. This matters for businesses that currently charge for bulk exports, migration assistance, account closure or transferring customer data to another service. During 2026, each of these charges should be classified according to what it actually pays for rather than according to the wording used on an invoice.

The change does not make every service connected with departure free. Standard subscription fees are not switching charges, and they can continue while the contract remains in force. Early termination penalties are also treated separately from switching charges and may still be possible where they comply with applicable EU and national law. A customer can additionally request professional assistance that goes beyond the duties imposed on the provider by the Data Act, and such extra work can be charged when the customer requests it and agrees to the price in advance. The practical task for a startup is therefore to separate mandatory exit work from genuine optional consultancy. A generic “migration fee” covering both categories is much harder to defend than a pricing model that clearly distinguishes the regulated switching process from additional services requested by the customer.

Check Whether Your SaaS Service and Contracts Are Actually in Scope

Most standard SaaS products offered to many customers through the same commercial service catalogue should be assessed on the assumption that the Chapter VI switching rules apply. There is, however, an important existing exception. Article 31 gives a specific regime to services where the majority of the main features have been custom-built for an individual customer, or all components have been developed for that customer, provided that the service is not offered at broad commercial scale through the provider’s catalogue. For qualifying services, some switching duties, including Article 29 on switching charges, do not apply. Limited non-production services supplied only for testing and evaluation also have a separate exemption. These are narrow conditions, so describing ordinary configuration, branding or customer-specific settings as “custom development” should not be treated as a safe route around the rules.

There is a further 2026 complication that startups should monitor without treating it as settled law. The European Commission’s Digital Omnibus proposal, COM(2025) 837, proposes amendments affecting parts of the Data Act, including aspects of the switching regime for some smaller providers, custom-made services and older contracts. As at September 2026, that proposal remains in the ordinary EU legislative procedure rather than forming part of the law already in force. A startup should therefore base its immediate compliance work on the current Data Act while following the legislative process for changes that may affect legacy contracts. Delaying all preparation in the hope of a future exemption would create a significant operational risk because the current rules already apply.

SaaS providers should also avoid assuming that they must reproduce their application inside a competitor’s environment. The Data Act treats infrastructure services differently from software services when it comes to functional equivalence. For SaaS, the central obligations are more closely connected with removing switching obstacles, making exportable information portable and providing open interfaces. In practical terms, a project-management SaaS business does not have to rebuild its proprietary workflow engine for a rival service. It does need to ensure that a departing customer can obtain the records, outputs, relevant metadata and other portable digital assets covered by the Regulation and can use the available interface and documentation to move those materials without an artificial technical lock-in.

Build Data Exports and Open Interfaces That Can Support a Real Exit

The starting point for product work is the Data Act definition of exportable data. It covers input and output data, including metadata, that are directly or indirectly generated or co-generated through the customer’s use of the service. At the same time, it excludes provider or third-party assets and data protected by intellectual property rights or constituting their trade secrets. For a SaaS startup, this calls for a data inventory based on ownership and use rather than a simple database dump. Depending on the service, exportable information may include records entered by users, generated reports, customer-created content, transaction data, timestamps and relevant metadata. Digital assets for which the customer has a right of use may also include information related to configurations, security settings and access or control rights. Internal algorithms, proprietary source code and protected provider data do not automatically become customer export data.

A useful export must also be capable of moving to another environment. Where no applicable common specification or harmonised interoperability standard has been published for the relevant service type, the Data Act requires exportable data to be supplied, on request in the relevant switching situation, in a structured, commonly used and machine-readable format. For an ordinary SaaS business, formats such as CSV or JSON may be appropriate depending on the nature and relationships of the data, but the Regulation does not prescribe a single universal file type for every service. The important point is that the export should preserve enough structure to make the information practically reusable. A folder containing hundreds of disconnected PDFs may be readable by a person yet still be a poor method of transferring structured CRM contacts, invoices, project records or analytics data to another application.

The provider also has an information duty. Customers must receive information about available switching and porting procedures, including methods, formats, known restrictions and technical limitations. The provider must maintain an up-to-date online register covering the relevant data structures, formats, standards and open interoperability specifications in which exportable data are available. For SaaS and other services that are not pure infrastructure services, Article 30 additionally requires open interfaces to be made available free of charge, to the same extent, to customers and relevant destination providers for portability and interoperability. The law does not say that every SaaS company must use one particular API architecture. An existing well-documented API may form an important part of the solution, while another business may combine export endpoints and other open interfaces. What matters is that software can communicate with the service sufficiently for the required portability and interoperability purposes.

Turn the Export Feature Into a Documented Switching Workflow

A download button is not the same as a complete switching process. The contract must allow switching or porting without undue delay and normally within a mandatory maximum transitional period of 30 calendar days after the applicable notice period. The maximum contractual notice period for initiating the switching process must not exceed two months. This gives a startup a useful operational framework: a switching request should have a clear entry point, a responsible team, an identity-verification step, a confirmed scope of information to be transferred and an agreed route for delivery. Support staff should know when a request is an ordinary account export and when it is a formal switching request involving the rights and timeframes established by the Data Act.

The Regulation recognises that some migrations are genuinely more difficult. If completing the transition within the normal 30-day maximum is technically unfeasible, the provider must notify the customer within 14 working days of the switching request, justify why the normal period is technically unfeasible and state an alternative transitional period. That alternative cannot exceed seven months. The customer also has a contractual right to extend the transitional period once for a period it considers more appropriate for its own purposes. After the agreed transition, the contract must provide a data retrieval period of at least 30 calendar days before the relevant exportable data and digital assets are fully erased in accordance with the contractual and legal requirements. These dates should be reflected in support procedures rather than left for the legal team to calculate after a customer has already announced its departure.

Testing should therefore involve more than checking whether an export file can be generated. A startup can create representative customer accounts containing realistic records, attachments, permissions, relationships, historical information and metadata, then run a complete exit exercise. The team should verify that the export is complete, that relationships between records remain understandable, that authorised users can obtain it securely and that the process does not require an engineer to perform improvised manual work every time. Security commitments must continue throughout switching, and service continuity also matters during the transition. A practical rehearsal can expose simple problems before they become compliance failures: missing metadata, undocumented fields, expired download links, exports that fail on large accounts, unclear ownership between support and engineering, or deletion routines that start before the required retrieval period has finished.

Rewrite Contracts and Pricing Before the Switching-Fee Ban Arrives

Article 25 makes the contract itself a central part of compliance. The customer’s switching rights and the provider’s obligations must be clearly set out in writing, and the agreement must be made available before signature in a form the customer can store and reproduce. Among other matters, the contract needs to deal with switching to another provider or moving exportable data and digital assets to the customer’s own infrastructure, the applicable notice and transition periods, assistance during switching, continuity and security, and the categories of data and digital assets that can be ported. It must also identify categories of internal service data excluded where disclosure would create a risk of exposing the provider’s trade secrets, without using those exclusions to obstruct or delay switching. Retrieval and final erasure rules also need to be addressed.

Pricing language deserves a separate review because an otherwise sound switching clause can still conflict with Article 29. Any switching charges retained during the 2026 transitional period should be traceable to costs directly associated with the relevant switch and should not exceed those costs. For switching covered by Article 29, the pricing model must be ready to remove those charges from 12 January 2027. At the same time, founders do not need to abandon ordinary commercial safeguards. Standard service charges can continue until the relevant contract ceases to apply, and proportionate early termination arrangements remain a separate issue subject to applicable law. Optional migration consulting that goes beyond the provider’s mandatory switching work can also remain a paid service where the scope and price are agreed with the customer in advance. Clear drafting helps prevent a legitimate professional service from appearing to be a prohibited exit charge.

The contract review is also a good moment to make the customer’s exit information consistent across the agreement, website, support centre and technical documentation. The Commission published non-binding Standard Contractual Clauses intended to help businesses implement the Data Act’s switching provisions, including clauses dealing with switching and exit, termination, security and business continuity. They are useful as a drafting benchmark, particularly for a small legal team, but they do not replace the need to adapt terms to the actual product and business model. Providers should also remember the Data Act’s separate transparency requirements concerning the jurisdiction governing the ICT infrastructure used for their services and the measures used to address conflicting third-country governmental access to non-personal data held in the Union. The relevant website information must be kept current, and the websites containing it must be identified in contracts for the data processing services concerned.

Use the Remaining 2026 Window as a Product, Legal and Finance Project

The remaining months before 12 January 2027 are best treated as a cross-functional implementation period. In September and October 2026, a startup can map every customer data category, decide what is exportable, document protected internal information, review current APIs and other interfaces, and identify every fee associated with account closure or migration. The same exercise should identify the contracts used for self-service customers, enterprise customers and individually negotiated deals. Product, engineering, legal, customer support, security and finance should work from the same definition of the switching process. This prevents a common failure in which the contract promises one procedure, the product supports another, and the support team quotes a third.

Before the end of 2026, the company should run at least one full switching rehearsal and amend customer-facing documentation based on what actually happens. Finance should model the loss of switching-fee revenue and, more importantly, the cost of providing mandatory exports and transfer support without charging the departing customer after the deadline. This can expose an upstream issue for SaaS businesses that themselves rely on external cloud services. A startup may incur storage, network or operational costs when moving a customer’s data, so it should review its own supplier agreements rather than discovering those costs during the first large migration of 2027. The Data Act can benefit the startup in its role as a customer of other data processing services as well as imposing duties on the startup in its role as a SaaS provider.

By 12 January 2027, the operational result should be simple enough to explain to a customer without a legal memorandum. The customer can request a switch, obtain the exportable data and eligible digital assets in an appropriate machine-readable form, use the documented interfaces needed for portability, receive reasonable assistance and retain access for the required period while the transition is completed. The provider can continue protecting proprietary technology, trade secrets and security-sensitive information, can collect ordinary service fees while the contract remains applicable and can charge separately for genuinely additional work requested by the customer. Preparing in this way turns Data Act compliance into a defined exit process rather than an emergency response to the first customer who cites Article 29 after 12 January 2027.