Summary If a CADA risk assessment determines that your public sector activities require a higher Union assurance level, you must migrate to a compliant cloud service within a maximum of 12 months, as proposed in Article 29(6). This transition period is not a fixed deadline for all cases but a strict upper limit that must be calibrated against technical feasibility, continuity of service, and data portability requirements. Planning this migration requires a structured, proactive approach that prioritizes operational resilience while ensuring you meet the new sovereignty standards before the transition window closes. Failure to migrate within this reasonable period, unless justified by these specific constraints, would constitute a breach of the proposed regulation.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a rigorous framework for cloud sovereignty, requiring public sector bodies to align their cloud services with specific Union assurance levels based on a formal risk assessment. When a risk assessment under Article 29 concludes that a current cloud provider does not meet the required assurance level for activities contributing to the preservation of public order, a migration is legally triggered.

Unlike standard IT upgrades driven by cost or performance, a CADA-driven migration is a compliance imperative. The regulation acknowledges the complexity of moving critical public infrastructure but sets a clear boundary for how long a non-compliant state can persist.

The 12-Month Transition Mandate: Article 29(6)

Article 29(6) of the CADA proposal explicitly states: "Where the risk assessment requires the migration to another cloud computing service, the Member State or Union entity shall migrate within a reasonable transition period that shall not exceed 12 months."

This provision is the cornerstone of migration planning for public buyers. It establishes a "hard outer limit" for compliance. While the regulation uses the term "reasonable transition period," it immediately qualifies this by capping the duration at 12 months. This means that while a migration might reasonably take 6 or 9 months depending on complexity, it cannot legally extend to 13 months or more without a specific, extraordinary justification that falls outside the standard interpretation of the regulation.

The regulation explicitly mandates that the determination of this "reasonable" period must take into account three specific factors:

  1. Technical feasibility: This refers to the practical ability to move the workload. Can the target sovereign cloud service support the existing architecture, or does a significant redesign of the application stack require time? If the current environment relies on proprietary technologies that cannot be easily replicated in the new sovereign environment, this factor justifies a longer portion of the 12-month window.
  2. Continuity of service: Public services cannot simply go offline. The migration plan must ensure that there is no disruption to the essential services provided to citizens or other government bodies. A migration that causes a blackout in critical infrastructure (e.g., healthcare or law enforcement systems) would fail the continuity test, regardless of the timeline.
  3. Data portability requirements: The ability to move data from the incumbent provider to the new sovereign provider without loss, corruption, or excessive latency is a primary constraint. If the incumbent provider uses proprietary formats, creates vendor lock-in, or lacks robust export tools, the time required to extract, transform, and validate data may extend the transition period.

Strategic Planning for CADA Migration

Planning a migration under CADA differs fundamentally from standard cloud moves. The driver is regulatory compliance and the preservation of public order, not just cost optimization. The process should begin immediately after the risk assessment is finalized, as the 12-month clock starts ticking from the point the migration requirement is identified.

1. Gap Analysis and Target Selection

The first step is to identify the specific Union assurance level (2, 3, or 4) required by the risk assessment. This level is determined by the sensitivity of the data and the criticality of the activity (e.g., law enforcement, defence, or internal security).

Next, consult the central repository of recognised cloud computing services maintained by the Commission under Article 22. This repository lists providers that have been formally recognised as offering specific Union assurance levels. You must verify that the target provider holds a valid recognition for the specific assurance level required.

  • Verification: Do not assume a provider is compliant because they are "EU-based." They must be formally recognised under Article 17.
  • Derogations: If no suitable provider exists in the repository, Article 30(4) allows for derogations in exceptional circumstances (e.g., if the subject matter cannot be supplied by recognised services). However, this is a last resort and not a planning assumption. Relying on a derogation without exhausting the repository first could be seen as non-compliant.

2. Technical Feasibility Assessment

Evaluate the current technical architecture against the requirements of the new provider. CADA emphasizes the use of open standards and open-source solutions (Article 41) to reduce vendor lock-in. If your current environment relies heavily on proprietary, closed-source technologies from a non-compliant provider, the "technical feasibility" factor under Article 29(6) may justify a longer portion of the 12-month window.

Key technical considerations include:

  • Application Refactoring: Do applications need to be rewritten to run on the new infrastructure? Legacy systems may require significant re-architecting to meet the sovereignty criteria of the new provider.
  • Integration Complexity: How are the cloud services integrated with other government systems? Breaking these integrations during migration can cause cascading failures.
  • Performance Benchmarks: Will the new sovereign cloud meet the latency and throughput requirements of the public service? A migration that degrades performance below operational thresholds fails the "continuity of service" test.

3. Data Portability Strategy

Data portability is often the most time-consuming and risky aspect of cloud migration. Under CADA, for higher assurance levels (2, 3, and 4), customer data, including metadata and telemetry, must remain exclusively within the Union (Annex II). You must plan for:

  • Data Extraction: Developing scripts and tools to export data from the incumbent provider. If the provider resists or lacks tools, this becomes a legal and technical hurdle.
  • Data Transformation: Converting data formats if the new provider uses different schemas. This is critical to ensure data integrity.
  • Data Validation: Ensuring that no data is lost or corrupted during the transfer. This requires rigorous testing and reconciliation.
  • Legal Compliance: Ensuring that the transfer complies with GDPR and other data protection laws. CADA complements but does not replace these frameworks. The migration plan must address both sovereignty (CADA) and data protection (GDPR) requirements simultaneously.

4. Service Continuity Planning

Public sector bodies cannot afford downtime. The migration plan must include a detailed continuity strategy, such as:

  • Parallel Running: Running both the old and new systems simultaneously for a period to validate performance and data integrity. This is often the safest approach but requires double the resources.
  • Phased Migration: Moving non-critical workloads first, followed by critical systems. This minimizes risk but extends the overall timeline.
  • Rollback Procedures: Defining clear criteria and steps to revert to the old system if the migration fails. However, this is a temporary measure; the old system is non-compliant and cannot be used indefinitely.

5. Contractual and Procurement Alignment

The migration must be supported by appropriate contractual arrangements. If the current contract with the non-compliant provider has termination clauses that hinder migration (e.g., long notice periods or high exit fees), these must be renegotiated or managed legally.

For the new provider, the procurement process should have already been initiated or completed, as Article 30 requires contracting authorities to procure only services that meet the required assurance level. The migration timeline should be reflected in the service level agreements (SLAs) with the new provider. If the new provider cannot guarantee the migration within the 12-month window, they may not be a viable option.

6. Monitoring and Reporting

Throughout the 12-month period, the public sector body must monitor the migration progress. Article 29 requires Member States to provide the Commission with the results of risk assessments and any departures from the methodology. While the migration itself is an operational task, the successful completion of the migration is evidence of compliance with the risk assessment outcomes.

Any significant delays or issues that threaten the 12-month deadline should be documented and, if necessary, reported to the relevant national competent authority. Failure to migrate within the reasonable period (up to 12 months) without valid justification could lead to penalties under Article 24, which requires Member States to lay down rules on penalties that are "effective, proportionate and dissuasive."

What this means for you

For public-sector and procurement officers, the 12-month transition period under Article 29(6) is a critical milestone that requires immediate action. You cannot wait for the risk assessment to be finalized to begin planning; in fact, proactive planning should be part of your overall cloud strategy to minimize disruption.

Key Actions:

  • Initiate Planning Early: As soon as a risk assessment indicates a potential need for migration, begin a preliminary gap analysis. Identify which services are most at risk and which providers are eligible.
  • Engage IT Teams: Work closely with your IT departments to assess technical feasibility. Understand the complexity of your current architecture and the effort required to move to a new provider.
  • Prioritize Data Portability: Ensure that your current contracts with cloud providers include robust data portability clauses. If they do not, start negotiating amendments or preparing technical workarounds.
  • Coordinate with Procurement: Ensure that the procurement process for the new provider is aligned with the migration timeline. You need a contract in place before the migration begins.
  • Document Everything: Keep detailed records of your migration planning, including assessments of technical feasibility, service continuity plans, and data portability strategies. This documentation will be essential if you need to justify the length of your transition period within the 12-month maximum.

Common misconceptions

Misconception 1: The 12-month period is a fixed deadline for all migrations. Reality: Article 29(6) sets a maximum limit, not a fixed term. The actual period should be "reasonable" based on technical feasibility, service continuity, and data portability. A simple migration might take 3 months, while a complex, large-scale migration might take the full 12 months. The key is to justify the duration based on the specific factors listed in the regulation.

Misconception 2: I can delay migration until the 12th month. Reality: Waiting until the last minute is risky. Technical issues, data corruption, or service disruptions are more likely if the migration is rushed. A phased, well-planned approach that starts early is far more likely to ensure service continuity and compliance. The "reasonable" period should be determined at the start of the migration, not at the end.

Misconception 3: CADA replaces GDPR requirements for data transfers. Reality: CADA complements but does not replace the GDPR. While CADA focuses on sovereignty and assurance levels, data transfers still must comply with GDPR rules, including adequacy decisions and appropriate safeguards. The migration plan must address both sets of requirements.

Misconception 4: Any cloud provider in the EU is automatically compliant. Reality: Compliance is not automatic. Providers must be formally recognised as offering a specific Union assurance level (1, 2, 3, or 4) under Article 17. You must verify this recognition in the central repository before selecting a provider for migration.

Official sources

Related

This is general information about a draft EU regulation, not legal advice.