Assess a European destination: The Cloud Exit Check assesses the estate, target architecture and migration path. Arrange a consultation.
A Linode alternative in Germany could be a Linux server at Hetzner. For an environment with managed Kubernetes, a database and object storage, that answer is incomplete: the alternative must fit the services in use and the desired operating model. Hetzner, OVHcloud, Scaleway, IONOS and STACKIT are candidates whose documented building blocks we assess below.
This comparison starts from Linode/Akamai, DigitalOcean, AWS, Azure and Google Cloud. It distinguishes source services and potential target paths. The narrower guide Leaving AWS addresses destination selection from an AWS estate. As of October 2026. Selection and acceptance criteria here are our recommendations; we report no original benchmarks or customer tests.
Contents
- Distinguish source providers by their services
- Select European alternatives by workload
- Assess Linode beyond the VM plan
- Assess data location and privacy separately
- Capture costs and operational responsibility in full
- Prepare the move with acceptance criteria
- Our approach at WZ-IT
- Further guides
Distinguish source providers by their services
Linode is part of Akamai. This matters for the search term: a Linode environment can contain several Akamai cloud products. Cloud Manager covers VMs, Kubernetes clusters, NodeBalancers and Object Storage, among other services. Akamai: completed Linode acquisition, Cloud Manager overview.
The table names selected documented products and the assessment tasks we derive from them. It claims neither completeness nor feature equivalence between providers.
| Source provider | Examples of documented services | Capture before selecting a destination |
|---|---|---|
| Linode / Akamai | Linodes, LKE, NodeBalancers, Object Storage | Which components provide the application, networking and data layer? |
| DigitalOcean | Droplets, Kubernetes, App Platform, Managed Databases, Spaces | Which responsibilities belong to the platform service rather than your team? |
| AWS | EC2, RDS, S3 and Lambda | Which application paths depend on AWS APIs and permissions? |
| Microsoft Azure | Virtual Machines, Azure SQL, Blob Storage and Functions | Which identities, data models and integrations need replacing? |
| Google Cloud | Compute Engine, Cloud SQL, Cloud Storage and BigQuery | Which data and analytics capabilities does the destination actually require? |
Our suggestion: one inventory row per service, with data volume, interface, dependencies and responsible team. An application using PostgreSQL and files calls for a different assessment from one using proprietary event or analytics services. This classification narrows provider selection; it does not replace technical validation.
Select European alternatives by workload
Two questions help build an initial shortlist: should the destination mainly provide infrastructure, or should the provider also take on platform tasks? And which functions must remain available from the application's perspective?
| European candidate | Documented building block | Derived selection path |
|---|---|---|
| Hetzner | Cloud servers, API and firewalls, private networks | Assess a server-based design; explicitly assign administration of the OS, application and database |
| OVHcloud | Managed Kubernetes | Match platform scope, network integration and persistent data to existing container workloads |
| Scaleway | Kubernetes Kapsule | Assess a managed Kubernetes path; capture required integrations and operational boundaries |
| IONOS | Managed PostgreSQL | Match version, extensions, access and recovery requirements to PostgreSQL needs |
| STACKIT | PostgreSQL Flex | Check features and responsibilities for a managed PostgreSQL target design |
The table deliberately shows one starting point per provider, without limiting its portfolio. A suitable database service does not establish a complete target environment. Networking, deployment, identities, backups and observability belong in the same design.
Our selection approach: start with two candidates covering mandatory functionality. For each open point, record the missing product documentation or contractual specification. This distinguishes a missing requirement from an unfamiliar administration interface. For the reverse starting point, see Hetzner alternatives.
Assess Linode beyond the VM plan
Linode Kubernetes Engine is a managed Kubernetes service. A destination composed of cloud VMs therefore starts with a different operating model, even if Kubernetes is later installed there. Akamai: LKE.
For migration from Linode to Hetzner, we recommend the following mapping as an assessment framework:
| Existing component | Decision before migration | Suggested acceptance point |
|---|---|---|
| Linode VM with a local application | Rebuild the target or select an appropriate transfer method | Check boot, drivers, networking, services and the application |
| LKE with persistent volumes | Plan the target cluster and storage integration separately | Check data access, restart behaviour and recovery |
| NodeBalancer | Specify target TLS, health check and forwarding rules | Check reachability and failure paths |
| Object Storage | Inventory API actions, permissions and delivery in use | Check representative objects and required features |
| Managed database | Select the target product and operational responsibility | Check data, roles, queries and recovery |
These table entries are planning recommendations, not claims about completed tests. If a managed service is replaced with a self-operated component, the cost picture needs to include that additional responsibility.
Object storage also needs a feature list: S3 compatibility does not establish complete feature parity. Hetzner documents unsupported bucket replication and tagging actions, for example. Before selecting a destination, identify whether code or processes use these features. Hetzner: supported S3 actions.
Assess data location and privacy separately
A European provider, a German region and GDPR-compliant processing are separate assessment points. Hetzner lists cloud locations in Germany and Finland, as well as the USA and Singapore. The provider name alone therefore does not determine data location. Hetzner: locations.
For processing on behalf of a controller, GDPR Article 28 sets requirements for processors and the contract. Article 32 requires technical and organisational security measures appropriate to the risk. Transfers of personal data to third countries are subject to Chapter V, beginning with Article 44. An EU location alone does not cover these requirements. GDPR: Articles 28, 32 and 44.
As technical preparation, we recommend a data-flow list: primary region, backups, logs, monitoring destinations, administrative access and subprocessors. For each entry, specify which contractual documents and evidence need assessment. Legal evaluation of the actual processing belongs with the responsible privacy and legal specialists.
Capture costs and operational responsibility in full
Our comparison framework includes ongoing infrastructure, platform services, traffic, licences and operations. One-off migration, application changes and parallel operations are recorded separately. Compare the same period, data volumes and required scope.
| Cost block | Recommended evidence |
|---|---|
| Compute and storage | Resource inventory, utilisation, growth and a sized target design |
| Traffic and external connections | Bills and directional data flows, including a potential partial migration |
| Managed services | Current scope and the corresponding target scope |
| Operations and recovery | Ownership of updates, backups, recovery and incidents |
| Migration and parallel operations | Transfer method, adaptations, acceptance and rollback planning |
Do not automatically set unknown values to zero. If target operational responsibility is missing, the calculation remains incomplete. This method does not establish a universal price winner; the article therefore provides neither savings percentages nor unverified tariff comparisons.
A partial migration should undergo the same assessment. In particular, document which services remain with the existing provider and which connections between environments will be needed permanently. The decision then becomes a bounded target design rather than an incomplete full migration.
Prepare the move with acceptance criteria
We recommend an acceptance checklist before implementation. For each application, it specifies required functions and the person responsible for judging whether they are met. Data and permissions also need a traceable validation method.
- Record the estate: Inventory services, resources, data, access, dependencies and contracts.
- Determine the destination: Specify product, region, operational responsibility and replacements for required interfaces.
- Design the data path: Describe initial transfer, ongoing changes, consistency checks and backups.
- Define acceptance: Have business workflows, permitted and prohibited access, and recovery checked.
- Plan cutover: Document write access, DNS, observation and rollback conditions.
- Clean up the source: Cancel and remove only after approval and assessment of retention and deletion requirements.
This sequence is a planning framework. It promises no effort, duration or uninterrupted migration. An unresolved mandatory criterion remains an open decision point until it is substantiated for the specific target path.
Our approach at WZ-IT
The Cloud Exit Check is the starting point when the provider or operating model remains open. The offer covers estate analysis, costs, dependencies, target architecture and migration path. For an established Hetzner destination, see Linode migration and DigitalOcean migration. The migration hub lists further source providers.
Useful enquiry material includes a service list, cost export, data volumes, desired regions and existing responsibilities. Implementation or operations scope follows the specific offer. Mentioning a cloud product in this comparison creates no additional WZ-IT partnership or operations commitment.
Further guides
- Cloud exit strategy: capture costs and dependencies
- Leaving AWS: assess European destinations
- Compare DigitalOcean and Hetzner
Define destination selection and migration: The Cloud Exit Check assesses the estate and migration path. Arrange a consultation.
