Experience feedback from a defense sector company
How a defense company successfully migrated its entire Azure infrastructure to a European cloud in just 12 weeks, highlighting the methodology, key trade-offs and lessons learned.
About the author
Cloud, DevOps and Sovereign Infrastructure Expert
Introduction
This article is based on a webinar organized by Hubadviser on the topic of reconciling cloud and sovereignty. The objective was to move beyond theoretical discussions around digital sovereignty and focus on practical insights, through the real-world experience of an expert who has led migrations toward sovereign infrastructures.
In this article, you will find
- A concise overview of the legal risks associated with dependence on US cloud providers, including the Cloud Act, FISA and OFAC
- A detailed account of a migration from Azure to Scaleway for a defense sector company, completed in 12 weeks
- An overview of the three sovereign cloud models available in Europe, including trusted clouds, European public clouds and self-hosted approaches
- A comprehensive mapping of European and open source alternatives, function by function
- Five key operational lessons drawn from this experience
1. Why digital sovereignty has become an operational priority
Digital sovereignty is no longer a theoretical concern. In 2024 and 2025, several strong signals have turned it into a concrete priority for CIOs.
These include the enforcement of US extraterritorial sanctions impacting European players, such as account freezes through platforms like Visa, Amazon or PayPal, growing concerns about Europe’s technological dependency often described as “digital vassalization,” and the increasing geopolitical dimension of digital infrastructures, now considered strategic assets.
Behind these signals, three legal mechanisms directly expose European organizations. The Cloud Act allows US authorities to access data hosted outside the United States by American providers. FISA Section 702 enables intelligence collection on non-US citizens. In addition, governments retain the ability to restrict the sale or renewal of software licenses to foreign entities.
“The risk is not that a US cloud provider would cut off access to an entire country, as that would be damaging to their own economy. The real risk lies in targeted actions, whether against a key individual, a sensitive company, or a critical organization.”
Flavien Berwick
Cloud : An unavoidable imperative
At the same time, CIOs are facing increasing pressure to gain agility and responsiveness, and to enable the adoption of artificial intelligence within their organizations. Scalable infrastructures, on-demand access to GPUs, and the ability to rapidly deploy new services, cloud is no longer an option; it is a prerequisite to meet competitiveness and digital transformation challenges.
As a result, the equation becomes more complex. It is no longer about choosing between cloud and sovereignty, both are essential. The real question becomes : how can they be reconciled ? This is precisely the focus of this experience feedback.
It is within this context that Flavien Berwick, an expert in sovereign infrastructures with experience at the Ministry of the Armed Forces and the Ministry of the Interior, shares the details of a migration he led for a company in the defense sector.
2. Starting point : a defense company running on Azure
The initial assessment revealed an almost complete dependency on US-based services.
The key question
“The first question I asked the CTO was what exactly they were trying to protect themselves against. As in cybersecurity, full autonomy is not realistic. The priority is to clearly define the risks you want to mitigate.”
— F. Berwick
The CTO’s answer was clear. The objective was to avoid potential US targeting of its services, whether through restricted access to Azure or the risk of intellectual property exposure.
In this context, moving to a sovereign cloud became the natural strategic decision.
3. Before and after : the transformation at a glance
The table below summarizes the initial state of the infrastructure, fully dependent on US-based services, and the final state after migrating to a sovereign stack.
Beyond the change of cloud provider, the migration was also an opportunity to structure key components of the infrastructure, including VPN, identity and access management, observability, and governance, which were previously either missing or only partially implemented.
| Function | Initial state (Azure and US stack) | Final state (sovereign) |
|---|---|---|
| Cloud IaaS | Azure | Scaleway |
| Office and email | Microsoft 365 and Exchange | Nextcloud, OnlyOffice, Infomaniak |
| Code repository | GitHub | GitLab self-hosted |
| Web protection and CDN | Cloudflare | Bunny.net |
| VPN | Cisco AnyConnect | Tailscale |
| Authentication and IAM | Microsoft | Samba, FreeIPA, Keycloak |
| Configuration management | Manual or partial | Ansible (Infrastructure as Code) |
| Observability | Not implemented | FluentBit, OpenSearch |
| Documentation and wiki | Not implemented | Wiki.js |
| Governance | Partial | Documented and formalized |
4. Overview of alternatives : three sovereign cloud models
Trusted cloud providers through joint ventures
These are joint ventures between European and American players, such as S3NS for Thales and Google, Bleu for Orange Capgemini and Microsoft, and Azure Sovereign Cloud.
They rely on US technologies hosted in Europe, with local encryption key management using a bring your own key approach and controlled update mechanisms.
The main advantage lies in familiarity for existing teams. However, limitations include access to only a subset of the original product, with missing services such as AI capabilities, Cloud Shell or notebooks, continued dependence on US licensing, and access often restricted behind a contact-based onboarding process.
European public cloud providers
These providers operate under European law and rely on open source or internally developed technologies. Examples include Scaleway, OVHcloud, Outscale, United Cloud and Hetzner.
While historically perceived as less feature-rich, they now offer immediate accessibility and have introduced their own innovations, including quantum computing initiatives, IPFS-based storage and advanced networking such as layer 2 virtual private racks.
In practice, they cover the vast majority of use cases, with around 95 percent of needs addressed. They also provide a smoother transition path for teams coming from on-premise environments.
Self-hosted and colocation models
These approaches are typically reserved for highly critical systems in sectors such as defense, energy or healthcare.
They often involve air-gapped environments to meet strict certification requirements, including restricted or classified information levels, as well as eIDAS-compliant colocation setups.
Common technologies include OpenStack, Rancher, Nexus, Proxmox, perpetual VMware licenses and certified custom-built platforms.
5. Choosing Scaleway
Among the available European public cloud providers, the company selected Scaleway. A subsidiary of the Iliad Group, Scaleway has emerged in recent years as one of the most ambitious European cloud providers, with a clear positioning: offering a sovereign alternative to American hyperscalers without compromising on developer experience.
Scaleway Profile
Scaleway is a French cloud provider operating under European law, with all its data centers located in France and the Netherlands. Unlike “trusted cloud” offerings (such as S3NS or Bleu), Scaleway has developed its own software stack in-house, based on open-source components, without technological dependency on any American vendor. The company offers a comprehensive range of services: virtual instances (VMs), managed Kubernetes (Kapsule/Kosmos), managed databases, object storage (S3-compatible), load balancing, private networking (vRack), and dedicated GPU offerings for AI.
Certifications and Compliance
- ISO 27001:2022: the benchmark standard for information security management systems.
- HDS (Health Data Hosting): certification obtained in July 2024, enabling the hosting of health data in compliance with French Ministry of Health requirements.
- SecNumCloud (in progress): Scaleway achieved the ANSSI J0 milestone in January 2025 and is targeting full qualification. A key differentiator is that Scaleway is qualifying its entire cloud offering, rather than a specific, isolated product.
- Native GDPR compliance: data is hosted in Europe, operated by European teams, with no exposure to extraterritorial legislation.
Why Scaleway in This Specific Context
Several concrete factors influenced the company’s decision:
- Self-service access: unlike S3NS or Bleu, where onboarding requires a commercial process (“Contact us”), Scaleway offers immediate sign-up, similar to AWS or Azure. For a mid-sized company, this is a decisive advantage.
- Team familiarity: the company’s two system administrators had already used Scaleway on previous projects, making the learning curve negligible.
- Ease of adoption: transitioning from on-premise environments to Scaleway is smoother than to AWS, where the breadth of services (300+) can be overwhelming.
- Talent pool: Scaleway has sufficient recognition in Europe to allow the company to recruit skilled professionals familiar with the platform.
- Relevant certifications: ISO 27001 and HDS covered immediate needs, while the ongoing SecNumCloud qualification provided a strong outlook for future public sector tenders.
“With Scaleway, you can sign up directly, just like with AWS or Azure. You’re not stuck in three days of discussions with sales teams. For a technical team that wants to move fast, it makes a real difference.” — F. Berwick
It is important to note that this choice is neither a partnership nor a commercial endorsement. Other European cloud providers (OVHcloud, Outscale, Hetzner) could also have been suitable depending on the context. In this case, the decision to use Scaleway resulted from an alignment between existing skills, required certifications, and ease of access to the platform.
6. Timeline : a 12-week migration
The migration was carried out over a 12-week period, structured into three distinct phases.
The company relied on two system administrators who were already familiar with Scaleway, which significantly accelerated execution.
| Phase | Timeline | Key actions |
|---|---|---|
| 1. Alignment and scoping | Weeks 1 to 2 | • CTO interview to define needs, scope and initial estimates • Presentation of the vision to the entire company • Feedback collection and addressing concerns • Finalization of the migration plan with system administrators |
| 2. Platform build | Weeks 3 to 8 | • Governance and documentation setup using Wiki.js • Scaleway landing zone including network, IAM, VPN and load balancer • Identity stack with FreeIPA, Samba, Keycloak and SSO • Deployment of core services such as Nextcloud, GitLab and reverse proxy • Migration of Azure virtual machines to Scaleway using qcow2 format • Backup strategy and observability with FluentBit and OpenSearch • Automation through Ansible, including certificates and group policies |
| 3. Cutover and adoption | Weeks 9 to 12 | • Migration of email services to Infomaniak and DNS to Bunny.net • Progressive onboarding of employees • Support, feedback collection, adjustments and stabilization |
The core challenge : rebuilding the equivalent of Active Directory
Microsoft’s strength lies in its ability to consolidate multiple capabilities into a single product, such as Azure AD or Entra ID.
In a sovereign environment, achieving the same level of functionality requires combining several components. The following architecture was implemented
- VPN with Tailscale to provide secure access to internal services, replacing Cisco AnyConnect
- Windows authentication with Samba AD to manage the existing Windows environment
- Linux authentication with FreeIPA to control access across Linux servers
- Single sign-on with Keycloak to unify authentication across all services
- Configuration management with Ansible to automate updates, certificates and group policies
- Observability with FluentBit and OpenSearch to centralize logs and enable monitoring
7. Comprehensive mapping of alternatives
The table below provides an overview of available solutions for each IT function, structured across three categories: traditional tools, typically US-based, open source alternatives, and private European or Canadian solutions.
| Topic | Traditional tools | Open source alternatives | European and Canadian private solutions |
|---|---|---|---|
| Authentication | Microsoft Active Directory | Samba AD DC, FreeIPA | Univention |
| Unified Endpoint Management | InTune (Microsoft 365), Jamf Pro, NinjaOne, ManageEngine | Fleetdm, opsi | Relution, Matrix42, SOTI |
| Office suite | Office 365, Google Workspace | LaSuite.coop, Nextcloud, OnlyOffice | Infomaniak, Proton, Leviia, Wimi, Hexagone |
| VPN | OpenVPN, Cloudflare, Cisco AnyConnect | OpenVPN, Pangolin, Headscale | Tailscale, Netbird |
| DNS and CDN | Cloudflare, Akamai, AWS CloudFront | NGINX, Varnish, PowerDNS | Bunny.net |
| Cloud provider | Azure, Google Cloud Platform, AWS, Oracle | OpenStack, CloudStack, OpenNebula, Microcloud, Proxmox, Rancher | Scaleway, OVHcloud, Outscale, United Cloud, Hetzner, IONOS, Exoscale |
| AI models | OpenAI, Anthropic, Google, Azure, AWS | Hugging Face ecosystem including Meta, DeepSeek, Qwen, BGE, Google, Mistral AI, OpenAI | Mistral AI, H Company, Cohere, Black Forest Labs, Aleph Alpha |
| Operating system | Windows, Red Hat Enterprise Linux, macOS | Debian, AlmaLinux, Ubuntu, CentOS Stream, openSUSE | SUSE Linux Enterprise |
8. Five key lessons learned
1. Your technical teams are already on board
This is a consistent pattern. Technical teams tend to see the shift toward open source as a natural step in their professional growth. Moving from Windows to Linux or from VMware to Kubernetes means working with modern, in-demand technologies that enhance their market value.
The barrier is almost never technical. It is primarily political.
2. The decision is political, not technical
Migrating to a sovereign cloud reshapes investment priorities, HR policies and IT consumption habits.
This is not a decision that can be made by the IT department alone. It must be validated at the executive level, with clear sponsorship from top management.
3. Start with a limited scope, but move to production
The right approach is to identify a pilot project with motivated teams, experiment, and then move quickly into production.
The common pitfall is remaining stuck in a prolonged testing phase, with parallel infrastructures that never fully converge. This leads to increased costs without delivering meaningful or lasting learning.
4. Build internal capabilities
External support can be valuable at the beginning. However, the objective should always be to make internal teams autonomous.
Over-reliance on external partners simply replaces technological dependency with human dependency.
5. Systematically capture and share knowledge
Every incident, bug and decision should be documented through post-mortems and centralized in a collaborative knowledge base, such as Wiki.js in this case.
This discipline is what differentiates a successful migration from a fragile infrastructure.
9. A pragmatic approach : hybrid cloud
Migrating to a sovereign cloud does not mean completely abandoning AWS, Azure or Google Cloud.
The key recommendation from this experience is to adopt a three-layer hybrid approach
- Daily operations on a European cloud, such as Scaleway or OVHcloud, for hosting and core services
- Innovation and experimentation on hyperscalers for specific use cases, including advanced AI or rapid prototyping that are not yet fully available in Europe
- Critical systems on SecNumCloud-certified environments or self-hosted infrastructures for classified data and regulated workloads
“Up to 95 percent of use cases are already covered by current capabilities from providers like Scaleway or OVHcloud. Organizations should carefully assess their real needs before defaulting to a US hyperscaler.”
— F. Berwick
10. Key takeaways
This experience shows that migrating to a sovereign cloud can be achieved within 12 weeks for a mid-sized organization, provided that four key principles are followed
- Developing an internal sovereign capability, even if only partial
- Recognizing that sovereignty is primarily a political decision requiring executive-level sponsorship
- Engaging all stakeholders from the outset, including technical teams, leadership and business users
- Adopting a hybrid cloud approach, with sovereignty for core operations and openness for innovation
Digital sovereignty is neither an illusion nor a rejection of progress.
It is a strategic choice for independence that, as demonstrated in this experience, can be implemented in a pragmatic, gradual and controlled manner.
