There is SWIPO and OpenAPI; there is no need to reinvent the wheel.
One might summarize Arcep’s recommendations on interoperability and portability of cloud services as follows.
In the background, the SREN law (“securing and regulating the digital space”), enacted in May 2024. It introduced in French law certain measures from the Data Act ahead of time, which would not apply until September 12, 2025.
Article 28 requires CSPs to comply with interoperability and portability requirements, while providing free APIs to implement these requirements. The idea is to foster both multi-cloud usage and provider switching.
The SREN law tasks Arcep with detailing the rules and the modalities for implementing the requirements. In particular, by issuing specifications. The authority ultimately opted for best practices, in this recommendation “made without any normative scope.” It thus leaves the European Commission to develop the specifications in question. Several elements motivated this choice. The contributions to the public consultation conducted between October and December 2024 are one factor. The SREN law’s implementation timetable is another (the interoperability provisions will apply only until January 12, 2027). As are the timelines that would be required to comply with any binding rules Brussels might impose, which could be layered with implementing acts.
The Arcep Reaches for the SWIPO Baseline
On interoperability and portability, a majority of responses to the public consultation suggested relying on work already conducted in the sector. At the forefront are the SWIPO codes (Switching Cloud Providers and Porting Data). The initiative has ended, but the ecosystem still broadly recognizes its relevance. Arcep has therefore taken up the main lines again, starting with the IaaS-related code. It invites CSPs to publish, in an open format (web page or PDF) and in a machine-readable format, the following information:
- Data (raw or derived) and digital assets that can be transferred during a migration or during simultaneous use of services from different providers
- Procedures to initiate a migration from the cloud service
- Procedures to initiate a migration to the cloud service
- Methods (upload, API, disk shipping) available for migration and simultaneous use of services from different providers, including available protections (encryption) and known restrictions and technical limitations; methods to ensure data security during transfer (access control, user authentication, confidentiality and integrity)
- Procedures to test the different migration mechanisms, notably backup (snapshot), restore (rollback) and data integrity verification
- Processes available to ensure data integrity, service continuity and to prevent data loss during migration
- Termination procedures for an existing cloud service when the client wishes to discontinue its use after migration
- Available monitoring tools for the migration and the costs associated with their use
- Formats available, recommended or used in the context of a migration or multi-provider use, along with the specifications and documentation related to these formats
- API documentation references enabling the implementation of portability and interoperability
- Description and documentation of dependencies, including code libraries, data linked to other cloud services of the provider, and third-party services and tools required to export data for migration or multi-cloud use
API: a 12-Month Notice for Non-Backward-Compatible Updates
Regarding the provision of stable, well-documented APIs, contributions highlighted the OpenAPI specification, widely used by many cloud providers. Arcep considered that promoting it would help avoid major changes and preserve a degree of flexibility. It leaves the door open, however, to adopting equivalent specifications, particularly for APIs that do not rely on the HTTP protocol.
Compared with the preliminary version of its recommendations, released for consultation in June–July 2025, the authority clarified the notion of backward compatibility. It considers that backward compatibility is not guaranteed if an update:
- causes a previously successful request or operation to fail;
- forces customers or third-party providers to take measures to avoid a service interruption; or
- removes a feature or functionality of the service used by customers or third-party providers.
Arcep recommends that, when issuing non-backward-compatible updates, users be informed at least 12 months in advance. Unless there are legal obligations or safety imperatives (such as the discovery of a vulnerability in an API).
