When a Swedish government agency needs to move Teams, Confluence, and critical infrastructure to the cloud, a conversation should be simple. Instead, it fractures into three separate arguments happening in the same room.

The lawyers are asking: Where do our citizens' data live, legally? The provisioning engineers are saying: We can spin up a server anywhere. The decision-makers are wondering: What's the actual difference between cloud and our existing servers?

They're all technically correct. And they're all talking past each other.

The problem isn't Atlassian, cloud providers, or Swedish regulation. The problem is that "cloud" has become a word that means different things to different people, and nobody pauses to name what they actually mean.

What "Cloud" Actually Means

Here's the myth: Cloud is just renting a server in someone else's datacenter.

Here's the reality: Cloud is a set of architectural properties. Some of those properties are:

  • Multi-tenancy (or isolation layers that simulate it): Multiple organizations on the same infrastructure
  • Elasticity: Resources scale up or down based on demand, not pre-provisioned capacity
  • Self-service provisioning: You deploy it yourself without filing a ticket
  • Pay-per-use metering: You pay for what you use, not for peak capacity
  • Automated updates and patches: New versions roll out continuously without your intervention
  • Geographic distribution and redundancy: Your data and services live in multiple places

None of these properties require you to use AWS, Azure, or Google Cloud. They're architectural choices. They can exist in your own datacenter, in a cloud provider, or in a hybrid mix.

Once you see cloud this way, the confusion starts dissolving.

Why Atlassian Went "Cloud Only"—And What That Really Means

Atlassian didn't sunset their on-premises products for business reasons alone. They did it because Confluence cloud and Confluence on-premises are architecturally different products.

The on-premises version assumes:

  • Single-tenant isolation: Your data is siloed on your servers
  • Versioned releases: You decide when to upgrade
  • Feature stability: Certain features designed for on-premises are incompatible with multi-tenancy

The cloud version assumes:

  • Multi-tenant data model: Data from many organizations shares the same infrastructure (with strict isolation)
  • Continuous deployment: Updates roll out constantly
  • Feature alignment: Features are built differently to work at scale across thousands of tenants

This isn't a licensing decision; it's an architectural decision. Once you commit to multi-tenant architecture, maintaining two separate codebases—one for cloud, one for on-premises—becomes unsustainable. You have to choose one, and Atlassian chose cloud because that's where the operational leverage is: one version, one infrastructure, one deployment pipeline.

Their motive wasn't to maximize data control; it was to minimize operational complexity.

Why Sweden Needs Its Own Infrastructure

GDPR and Swedish data sovereignty law aren't negotiable. They're also real constraints.

A US cloud provider (AWS, Azure, Google) has legal obligations under the Patriot Act and other US law that can conflict with Swedish law. The political question—"Can we trust US providers?"—is secondary. The legal question is primary: Can we operate within both jurisdictions at the same time?

The answer for Sweden is: build sovereign infrastructure.

But here's the critical part: sovereign infrastructure doesn't mean rejecting cloud architecture.

It means: Apply cloud architectural properties to infrastructure you control.

What On-Premises Cloud Actually Requires

If Sweden decides to run Confluence (or any complex service) on sovereign infrastructure, they can absolutely have cloud properties. It requires:

  • Kubernetes and containerization: Not optional. This is the baseline for elasticity and self-service.
  • Infrastructure-as-Code: Terraform, Ansible, or similar. You're defining infrastructure declaratively, not clicking buttons.
  • Continuous deployment pipeline: Automated tests, staged rollouts, automated rollbacks on failure.
  • Monitoring and alerting: Not optional. If something breaks at 3 AM, someone needs to know.
  • Backup and disaster recovery: More complex than a single box. You need multi-region failover, point-in-time recovery, and tested restoration procedures.
  • Expertise to operate it: This is the actual cost. You need a team that understands distributed systems, Kubernetes, networking, and compliance.

Ballpark: That's a minimum of 3–5 full-time engineers to maintain this, plus on-call rotation. It's not a one-time project; it's an ongoing operational responsibility. And it takes 18–24 months to get to operational maturity, assuming you have people with Kubernetes experience.

The Real Problem: Policy Pressure Without Strategy

Here's what I'm seeing from conversations with colleagues managing Confluence: policy constraints arrive faster than strategy.

The EU is explicit about this. In June 2026, the Commission released a Tech Sovereignty Package specifically designed to reduce European dependence on US cloud providers. The message is clear: strategic autonomy means sovereign infrastructure. AWS responded immediately by launching a "European Sovereign Cloud" service.

But at the Swedish government level? There's no published roadmap. No public strategy. No transparent budget. Work might be happening—budget might exist—but it's not accessible unless you demand the documentation.

So what happens? Implementation teams (people like my colleagues) feel the pressure first. Compliance questions arrive. Legal constraints show up. Procurement gets more complex. But there's no clear answer to the foundational question: What are we actually supposed to be building toward?

The provisioning tech says: "It's just a server. We can stand up a VM in our datacenter." That's technically correct, but it doesn't solve the architectural question.

The lawyer asks: "Who has access to the data?" That's the right question, but it's being asked to someone who thinks in terms of VMs, not architectural patterns.

The real problem isn't stupidity or incompetence. It's a capability gap: the organization doesn't have someone who can translate between EU policy pressure, compliance requirements, architectural constraints, and operational reality at the same time. If that conversation is happening somewhere, it hasn't reached the implementation teams yet. And if the gap exists in public documentation, it probably exists in the organization too.

The Cost/Risk/Timeline Tradeoff

If Sweden commits to sovereign Confluence:

Cost: An ops team (3–5 people, ongoing). This costs more than the subscription to cloud Confluence, but you get data sovereignty. It's a legitimate tradeoff, not a bug.

Risk: Operational burden. Who's on call at 3 AM when the database runs out of disk space? When a network card fails? When a security patch needs to be deployed? Cloud providers hire people to answer these questions. If you run your own infrastructure, you become that people.

Timeline: Not months, not years. It depends entirely on your existing expertise. If you have experienced Kubernetes engineers, 18 months. If you don't, add another year of hiring and learning.

The Pragmatic Path Forward: Hybrid

Here's where the conversation shifts from theoretical to operational:

You don't have to choose sovereign or cloud. You can choose both.

Some workloads are genuinely safer on a US cloud provider (because the operational burden of running them yourself outweighs the risk). Some workloads—Teams, Confluence, citizen-facing services—belong in sovereign infrastructure.

AWS has a Stockholm region. Azure has a Stockholm region. Google Cloud doesn't, but it's worth checking the specific compliance requirements.

The pragmatic path:

  • Critical, citizen-facing workloads (Confluence, Teams, databases) run on sovereign Kubernetes
  • Auxiliary services (analytics, logging, external APIs) run on AWS Stockholm or equivalent
  • Development and testing can run on cloud providers cheaply, then sync back to sovereign infrastructure

This isn't perfect cloud architecture. It's pragmatic architecture. And pragmatism is what actually scales.

The Right Question

Stop asking: Should we go cloud or on-premises?

Start asking: What architectural properties do we need, and where can we actually get them?

Sweden absolutely can have cloud architecture in sovereign infrastructure. But it requires naming the actual problem: an expertise gap, not a technology gap.

The fix isn't buying more servers. It's hiring the right people—or building the right team—to think across regulatory requirements, architectural constraints, and operational reality at the same time.

When that team exists, the conversation changes. The lawyers know what questions to ask. The engineers know what patterns to build. The decision-makers can decide based on fact instead of confusion.

And Sweden gets what it actually needs: infrastructure that's both sovereign and sane.

Brasklapp

I don't know what's happening at the central government level. Strategic decisions, budget allocations, organizational priorities—that's opaque from where I sit.

What I do know: This has been an open question for years. Ever since Microsoft made 365 non-optional, Swedish government agencies have been caught between compliance pressure and no clear alternative. Years have passed. Some decisions have been made about when US cloud is acceptable. But I haven't heard about a coherent cloud solution for governmental agencies.

That gap—years without visible progress toward a strategy—is what prompted this post. Whether the gap reflects decision-making caution, organizational friction, or competing priorities, I can't say. But the friction is real at the implementation level, and the policy pressure from the EU is real in June 2026.

This post reflects what's observable: the EU policy direction, the ground-level friction, and the missing link between them. If I'm wrong about what's happening behind closed doors, that's fine. But if you're a 2nd or 3rd line tech dealing with the same friction, I hope this framing helps clarify what you're actually seeing.