Leaving Microsoft, 7/7: keeping the freedom to choose

Can a service built on Google technology win a European sovereign cloud contract? On 17 April 2026, the European Commission gave a concrete answer. It awarded four contracts with a combined ceiling of €180 million over six years. The successful bids included Proximus with S3NS, Clarence and Mistral, an offering whose Google Cloud technology the Commission describes as operated exclusively by European companies. It received a SEAL 2 rating. The offerings from Post Telecom with OVHcloud and Clever Cloud, STACKIT, and Scaleway reached SEAL 3. The announced amount is a contractual ceiling; actual spending against it remains to be established. ^[1]

The result invites a closer look at the dependencies behind a supplier’s address: which dependencies is the buyer willing to accept, for what service, and with what ability to reduce them? The origin of the technology, the company operating it and the customer’s rights are separate layers. This procurement shows how they enter a public decision.

This final instalment follows the work that continues after a migration. It asks how freedom of choice passes to the next contract, the next provider and the people who will inherit the system. European rules, French contract clauses and British operational guidance make that freedom something a public body can examine.

Assessing a sovereign cloud offering

The Commission’s framework examines eight objectives. They cover areas including legal control, operations, the supply chain, technology, data and artificial intelligence, security, and environmental sustainability. Sovereignty becomes an assessment of several dependencies within a particular offering. The October 2025 framework sets out a scale from zero to four called SEAL, short for Sovereignty Effectiveness Assurance Levels. ^[2]

Each objective must meet the required threshold. The implementation guide published in June 2026, explaining the calculation used in the completed procurement, specifies that the overall level is the lowest of the eight individual levels. This procurement required at least SEAL 2. Falling below that threshold on one objective therefore means rejection, even where other dimensions score highly. ^{[2] [3]}

A separate calculation then contributes to the quality assessment of eligible bids: a weighted sovereignty score. The supply chain carries a weight of 20%, compared with 5% for environmental sustainability; the other weights appear in the diagram. This calculation helps distinguish the quality of bids under the procurement criteria. It serves a different purpose from the minimum threshold. ^[2]

Method and scope

European Commission framework, version 1.2.1 of October 2025, and implementation guidance published in June 2026. The overall SEAL level is the lowest level across the eight objectives. The procurement required a minimum of SEAL 2. Percentages are the weights in the complementary score contributing to the quality assessment, rather than market shares or providers’ scores. SEAL levels are ordinal. No individual score missing from the documents has been reconstructed. [2] [3]

The method makes the buyer specify an acceptable level of dependence. It also explains how offerings rated SEAL 2 and SEAL 3 can appear in the same award. Those ratings describe an assessment under this procurement’s criteria and evidence. The award announcement leaves a further question unanswered: how would each service perform during an actual migration or a disruption in its supply chain? Our sources include no reports of such tests. ^[1]

For an administration considering a departure from Microsoft, the approach suggests examining the dependencies retained at the destination. A European operator may use technology developed elsewhere; open source software may rely on expertise concentrated in one provider. Decisions become more precise when contracts, architecture and training address those dependencies explicitly.

Protecting data and preparing to move it

In France, guidance from the Direction des affaires juridiques, the legal affairs directorate known as the DAJ, updated on 21 August 2026, explains the application of Article 31 of the SREN law on securing and regulating the digital environment. The regime covers certain particularly sensitive data entrusted to private cloud providers by the state administrations, public bodies and public interest groupings within its scope. It considers both the nature of the data and the potential consequences of a breach. Personal data and sensitive data as defined by this law may overlap: buyers must assess the legal criteria for their own project. ^[4]

The guidance explains the decree of 14 April 2026 and the order of 12 August approving the SecNumCloud 3.2 requirements. The framework addresses, among other risks, access by authorities of countries outside the EU without a legal basis in Union or member state law. Its requirements, procedures and exemptions apply to the entities and data concerned. A blanket description covering all French public sector cloud use would lose those conditions. ^[4]

SecNumCloud also contains provisions relevant to an exit. Its contractual requirements cover the recovery of data entrusted to the provider and data generated through the customer’s use. The provider must offer files in documented formats usable outside the service, or technical interfaces following a documented and usable schema. These interfaces are points through which software exchanges information. The arrangements belong in the service agreement and give practical content to reversibility: the ability to take a service back or have it taken over elsewhere. ^[5]

A recovered file still has to become part of a working service. A case file may arrive with its contents while the rules governing who can read it remain tied to the old environment. Access then has to be rebuilt and checked at the destination. The cloud exit guide from NHS England describes this risk: read and write permissions associated with data may be difficult to translate meaningfully between environments, and identity mechanisms differ between providers. ^[9]

Protection during hosting and the ability to resume work elsewhere complement each other. To assess the latter, buyers need to follow the data through to the task it supports. That connects with the dependencies between workflows and applications examined in the fourth instalment.

A contract must hand over the means to operate

French public procurement already has provisions for this handover. The CCAG-TIC, the general administrative terms for public IT contracts, provides for a reversibility or transfer plan. Within the applicable scope, Article 38.4 lists files in documented formats, configuration information, scripts, documentation and existing training materials. Source code is included where appropriate. Article 42 provides for the access needed by the buyer or incoming contractor, while preserving security and continuity during the transfer. These terms apply to contracts that expressly refer to the CCAG, subject to any departures specified in their own contract documents. ^[6]

The annex to the DAJ’s August 2026 guidance goes further for certain bespoke developments. It proposes giving the buyer rights to code, components and interfaces developed for its cybersecurity or digital sovereignty needs. The provider would progressively deliver the materials needed to operate and develop them, with current documentation, throughout the contract. These are model clauses for incorporation into an agreement. They do not automatically transfer ownership of every product used or rights to pre-existing components: the guidance distinguishes the results of the contract from prior intellectual property. ^[4]

Consider an interface developed to connect an email tool with a case management system. This is an illustrative example. The next provider needs to understand how to install, configure and fix that interface, and to have the rights to do so. Progressive delivery lets the public body’s team check those elements while the outgoing provider is still maintaining them. Late discoveries risk piling up just as the teams are managing the handover.

Broader rights also carry an economic trade-off. The DAJ warns that exclusive ownership can make a solution more expensive, because the provider has fewer opportunities to recover development costs from other customers. Buyers need to select rights appropriate to future use, alongside their cost and the arrangements for maintenance. That decision extends the discussion of funding the transition. ^[4]

Where the thirty days fit

The EU Data Act offers another mechanism and has applied since 12 September 2025. Its chapter on switching providers covers data processing services within its definition, including cloud services. An application installed on a computer therefore does not automatically fall within this regime. The rules concern providers offering these services to customers in the Union, wherever the provider is established. ^[7]

Article 25 requires the contract to set out the switching arrangements. The maximum notice period is two months. After that notice period, the transition should normally take no more than thirty calendar days. Customers then have at least thirty calendar days to retrieve their data, starting at the end of the agreed transition period. Erasure follows that retrieval period, or a later agreed date, subject to successful completion of the switch. Each period governs a particular operation. ^[7]

The same article allows for technical infeasibility of completing the normal transition. Within fourteen working days of the switching request, the provider must notify the customer, give its justification and specify an alternative transition period of no more than seven months. The customer may also extend the transition once, for a period it considers appropriate. These provisions need to be read together. Thirty days is not a universal promise that an entire migration will be complete. ^[7]

Reading the legal timetable

Article 25 of Regulation (EU) 2023/2854. Notice is capped at two months; the normal transition at thirty calendar days after notice; the minimum retrieval period is thirty calendar days from the end of the agreed transition. Erasure depends on successful completion of the switch and may be postponed by agreement. Technical infeasibility must be justified within fourteen working days of the request; the alternative transition is capped at seven months, with no final calendar date calculated here. A single extension requested by the customer is a separate provision. Graphic lengths are not proportional to duration. The FAQ explains the technical scope of the obligations. [7] [8]

The technical scope matters as much as the timetable. The obligation to take reasonable measures to facilitate functional equivalence concerns infrastructure as a service, or IaaS: computing, storage and networking resources. It does not apply in the same way to a complete software application delivered as a service, or SaaS. The Commission’s FAQ also explains that the outgoing provider need not rebuild the service in the destination environment. Its duties to assist and provide information about its own environment remain relevant. ^{[7] [8]}

The regulation requires, among other information, a description of the categories of exportable data and digital assets, the methods and formats available, and known technical limitations. Exportable data include inputs, outputs and certain metadata generated through use; the definition preserves the intellectual property rights and trade secrets of the provider and third parties. That makes a specific document central to scrutiny: the description of what can leave, what stays behind and what the receiving system will be able to use. ^[7]

Rehearsing an exit while the service still works

NHS England recommends preparing for an exit when entering the cloud. Its guide provides for a transition in which environments may run alongside each other, with acceptance testing, data quality checks and a rollback option. It recommends at least an initial exercise on paper. This is published guidance for healthcare organisations; it supplies no basis for calculating how widely they follow it. ^[9]

The exercise needs to cover the whole service. Accounts and permissions, encryption key management, security logs and backups may all have to be organised differently after a change of host. The same guide distinguishes leaving a provider from disaster recovery, which is often designed around another data centre belonging to the incumbent. A restorable backup provides evidence about data recovery. Resuming operations with a different provider requires checking the remaining dependencies too. ^[9]

Take an illustrative test scenario, with no actual result implied. A team transfers a representative set of case files to an isolated environment, creates the required accounts with minimum necessary permissions, has users complete a workflow, and checks the security logs. It records working time, manual operations and missing elements. The observations can then inform changes to the contract, documentation or architecture. Test data and access must retain safeguards appropriate to their sensitivity.

UK guidance on technical cloud lock-in reports that some organisations periodically rebuild critical components with another provider to reassess the cost of switching. It also recognises the value of integrated services: delegating operational work can bring benefits. The decision involves weighing those benefits against a known dependence that is reviewed over time. Using several cloud providers leaves that question to be answered for each component. ^[10]

Responsibility beyond the next political term

France’s Cour des comptes has examined this organisational problem. In its October 2025 report on the state’s civilian information systems, it calls for a costed strategy covering development and operations, with regular audits of implementation. On 8 April 2026, the interministerial digital directorate, DINUM, announced central coordination and asked every ministry, including its public bodies, to formalise a plan to reduce dependencies on non-European suppliers by the autumn. The announcement assigns responsibility and a deadline; our sources do not establish whether all these plans had been delivered and implemented by 9 October. ^{[12] [13]}

A UK internal policy shows how such responsibilities can be assigned within an organisation. The Department for Work and Pensions, DWP, requires a documented and tested exit strategy for each critical cloud service. Its policy also allocates responsibilities throughout the service lifecycle: service owners oversee risks and the division of responsibilities, while procurement and legal teams must ensure that contracts carry the appropriate requirements. The rule applies within the department and to the providers covered by the policy. The document establishes the internal requirement; it does not publish the results of every test. ^[11]

Assigning this work helps a decision survive a change of personnel. The next service owner inherits its known dependencies, dated test results and outstanding problems. After each substantial change, that person can ask whether another departure remains feasible. A political choice then has a technical and contractual record that can be passed on.

The question that opened this investigation ultimately needs an answer at the level of each service. An administration can organise a phased departure from Microsoft. It can also retain certain uses whose constraints it understands. In either case, its room for manoeuvre depends on what it can take over, have maintained and pass to others. The first instalment began with accumulated dependencies. The last arrives at an enduring task: keeping alternatives concrete enough for a new team to exercise them.

The next contract can provide access to the necessary materials. Architecture can make their transfer feasible. Exercises can reveal the work still required. Maintaining that capability allows a state to choose again as its needs, risks or suppliers change.

Sources and limits of the investigation

Documentary investigation closed on 9 October 2026. We compared the European contract award with its assessment framework and calculation guide, then examined exit obligations alongside legal texts and operational guidance. EU rules, French clauses for incorporation into contracts and UK internal policies have different scopes. We conducted no original interviews, supplier audits or migration tests. Illustrative scenarios are identified as such. The two infographics explain documented mechanisms; they reconstruct no bid scores and predict no migration duration. The opening illustration is a conceptual composition.

1. European Commission, Commission advances cloud sovereignty through strategic procurement, 17 April 2026. Four contracts, a combined ceiling of €180 million over six years, contractors and partners, and SEAL levels assigned to the offerings. The buyer’s announcement; no actual spending or successful migration is inferred.
2. European Commission, Cloud Sovereignty Framework, version 1.2.1, October 2025, pages 2–3 and 6. Threshold for each objective, SEAL levels and the complementary score contributing to the quality assessment; weights of the eight objectives.
3. European Commission, Cloud Sovereignty Framework: Implementation guidance, June 2026, introduction and pages 9–11. Explanation of the calculation used in the completed procurement: the lowest objective level, a SEAL 2 threshold, then a weighted score.
4. Direction des affaires juridiques, Mise en œuvre de l’article 31 de la loi SREN et clauses pour renforcer la souveraineté des achats numériques, updated 21 August 2026, pages 1–8 and annex, particularly page 13. Scope of the sensitive data and entities concerned, the decree of 14 April 2026 and order of 12 August 2026, and model clauses on reversibility and rights to bespoke developments. Regulatory obligations, recommendations and terms to be incorporated into a contract are distinguished.
5. ANSSI, SecNumCloud requirements, version 3.2, 8 March 2022, page 48, contractual requirements 19.1 h and i. Recovery of entrusted and generated data, formats usable outside the service and documented interfaces.
6. Order of 30 March 2021 approving the CCAG-TIC, annex, Articles 1.1–1.2, 38.4 and 42, accessed 9 October 2026. Express reference to the CCAG, departures from its terms, the transfer plan and materials, access and security during takeover.
7. Regulation (EU) 2023/2854, Data Act, 13 December 2023, Articles 1–2, 25–26, 30–31 and 50. Scope, definitions, time limits, exit information and the distinction between infrastructure and other cloud services. Article 25 is the legal basis for the timetable; technical exceptions and the customer’s extension right are retained.
8. European Commission, Data Act: Frequently Asked Questions, version 1.4 of 22 January 2026, pages 37–40, questions 56, 58a and 58b. Scope of switching obligations, SaaS and IaaS, and the respective responsibilities of the outgoing provider and the destination. Explanatory guidance, which does not replace the regulation.
9. NHS England, NHS cloud exit strategy, last modification displayed as 3 November 2025. Exit preparation, testing, access rights, identity, security, continuity and the distinction from disaster recovery. Methodological guidance without measurement of its implementation by healthcare organisations.
10. Government Digital Service, Managing technical lock-in in the cloud, published 17 December 2019, substantive revision recorded on 1 April 2025, accessed 9 October 2026. Benefits and costs of dependence, continuing review, testing with another provider and skills. The change dated 3 September 2026 concerns the name of the public procurement body.
11. Department for Work and Pensions, Cloud computing security policy, version accessed 9 October 2026, sections 1, 6.3 and responsibilities. Documented and tested exit strategies for each critical service, responsibilities and contractual requirements. An internal policy with its scope defined in the document.
12. Cour des comptes, Les enjeux de souveraineté des systèmes d’information civils de l’État, 31 October 2025, printed pages 9, 28–31 and 55. Interministerial governance, a costed strategy covering development and operations, and implementation audits. Recommendations are distinguished from evidence of subsequent implementation.
13. DINUM, Réduction des dépendances numériques extra-européennes, announcement of 8 April 2026. Interministerial coordination and plans required by the autumn, including ministries and their public bodies. The announcement is not an implementation report.