Not a day goes by without someone talking about cloud sovereignty and becoming less dependent on US tech giants (AWS, Azure, Google and so on).
Many make valid points. But plenty have a pretty fixed mindset on the topic, and I tend to put those into a few categories:
- The Sovereignty influencers (pushing alternatives at all costs)
- The «Advisors» (talking about how companies should do X, Y, Z when it comes to sovereignty without ACTUALLY giving any practical advice on the topic)
- The Open-source fanatics (Those that are pushing companies to adopt open-source alternatives to the big cloud providers, no matter what!
Sorry I am ranting here…
One point that many are arguing is that US government can access your cloud data (trough CLOUD Act which requires a warrant from a US judge, tied to a specific criminal investigation) (Which is actually true → https://www.actuia.com/en/news/sensitive-data-and-cloud-act-microsoft-france-admits-it-cannot-oppose-an-american-injunction/) but should I care?
And another point is why should we put our own money into a company in the US, should we be building our own infrastructure and services? (ill get back to this part)
Lots of people talk about getting back control. Far fewer talk about what actually makes sense. Many get lost in the story without thinking logically about it, as a business owner I want to focus on my core business so the logical approach I want IT services to run as stable, secure and cheap as possible. So I want to share my thoughts: Are we locked in the cloud? Does it make sense? Can we replace it? And how? (A fair warning, this post is going to get messy)
Many point to Denmark, Germany and Estonia for success stories building their own digital platforms and moving away from Microsoft services to going either to open-source or European platforms (I’ll get back to that…)
Denmark: Switching from Windows to Danish Road Traffic Authority switches from Microsoft to Linux – Announcements – NixOS Discourse
Germany: Moving to NextCloud Mecklenburg-Western Pomerania relies on open source | DVZ M-V
Estonia: X-Road – e-Estonia
The story on how we got here
When we look here in Norway and the digital history, many organizations both within the public and private sector have used lots of public cloud and especially Microsoft 365. This picture shows that almost all municipalities in Norway use Microsoft 365 → Post | LinkedIn
Most large organizations in Norway are actually using Microsoft 365 / Google Workspace if you look at the DNS, so it is safe to say that TODAY, RIGHT NOW most collaboration in Norway happens within US cloud cloud platform.
Now could all municipalities work together to form a single service to host a common collaboration solution for all instead of using a public cloud service that is integrated with different identity services? From a technical standpoint, of course! But the politics behind it is not gonna to make that happen.
Why did everyone move to Cloud? Because it’s SaaS. Compared to managing Exchange, SharePoint, and Skype for Business servers back in the days, a cloud service is alot easier to manage, always up to date, and packed with features. The counterargument is that it offers so many capabilities that it becomes hard to govern and maintain. But for those that have ACTUALLY managed Exchange, SharePoint, Lync Server knows all the pain involved with keeping those up to date.
When Office 365 debuted in 2011, there were NOT that many alternatives offering that range of functionality as a SaaS service. So many organizations made the jump. Eventually it became the “safe” choice for many, since now you have a community around it and your company has expertise on it.
In later years, companies also shifted workloads to the public cloud through PaaS and IaaS services. And as companies moved their own workloads, ISVs began building their own SaaS offerings on top of the cloud providers, because it gave them the scalability they needed.
Why were/and are companies moving to the cloud? (and still are…)
- Cost and focus. Datacenters were (and still are) expensive to run, along with the expertise and redundancy they demand. Companies wanted to depend less on hardware and infrastructure. Many ISVs wanted to focus on their core business building software, not managing infrastructure and other companies saw the same appeal in the cloud’s ease of use and pay-as-you-go model.
- Reach. While this doesn’t apply to most, global companies could scale to wherever there was a nearby cloud region.
- Service catalogue. Access to a wide range of ready-made services. But this is like when I order from a chinese restaurant I have a laaaaarge menu to choose from but I still choose the same old dish I have ordered like 100 times before.
- Potentially cheaper IT, without the on-premises overhead though in most cases, public cloud actually ends up more expensive especially if you are trying to do a lift and shift of services. However there are workloads where lift and shift makes sense and you save money in the cloud (Especially if you are using VDI workloads)
Now that so many organizations, both public and private, run workloads on the same providers and build expertise around them, communities and know-how have grown within the workforce. That, in turn, makes it a natural choice for new companies to move to the same “familiar” and “safe” platforms.
Close to twelve years ago, I worked with a company that moved to Microsoft 365 and Microsoft Azure, and for them the cloud made sense. Their business case was solid: they needed scalability for their services, global reach, and a few capabilities that were natively supported in Azure and integrated with their other ISVs.
Then, a few years ago, they hit a little snag: the cloud provider went offline for a few hours because of a roll-out that failed (Azure went down, and people actually noticed – Ars Technica ). What was the contingency plan? Nothing. Every workload was running in that one provider, so all they could do was wait….
(Can also mention that they got hit with many outages over the course of the last 12 years, such as Azure AD outage Microsoft’s latest cloud authentication outage: What went wrong | ZDNET)
Afterwards, they wanted me to guarantee it would never happen again. The problem… their services were so bundled and their logic so deeply integrated into the provider that there was no realistic way to move workloads or data elsewhere. Effectively locked in. Nice.
While I am highlighting Microsoft here, this happens with every vendor.
Last year! (October to be specific) We had
– US East 1 at AWS Which took down (Roborock, Ring Camera, Fortinite, Roblox, Snapchat and 100 other services) Because of an underlying DNS issue in DynamoDB
– Cloudflare because of a too large config file in the bot management service.
So while these outages become less and less frequent given that I have been working with these for a long time, it is always important to consider what will you do when it actually happens?
Move everything to another provider? What about backup?
How do I know you’re locked in? If a service runs on PaaS or SaaS that doesn’t use a universal standard or open-source tech, or depends on other services from the same vendor, you’re locked in.
In their case and their simple tech stack.
- Azure Web Apps (standard web frameworks)
- Azure Blob Storage (content delivery)
- Azure SQL
- Azure Entra ID for auth (Azure AD back then)
So ask yourself this, If the provider became unavailable tomorrow, could you run the service elsewhere without redesigning major parts of it? If the answer is no, it’s at least partly locked in.
The web application they had could be moved easily since it used a common framework. But their built-in logic depended on Blob Storage for data storage and Azure AD for auth, and their automation used native features for security, monitoring and scaling. We could make it globally redundant, but if the provider went down again, the outcome would be the same. And this would be the same if they used Google or AWS too
Now, none of this is new. We’ve always had vendor lock-in. When we ran VMware, we used their virtualization stack and their networking stack. Backup providers had to build against VMware’s backup APIs. Virtual machines were stored as VMDK files, so migrating them to another platform meant reaching for custom migration tools.
The difference with clouds is one of degree. With VMware you were locked into an infrastructure layer, but you still owned the workload. With PaaS and SaaS you’re handing over the workload and its data entirely and the higher up the value chain you go, the harder it becomes to move later.
Now back to the customer they ended up sticking with the current architecture and I think it is the same now in 2026.
Now let us look at another example.
Take two workloads, a virtual machine on Azure and a data platform built on Microsoft Fabric (or insert other platform here Databricks, Snowflake). Both live in Azure, but the effort to leave is worlds apart.
The VM sits low on the value chain. You brought the workload; the provider just gave you a computer to run it on. The OS, the application, and the data all live inside a virtual disk. To leave, you export the disk (VHD format), convert the format if needed, and boot it elsewhere, another cloud, or back on-prem. There’s some glue to redo (networking, identity, monitoring), but the workload itself is portable because you own everything inside the guest OS.
Fabric is the opposite. Here you didn’t bring a workload, you built one inside the provider’s platform, and Fabric is a bundle. Data lands in OneLake, ingestion runs through Data Factory pipelines, transformations live in Dataflows and notebooks, business logic is encoded as semantic models and DAX measures, reports are Power BI, and governance runs through Entra ID and workspace roles.
The raw data is the easy part to move since OneLake stores tables in open Delta/Parquet format, so you can copy those out. But the data was never the hard part, since the value is everything wrapped around it. The pipelines, the models, the reports, the security, the orchestration. None of it is portable since every piece is a Fabric-specific artifact with no drop-in equivalent elsewhere. Leaving Fabric doesn’t mean migrating your data platform; it means rebuilding it.
It does not mean that it is impossible to move from Fabric to another platform, but just that it will take a lot more time.
If we take data platforms as an example, what are the viable alternatives? Databricks, Snowflake, BigQuery, RedShift? Even if the data is stored using open formats the majority of the alternatives are still US based cloud services.
Some other examples…
| Migration scenario | Difficulty | Why |
| Move a virtual machine from on-premises infrastructure to the cloud and back again | Relatively easy | A VM is generally portable as long as the hypervisor and networking requirements are handled. |
| Move from Azure Data Factory to an equivalent service from another provider | Not easy | APIs, authentication, data logic, and integrations must be changed. |
| Move from Google Workspace to Microsoft 365 | Not easy | Email and files can be migrated, but integrations and business processes make the migration complex. |
| Move a database from Azure SQL to Amazon RDS | Moderately difficult | The data can be moved, but Azure-specific features, security controls, integrations, and operational processes must be rebuilt. But Amazon has its own migration tool. |
Data is portable. Business logic is often what creates vendor lock-in.
Just to summarize this part, the higher up the stack you go, PaaS/SaaS the more difficult it often is to move the service to another platform.
How locked are we to the public cloud?
Many are making the argument that one should move away from public cloud and US tech companies and choose EU based or open-source alternatives. Some say that it is easy to move . Nope it is not, since it all depends on the complexity of their tech stack, and secondly sure lets say that we can move 60% of the services, but how much functionality would we lose? How much would it also cost in added complexity?
When looking at lock-in I tend to divide it into 4 dimensions (Just from my architecture stand-point) while there are other dimensions as well such as compliance, politics etc.
Technical
Applications/services may depend on proprietary APIs, serverless platforms, databases, and messaging services such as Lambda, Azure Functions, DynamoDB, Cosmos DB, SQS, and Service Bus. Possible to move? Maybe, but will require changes to the business logic and or services that are using it.
Data
High transfer fees, proprietary formats, limited export tools, and data gravity can make moving large volumes of data expensive and complex. Moving data is of course in most cases fairly easy, but data alone is not worth much.
Skills
Teams may become dependent on one cloud platform through specialized expertise, infrastructure-as-code, automation, and established operational practices. While many have IaC in place to handle “different” providers, it is not as easy as just switching providers to another platform, you need to build new code and modules.
Integrations
Third-party backup, monitoring, security, and identity services may be closely integrated with one cloud platform, making migration more difficult. Again you might have dedicated backup products today that ACTUALLY support Microsoft, Google or AWS. Then you move to an european provider where your backup provider does not have ANY functionality or support for that cloud provider.
Let me describe one fictional customer with the typical cloud services from vendors, this summarizes many of the larger customers in the nordics.
- Collaboration services (Teams, Slack, Discord, Webex, and Google Meet)
- Office productivity tools (Microsoft Office and Google Workspace)
- CDN, networking, and security services (nearly 20% of all internet traffic currently passes through Cloudflare)
- Operating systems and patch management (Windows, Chromebooks, Mac)
- Monitoring and logging systems (Datadog, Azure, AWS, and GCP)
- Source code platforms (GitHub and Azure DevOps)
- Integration platforms (MuleSoft Cloud, Logic Apps, Data Factory)
- Identity management with Microsoft Entra ID, Okta)
- Security systems (EDR, MDM, and SIEM) – Mostly Microsoft MDM and Sentinel, Defender, Crowdstrike)
- Data storage services (Amazon S3, Azure Blob Storage, and others)
- Data platforms (BigQuery, Microsoft Fabric, Databricks, and Snowflake)
- ERP and CRM tools and services with numerous integrations
- IaaS/PaaS: Google, Microsoft, AWS.
Another aspect is GenAI services which are really difficult to replicate on-premises with the same level of performance/quality like with GPT 5.6 and Fable, we are locking ourselves more and more to the cloud providers.
Sure many of the tools and models can run on-premises, but! If you want to have tools and capabilities that are similar to what you can get with a frontier model like Fable or GPT 5.6 you need to invest in infrastructure for at least a few million to run LLMs like Kimi-K3.
Can many of these be replaced? Sure! However with some loss of functionality and not all.. Secondly it is also important that there are also dependencies into many of these services such as identity integration, many ISVs are using native features in Entra ID to provide identity integration with their product, so even if you “move” from one platform to another one you might still be heavily dependant on Entra ID.
But! Let’s take a look at some alternatives! This is a mix of Open source and European alternatives.
- Collaboration services (Nextcloud, Mattermost, Rocket.Chat, Element, Proton)
- Office productivity tools (LibreOffice, Collabora Online, and OnlyOffice)
- CDN, networking, and security services (Bunny CDN, Varnish, HAProxy, Traefik, Caddy, OPNsense, and pfSense)
- Operating systems and patch management: (Linux, Ubuntu Landscape, SUSE Manager, Foreman/Katello, Ansible, and Uyuni)
- Monitoring and logging systems: Graylog, Splunk, the Elastic Stack (ELK), Grafana, Prometheus, Loki, OpenSearch, and Zabbix
- Source code platforms: self-hosted Git, GitLab, Gitea, Forgejo, and Bitbucket Data Center
- Integration platforms: n8n, Apache Camel, WSO2, Node-RED, Windmill automation.
- Identity and access management: Gluu, Keycloak, authentik, FreeIPA, and OpenLDAP
- Security systems: FortiEDR, Wazuh, Security Onion, CrowdSec, Suricata, and Velociraptor)
- Data storage services: Cloudian, MinIO, Ceph, OpenStack Swift, and SeaweedFS
- Data platforms: HPE GreenLake, Apache Spark, ClickHouse, PostgreSQL, Trino, Apache Iceberg, and self-hosted data lakehouse platforms
- ERP and CRM tools and services: Macro, ERPNext, SuiteCRM, Dolibarr, and other self-hosted platforms with extensive integration capabilities
- IaaS/PaaS: Hetzner, Upcloud, OHVCloud, Scaleway,
- AI services: Ollama, LocalAI, vLLM, llama.cpp, Open WebUI, and other self-hosted AI and large language model platforms.
I can also mention that there are actually alternatives to Claude Cowork as well, with new open-source tools like Cloudflare OS and Openwork
And in regards to Collaboration, Nextcloud is actually a faster option compared to Office 365 and Buzz (is a really good slack alternative)
While many of these products are great and some cloud services are waaay cheaper than their US counterparts, it takes time and effort to gain competency and expertise on these products as well.
As one example in terms of moving to a cheaper option → https://basecamp.com/cloud-exit
But let me emphasize that there are many good alternatives now and it all depends on what kind of requirements companies have! For instance European alternatives have their own website showing different european alternatives and options within different categories → https://european-alternatives.eu/
European companies like Scaleway, OVHCloud, UpCloud and others are now providing a pretty decent list of services and quite cheap compared to many cloud providers as well. Just to showcase some services they have and the price for it.
| Feature / Price | US Cloud Provider 1 | US Cloud Provider 2 | UpCloud | OVHcloud | Hetzner | Scaleway |
| 1 VM — 4 vCPU, 16 GB RAM, 150 GB NVMe, comparable CPU, hosted in the EU | $2,222/year | $1,746/year | $1,323/year | $1,065/year | $747/year | $1,206/year |
| Object storage — 1 TB | $277/year | $244/year | $239/year | $96/year | $113/year | $114/year |
| PostgreSQL database — 2 vCPU, 8 GB RAM, excluding storage | $2,105/year | $1,425/year | $849/year | $2,028/year | N/A | $1,116/year |
| Service portfolio | Extensive | Extensive | Storage, Kubernetes, networking, IaaS, and databases | Storage, Kubernetes, networking, IaaS, databases, AI, and data analytics | Storage, networking, and IaaS | Very extensive |
These are using “pay-as-you-go” prices, and while this is an apple/orange comparison it’s still fruit! Just simple IaaS services can be as much as 3x times cheaper compared to the BIG 3.
Again there are many alternatives out there, but as I said initially it is more about what makes sense, especially if I were a CEO/CFO/CIO at a company.
So should we move our eggs into different baskets or all in one? And what direction should we go?
The 3 main approaches that many companies take.
Accept lock-in: Maximize innovation and reduce complexity by fully using vendor native cloud services. Best when speed matters more than portability. This is just embracing the preferred vendor.
Abstract: Balance innovation and flexibility with containers, open standards, custom APIs, and abstracted services. This is the main route that many of the larger companies take. Building on cloud-native technology stacks where the majority of the ecosystem is open-source based tools and components.
Multi-cloud: Design for multiple cloud platforms from the start to maximize portability and reduce provider dependency but expect significantly higher cost and MUCH Higher complexity.
The good news!
There are far more mature alternatives today than before, both open-source based and European vendors compared to when I started with public cloud a looooong time ago.
Then another aspect is regardless of which direction I take I still have public cloud services, what is my exit strategy? And wtf is that?
I still see a cloud exit strategy as more of an IT Emergency plan, those that need to comply with DORA need to have one in place.
This exit plan should contain a practical roadmap for maintaining operations during outages, service changes, contract changes, or a full provider migration (IF Possible!)
- Clear exit scenarios, triggers, responsibilities, and decision-making authority.
- An inventory of critical systems, data, integrations, and provider dependencies.
- Procedures for exporting data and migrating or replacing services.
- Realistic estimates for cost, time, operational risk, and required skills.
- Continuity, rollback, testing, and recovery procedures.
The plan should be regularly updated and tested as cloud platforms, services, and regulatory requirements update quite frequently (even up to 1200 new changes each year)
Here as well there are some free tools that can be used to map your dependency → https://github.com/escapecloud/cloudexit
And in addition the NHS has some great guidelines as well → https://digital.nhs.uk/services/cloud-centre-of-excellence/strategy/nhs-cloud-exit-strategy
Now to wrap this long blogpost up! I just want to say one or a few things…
There is no single right strategy or approach. The best approach depends on how you want to balance innovation, cost, and portability.
Another thing I want to add is that in many cases now there are many better, cheaper options (which can be both european and open-source) compared to many tools/services you might have been running for many years, so always keep your eyes/ears open to alternatives.
The biggest risk isn’t relying on a single provider, it’s not knowing how dependent you really are.