A European IT stack: Digital sovereignty through replaceable architecture

What does digital sovereignty mean when an organisation is not building its infrastructure from scratch? The debate often stops at European cloud providers, the location of data or replacing individual applications. These are important questions, but they do not yet constitute a resilient architecture.

At ForgeOne, sovereignty starts with control: over data, operations, identities, interfaces, recovery and future change. A technology decision must not become an irreversible dependency. At the same time, promising complete independence or a disruption-free move between arbitrary platforms would be unrealistic.

Our goal is therefore not unrestricted one-to-one interchangeability of individual products. We design functional architecture components so that an organisation can replace them in a controlled manner with preparation, testing and appropriate resources. If adjacent tools or processes also need to change, that is not a failure of the principle; it is part of an honestly designed exit strategy.

Key takeaways

A European IT stack can already be built for many clearly defined requirements. Technologies for virtualisation, operating systems, identity management, backup and collaboration are available today. However, this does not eliminate dependencies on international vendors and supply chains.

What matters is not just where technologies originate or how they are licensed, but how well their components integrate, how maintainable they are, whether systems can be reliably restored, and whether realistic migration paths exist. Existing infrastructures also require careful consideration of functionality, operational effort and economic risks.

EuroStack aims to strengthen European technology offerings and the conditions supporting their development and adoption. However, the initiative does not provide a technically validated reference architecture.

What is a European IT stack?

For us, a European IT stack is not an origin label attached to an arbitrary product list. At least five perspectives must be assessed separately: legal headquarters, ownership structure, development and governance, technological dependencies, and the practical ability to operate a solution independently and leave it later.

A. European vendors

This includes vendors headquartered in Europe with traceable product responsibility. Infrastructure and workplace examples include Proxmox and LINBIT in Austria; Bareos, Univention, OpenProject, Nextcloud, Open-Xchange and Checkmk in Germany; and XWiki in France. It still matters whether a company is based inside the EU or in a European non-EU country. Headquarters alone answers neither the ownership nor the governance question.

SUSE illustrates why this distinction is necessary: the company was founded in Germany, is headquartered in Luxembourg and describes itself as Swedish-controlled. Headquarters, ownership, development locations and technical control are separate criteria that should not be reduced to a single origin label.

B. Internationally developed open-source technologies

Debian is an international community project. Kubernetes and Keycloak are developed in global open-source ecosystems. Ansible is an open-source project with a commercial Red Hat ecosystem, while Ubuntu is backed by Canonical as an international organisation. These technologies are not exclusively European. They can nevertheless support sovereign self-hosting because source code, open interfaces, documented data paths and broad ecosystems improve control. Open source is a tool for control here, not automatic proof of origin.

C. Remaining dependencies

Hardware, processors, firmware, manufacturing capacity, libraries, external services and specialised applications frequently remain dependent on international supply chains or proprietary components. A credible target architecture names these limits and assesses who controls the roadmap, licensing model and technical development. European origin can support digital sovereignty, but it does not replace an open, controllable and replaceable architecture.

EuroStack and European technology policy: an initiative, not a reference architecture

As of October 2026, the EuroStack initiative is an industrial-policy initiative. It aims to combine technology, governance and funding so that European digital infrastructure, from connectivity and cloud to software and AI, can be built and adopted. It is neither a product catalogue nor a tested reference architecture that automatically makes specific components compatible.

EuroStack describes the principles “Buy European”, “Sell European” and “Fund European”. At the same time, the initiative states that it does not seek complete decoupling from US technology, but resilient European alternatives and greater competition. This description of its scope and origins matters: a policy objective, available products and a practically integrated operating architecture represent three different levels of maturity.

The EU technology-sovereignty strategy spans chips, infrastructure, software, cloud and AI and links them, among other measures, to an open-source strategy. However, the 2026 State of the Digital Decade still records market fragmentation and skills shortages. It puts the EU's share of the global semiconductor market at only 9 per cent and also identifies significant dependencies on non-EU suppliers in cloud, cybersecurity and other strategic technologies. Production-ready European and openly developed components already exist; large-scale integration, resilient supply chains and financially sustainable operations remain separate tasks.

The architecture: functional domains instead of rigid product combinations

The following structure is neither a mandatory product catalogue nor a set of strictly stacked layers. It shows which responsibilities an operable platform must cover and where alternatives, transitions and dependencies should be planned.

Identity management, security, backup, monitoring, automation and lifecycle management are cross-cutting functions. They span several domains and must not appear as isolated endpoints in an architecture diagram. PKI, secrets management, DNS and CI/CD also cross architectural boundaries. These less visible dependencies often determine whether a migration remains manageable.

Further guidance on individual components is available on our pages about Proxmox VE, SUSE, Bareos, Keycloak, FreeIPA and Ansible.

Replaceability means more than having an alternative

At ForgeOne, we do not consider a technology replaceable merely because another product offers comparable functions. The decisive question is whether the transition can be planned, prepared, tested and carried out with proportionate effort. We therefore distinguish technical replaceability from organisational readiness to change.

Technical replaceability

• Documented interfaces and open standards.
• Data export, data migration and transferable configurations.
• Reproducible, automated installation and configuration.
• Documented migration and recovery procedures.
• Testable alternative platforms and defined fallback options.
• Traceable dependencies between components.

Organisational readiness to change

• Current technical documentation and clear responsibilities.
• Available internal or external expertise and support services.
• Contractual exit options and regulated access to data.
• Suitable test and migration environments.
• Sufficient time and personnel.
• Defined approval, acceptance and escalation processes.

Even a technically open platform can become a practical dependency if nobody knows how it is built, how its data can be exported or how an alternative can be introduced.

“For us, a technology is only controllably replaceable when an alternative exists and there is also a documented, verifiable path to it.”

Replacing a virtualisation platform can also affect backup, networking, storage, monitoring and automation. What matters is not whether every product name remains unchanged, but whether the required operational functions continue to be delivered under control.

This is why we distinguish replacing a product from replacing a functional platform assembly. An individual tool can sometimes be exchanged directly. In other cases, a combination of hypervisor, backup target, storage driver and operating process must be redesigned together. A sovereign architecture makes that scope visible before the change becomes urgent.

Example: moving from Proxmox VE to SUSE Virtualization

Starting point

An organisation operates Proxmox VE as its hypervisor, Proxmox Backup Server for VM backups, Linux-based virtual machines, central monitoring, automated configuration management and central identity management. The platform is in production; retention, recovery objectives and responsibilities are defined.

New requirement

For strategic or technical reasons, virtualisation is to be operated with SUSE Virtualization in future. The decision should be possible without fundamentally redesigning applications, identities and every operating process. This does not mean that each integration can be transferred unchanged.

What actually changes

Proxmox Backup Server is directly integrated with Proxmox VE and provides VM- and container-oriented backup workflows there. This does not imply that existing PBS backups can be restored directly into SUSE Virtualization. Native backup and restore in SUSE Virtualization is itself dependent on version, storage and configuration. The official documentation must therefore be checked for the deployed release and the specific backend.

Bareos can additionally provide agent- or application-based protection inside virtual machines. That does not automatically make Bareos a complete replacement for all PBS functions. VM snapshots, full VM recovery, application-consistent backup, platform disaster recovery, RPO and RTO must be designed and tested separately.

• Complete VM backups and recovery of entire virtual machines.
• File-based and application-consistent backups inside guest systems.
• VM snapshots as short-lived operational mechanisms rather than the sole backup.
• Bare-metal or system recovery and rebuilding the complete platform.
• RPO, RTO, long-term retention and access to historical backup sets.

The specific backup architecture therefore depends on supported functions, storage technologies and recovery requirements. During a platform change, we preserve the required operational capabilities, not necessarily the same products.

Version note for the documented backup function: In the SUSE Virtualization 1.8 documentation reviewed here, backup support is limited to SUSE Storage volumes; volumes on external storage are not backed up by this function.

The table also serves as a textual architecture diagram: Linux workloads, central identity, service monitoring, automation principles and collaboration applications remain as functions in both designs. The virtualisation and native backup layers are replaced, while their integrations are adapted. This explicitly does not claim an automatic switchover.

Example protection paths: Proxmox VE → Proxmox Backup Server → backup storage. In one possible target design: SUSE Virtualization → supported native VM backup functions → suitable backup storage. In addition: SUSE Virtualization → guest operating systems and applications → Bareos → backup storage.

This is an architecture example, not a fully tested or certified ForgeOne reference implementation. A specific implementation must validate the version, storage, workloads, consistency requirements and recovery objectives separately.

Vendor dependency in practice: VMware VDDK

The VMware Virtual Disk Development Kit (VDDK) is a proprietary SDK for accessing VMware virtual disks. Red Hat recommends a VDDK image built from it for transferring virtual disks with the Migration Toolkit for Virtualization (MTV). Without VDDK, transfers can be significantly slower, and the MTV path does not work for virtual machines backed by VMware vSAN, according to the documented VMware prerequisites.

According to the Red Hat notice updated on 27 August 2026, previous public download paths were no longer available. Because Broadcom owns and licenses the proprietary package, Red Hat cannot distribute the image itself; at that date, access had to be requested through VMware/Broadcom support. Migration planning must therefore verify VDDK access, terms of use, a compatible version and an internally reachable image before committing to a schedule, rather than assuming permanent availability of this third-party component. The Red Hat notice about VDDK availability describes this dependency.

This does not make VMware migrations generally impossible. In some non-vSAN scenarios, MTV can operate without the VDDK image, though potentially with substantially lower performance. Red Hat also identifies storage copy offload/XCopy as a possible workaround when the storage backend supports it. Whether that route, another export or conversion method, or rebuilding a workload is appropriate depends on storage, workloads, downtime and fallback requirements and must be validated in a lab.

A controlled migration path

1. Document the existing platform, dependencies, data paths and recovery objectives.
2. Select the target platform, storage backend and supporting tools from actual requirements.
3. Build the new infrastructure in parallel and separately from production.
4. Implement backup, restore and disaster-recovery procedures before the first production migration.
5. Migrate representative test VMs, including stateful applications.
6. Verify data integrity, boot, network, DNS, time, performance, permissions and application paths.
7. Adapt monitoring, alerting, automation, inventory and documentation.
8. Migrate production workloads in controlled waves with defined abort criteria.
9. Practise recovery and fallback; document results and remaining deviations.
10. Retire the old platform only after functional and technical acceptance.

Historical PBS backups may still be needed during a transition for recovery on or through the existing Proxmox environment. Retention periods, availability of the old platform and a documented read path therefore belong in the migration plan.

Replaceability is an architectural property

Open standards and documented APIs

OIDC, SAML, LDAP and other established protocols can reduce coupling when they suit the purpose and are implemented correctly. A standard listed on a data sheet is not enough: claims, group mapping, certificates, failure behaviour and logout paths must be documented and tested.

Data portability

Export and import must cover the data, metadata, permissions, histories and attachments that are actually required. An export button is not yet proof of a verified transfer. Test imports and checksums provide stronger evidence.

Automation and separation

Version-controlled infrastructure and configuration sources make states reproducible. At the same time, hypervisor, backup, identity and application layers should not be mixed unnecessarily. Git-based Ansible automation is especially useful when general roles remain separate from platform-specific modules.

Documentation, validation and exit

Dependencies, interfaces, credential paths, recovery procedures and ownership must be documented clearly. Alternative platforms and recovery procedures belong in the lab on a regular basis. At introduction time, it should already be clear how data can be exported, which components would need to change and how long required legacy access must remain available. Open standards improve the starting point, but do not guarantee complete interchangeability.

A realistic time horizon without false promises

With sufficient preparation, technology changes should remain feasible within manageable, plannable periods. A blanket promise of only a few days would be misleading. The number and criticality of systems, data volume, application coupling, interfaces, availability requirements, compliance, available specialists and test scope determine the effort.

The architectural benefit is that alternatives and dependencies are documented from the beginning, automation remains reusable and migrations are rehearsed in the lab. A change therefore does not automatically become a fundamental project lasting many months. Production transitions still need their own risk, resource and schedule planning as well as functional and technical acceptance.

Where Europe is already well positioned

Limits of a European IT stack

• Integration: Standardised interfaces help connect production-ready components, but they do not automatically provide coordinated upgrades, uniform failure behaviour or end-to-end support.
• Operations: A modular stack requires additional integration, compatibility and recovery testing. Proxmox, SUSE and open projects must be assessed by the same lifecycle, monitoring and support criteria.
• Capabilities: Tightly integrated platform features, proprietary specialist applications, specialised hardware and established automation cannot always be replaced one for one.
• Supply chains: Dependencies remain in processors, manufacturing, firmware, network components, libraries, third parties and individual cloud services.
• Economics: A migration may be technically possible yet disproportionate when adaptation, parallel operations, testing and training cost more than the risk being reduced.
• Skills and accountability: Specialists, reliable documentation, vendor or community support and clear escalation paths determine whether self-hosting actually increases control.

A sound decision therefore compares more than licence cost or origin. It assesses technical dependencies, operating effort, outage risk, exit cost and available expertise across the intended lifecycle. Digital sovereignty is not a finished state; it is the demonstrable ability to control decisions and transitions under realistic conditions.

Our position at ForgeOne

We do not believe Europe needs to redevelop every IT technology. Many suitable products and open-source projects already exist. What matters is combining them sensibly, understanding their limits and building an architecture that remains adaptable over the long term.

We do not want to create another closed platform. Our approach is an open, modular infrastructure in which individual technologies and, where necessary, complete functional platform assemblies can be replaced in a controlled way. Technologies are tools, not irreversible decisions.

This also applies above the infrastructure layer: grommunio, Nextcloud, OpenProject and XWiki can cover different digital-workplace responsibilities depending on requirements. They become a sovereign system only with documented data paths, identities, backups, updates and exit options.

Conclusion

A completely European IT stack without international dependencies is currently feasible only to a limited extent. For clearly bounded requirements, a largely European and open-source-based stack can already be built. Whether it can be operated sovereignly must be demonstrated by the organisation through tested operating, recovery and exit procedures.

The real challenge is not finding a European product name for every proprietary application. It is connecting components so that organisations retain control over infrastructure, data and change.

For us, an IT architecture is truly sovereign when we can decide not only which technology to use today, but also which one we can replace tomorrow.

Our Digital sovereignty page provides a broader view of this approach; Backup and data protection explores requirements for protection and recovery in greater detail.