The Leap from Cloud to Multi-Cloud: A Practical Playbook from Damjan Gjurovski (Posedio)

Why this session stood out

At DevJobs.at, we hear a lot about cloud strategy. Few talks are as grounded and operational as “The Leap from Cloud to Multi-Cloud” by Damjan Gjurovski, CTO at Posedio. Instead of buzzwords, he offers a disciplined approach: Multi-cloud is not a pile of tools; it’s a unified strategy across providers with shared conventions, strict security, and a golden path for developers. The message is precise: multiple clouds become multi-cloud only when the organization behaves like one platform.

What multi-cloud is—and what it isn’t

Many companies look multi-cloud at a glance: Power BI and Office 365 in business units, apps on VMs or Kubernetes, a marketing pipeline from Google Ads into BigQuery, plus some on-prem databases. It’s a lot of surface area. Is that multi-cloud? Gjurovski’s answer is no.

That distinction matters. Without a common architecture, governance, security model, and developer path, you have sprawl—not multi-cloud.

The three drivers behind the leap to multi-cloud

Gjurovski frames the “why” with three drivers. We found them pragmatic and complete—technical autonomy, risk control, and organizational reality.

1) Use the right tool for the job

Cloud providers specialize:

• GCP for data-heavy work, BigQuery, AI/ML.
• Azure for Windows services and .NET.
• AWS with mature serverless like Lambda and the earliest broad offerings.

Teams closest to the problem know what they need. “Right tool for the job” becomes an organizational principle: decentralize decisions and unlock the full potential of your engineering organization, instead of squeezing everything into a single provider’s stack.

2) Manage risk—technical, financial, operational

• Avoid vendor lock-in: lock-in invites price hikes and limits leverage.
• Optimize TCO: compare offerings, create price pressure, negotiate contracts with credible alternatives in hand.
• Ensure business continuity: when a provider or region goes down—or compliance, governance, or legal constraints change—you need a backup plan. Gjurovski explicitly places this in a FinOps context.

3) It will happen anyway: shadow IT

If teams need autonomy and IT says “no,” they route around it. Shadow IT emerges—and with it, de facto multi-cloud without strategy. Gjurovski points to estimates where the number of cloud products actually used can be an order of magnitude higher than IT suspects (he mentions ranges around 15–25x). The point isn’t the exact multiple; it’s that ignoring drivers one and two still lands you in multi-cloud—just without a unified architecture.

How multi-cloud works: four technical pillars

The talk’s strongest contribution is a concrete, repeatable scaffold. Regardless of company size, these pillars sequence the work and reduce surprises.

1) Base setup: assess the org, define conventions, go all-in on IaC

Before deploying anything, assess:

• Departments and their operating model; cross-cutting concerns.
• Risk posture, governance, security requirements.
• Regulatory constraints.
• The current/“old” cloud solution and its gaps.

Then codify conventions:

• Naming, labeling, and a clear folder/project structure.
• Centralized governance and security with decentralized team decision-making so people can get work done.
• Infrastructure as Code (e.g., Terraform) for reproducibility and disaster recovery.
• Consider sustainability (green cloud) to enable future FinOps/asset management.

This base layer doesn’t ship features. It enables all benefits that follow.

2) Networking: first connect everything, then stop what shouldn’t connect

Connectivity is table stakes:

• Links from on-prem to the data center.
• Interconnect between cloud providers.
• VPNs to developer and business machines.
• A non-colliding IP plan.

Gjurovski is blunt: IP range conflicts are a nightmare and will block your integration. Treat IP planning as a first-class design step.

The order of operations is practical and memorable:

3) Security and identity: least privilege, short-lived access, lifecycle integration

Security follows least privilege with guardrails:

• Control traffic between providers and within each cloud.
• Avoid long-lived credentials; don’t let service account keys lie around.
• Aim for zero trust so secrets don’t leak and blast radius stays contained.

A frequently overlooked area is identity lifecycle management:

• Onboarding: new hires get identities and the access they need from day one.
• Offboarding: access is revoked automatically across all systems.
• Department changes: permissions follow the person—marketing can’t keep seeing leads after moving to accounting, but should see invoices.

This requires identity shared across clouds and consistent permission management—without manual cleanup.

4) Shared services: one entry point, a golden developer path, easy migrations

Multi-cloud demands a unified platform experience:

• A single entry point, even if workloads deploy to different providers.
• A golden path for developers: familiar workflows that reduce relearning and mistakes.
• Easy migrations between providers. Teams should be able to move an app with minimal effort—ideally without users noticing.

A common anti-pattern is double-deployments without a move capability. The migration path is what makes multi-cloud actionable.

The missing piece: multi-cloud goes both ways

A sharp insight: teams often engineer the new cloud by the book—IaC, modern security, best practices—while leaving the old cloud untouched. That splits the organization into two standards and accumulates debt.

Concretely:

• Backport what you’ve learned from the new setup into the old one.
• Grow both environments in parallel so teams share knowledge and stay aligned.
• Operate with a single cloud platform team across providers to avoid silos and the politics of “who deploys where.”

The journey in stages: from single-cloud to multi-cloud

Gjurovski closes with a sequence we’ve seen work in practice. It reads as a pragmatic roadmap straight from the talk:

1) Assess the existing solution

• Reduce risk and push decisions down to the teams with the most context.

2) Set up the new cloud

• Follow best practices rigorously.
• Do everything with Infrastructure as Code; don’t repeat initial click-ops mistakes.

3) Ensure interoperability

• What works in Cloud A should work in Cloud B, with explicit exceptions.
• Make deployments and migrations straightforward.
• Keep developer experience at the same high level on both clouds.

4) Continuously improve

• Co-develop both clouds.
• Share knowledge.
• Aim for a long-lived, successful parallel setup.

The questions platform and engineering leaders should ask now

Grounded in Gjurovski’s framework, these questions can guide your first planning session:

• Organization: Which departments and cross-cutting concerns shape our platform? What compliance and regulatory constraints apply?
• Conventions: What are our naming, labeling, and folder/project structures? Which policies will we enforce by default?
• IaC: What’s codified today? Where do we rely on click-ops? How do we version, test, and roll back infrastructure changes?
• Networking: Which IP ranges are in play? Where might conflicts arise? What connectivity is required On-Prem ↔ Cloud ↔ Cloud ↔ VPN?
• Security: How do we enforce least privilege? Where do long-lived credentials exist? How do we eliminate service account key sprawl?
• Identity: How do we integrate the company user lifecycle across both clouds? How do we automate onboarding, offboarding, and department moves?
• Developer Experience: What is our golden path? How do we abstract provider differences without blocking team autonomy?
• Migration: How do we move workloads between clouds with minimal effort and no visible user impact? Where are our runtime/delivery gaps?
• Ownership: Do we have a single platform team across providers? How do we prevent silos and conflicting standards?
• FinOps: How do we measure and compare TCO across providers? How do we reflect price and contract levers in architectural decisions?

Common pitfalls—called out explicitly in the talk

• IP conflicts ignored until late: connectivity breaks down, integration stalls.
• Long-lived credentials and stray service account keys: increased risk and operational drag.
• Missing lifecycle integration: permissions persist after offboarding or department changes—compliance risk.
• Double setups without a migration path: teams are stuck instead of flexible.
• A pristine new cloud while the old one stagnates: knowledge gaps widen; true multi-cloud never materializes.
• Over-centralized governance: teams lose momentum; the strategy fails at the execution layer.

Developer experience as the force multiplier

One of the session’s strongest undercurrents is developer experience. A single entry point and a golden path are not polish; they’re how you make multi-cloud safe and fast. If each provider forces developers to relearn core workflows, you multiply mistakes and slow delivery. Standardize the “how,” and let teams choose the “where.” That’s how “right tool for the job” becomes a competitive advantage rather than operational chaos.

Quote highlights for clarity and memory

• “Right tool for the job”—teams closest to the problem pick the best-fit services.
• “First connect everything; second stop everything from connecting”—a crisp sequence for networking and security.
• “Multi-cloud goes both ways”—backport improvements to the old setup.
• “The name of the game is multi-cloud, not cloud replacement”—avoid creating two worlds.

What to do next—directly inspired by the session

• Spend a focused week on inventory: organization map, existing cloud topology, IP plans, policies, click-ops hotspots.
• Define conventions and an IaC framework within a month: naming, labels, folder structure, policy-as-code, identity integration.
• Plan connectivity in parallel: eliminate IP collisions, map On-Prem ↔ Cloud ↔ Cloud links, and VPN paths.
• Establish guardrails: least privilege, short-lived credentials, remove service account keys-at-rest.
• Design the golden path: a single entry point, reusable delivery steps, the same DX bar across providers.
• Build a “walking skeleton” migration early: move a small app end-to-end between providers so teams see the path.
• Launch a backporting track: feed lessons learned into the old environment; retire click-ops.
• Charter one platform team for both clouds with a clear mandate to avoid silos.

Closing: multi-cloud as discipline, not a tool list

“The Leap from Cloud to Multi-Cloud” by Damjan Gjurovski (Posedio) is an operational blueprint. Multi-cloud emerges when organization, networking, security, identity, and shared services align under one strategy—and when that strategy applies equally to old and new environments. Our core takeaway: the benefit isn’t “more providers,” it’s “one platform, multiple targets.” That yields team autonomy, cost leverage, risk reduction, and a foundation that respects each domain’s tools.

A final litmus test: Can we move workloads between providers with minimal effort and no user impact? If yes, you have multi-cloud. If not, it’s just sprawl—and the next IP conflict or credential leak will remind you of the difference.