How do you choose between cloud and on-premises during a migration?

The choice between cloud and on-premises during a migration comes down to workload characteristics, compliance requirements, cost structure, and how much control you need over your data. There is no universal right answer – the decision depends on your specific combination of latency sensitivity, regulatory constraints, team capability, and long-term cost tolerance. The questions below unpack each dimension so you can make that call with a clear head.

Many of the teams we work with at Stackable are navigating exactly this decision – particularly when they need to run open-source data infrastructure across environments without surrendering control over where their data lives. Here is what that looks like in practice with the Stackable Data Platform (SDP).

What factors determine whether workloads belong in the cloud or on-premises?

The primary factors are data gravity, latency requirements, compliance obligations, and the economics of your access patterns. Workloads that process large volumes of data generated on-premises – or that must respond in milliseconds – often belong on-premises. Workloads with variable demand, short-lived compute needs, or global distribution requirements tend to favor the cloud.

Break your workload inventory into concrete dimensions before making any placement decision:

Data gravity: If your data is already on-premises and moving it costs more than running compute near it, keep the workload local.
Access patterns: Bursty, unpredictable, or seasonal workloads benefit from cloud elasticity. Steady, predictable loads are often cheaper on owned hardware.
Latency: Real-time event processing pipelines tied to physical infrastructure – manufacturing sensors, trading systems, hospital equipment – frequently cannot tolerate the round-trip to a cloud region.
Team capability: Cloud-native tooling requires different skills than bare-metal or virtualized on-premises infrastructure. Be honest about where your team’s expertise actually sits.
Regulatory scope: Some workloads are constrained by law, not preference. Identify these first and remove them from the debate entirely.

The practical takeaway: classify your workloads before you classify your infrastructure. Placement decisions made at the workload level are far more defensible than blanket “lift and shift” or “cloud first” mandates applied to everything.

What are the hidden costs of cloud migration that on-premises avoids?

The hidden costs of cloud migration include egress fees, per-seat licensing uplift, idle resource spend, and the operational overhead of managing cloud-specific abstractions. These costs rarely appear in initial migration estimates and frequently cause total cost of ownership (TCO) to exceed projections within the first two years.

The most common surprises teams report after migrating:

Data egress charges: Moving data out of a cloud provider’s network – to another region, another provider, or back on-premises – is billed per gigabyte. For data-intensive workloads, this becomes significant quickly.
Managed service premiums: Cloud-managed versions of open-source tools carry a markup over running those tools yourself. That premium is sometimes worth the operational convenience, but it should be a conscious choice, not a default.
Idle compute: Cloud environments make it easy to provision resources and forget them. Without disciplined resource governance, unused instances and storage accumulate silently.
Re-architecture costs: Applications built for on-premises infrastructure often need significant rework to run efficiently in cloud environments. This engineering time is rarely fully accounted for in migration budgets.
Support tier costs: Enterprise-grade support from major cloud providers is priced as a percentage of spend. As your cloud footprint grows, so does your support bill.

On-premises avoids most of these by replacing variable per-use charges with predictable capital and operational expenditure. The trade-off is upfront investment and the operational burden of managing physical infrastructure – which is real, but at least it is visible from the start.

How does data sovereignty affect the cloud vs. on-premises decision?

Data sovereignty refers to the principle that data is subject to the laws and governance frameworks of the jurisdiction where it is stored and processed. For organizations in regulated industries or operating under European frameworks such as the General Data Protection Regulation (GDPR), data sovereignty requirements can make on-premises or private cloud deployments the only legally compliant option for certain data categories.

The practical implications go beyond legal compliance. When data sits in a hyperscaler’s infrastructure, you are accepting that the provider controls the physical hardware, the network, and the software stack beneath your workloads. For many organizations in financial services, healthcare, or critical public infrastructure, that level of dependency may not be acceptable regardless of contractual assurances.

Sovereignty concerns also extend to supply chain transparency. If you cannot verify what software is running on the infrastructure processing your data – and whether it has been audited or patched – you cannot make meaningful claims about your security posture. This is increasingly relevant as regulators across Europe tighten requirements under frameworks like the NIS-2 Directive and the Digital Operational Resilience Act (DORA).

The cloud vs. on-premises decision, viewed through a sovereignty lens, is less about cost and more about control. Organizations that need to know exactly where their data is, who can access it, and what software is touching it will consistently find on-premises or self-managed private infrastructure more compatible with those requirements.

Should you migrate everything at once or use a hybrid approach?

For most organizations, a hybrid migration approach is more practical and lower risk than a full cutover. Migrating everything at once concentrates risk, requires a complete freeze on infrastructure changes during the migration window, and leaves no fallback if critical workloads behave differently in the new environment. A phased hybrid approach lets you validate assumptions before committing fully.

A workable hybrid migration strategy typically looks like this:

Classify workloads by migration readiness: Some workloads are straightforward to move; others have deep dependencies on local infrastructure. Start with the former.
Migrate non-critical or stateless workloads first: These give you real operational experience in the new environment without exposing critical data or services to migration risk.
Run parallel environments during transition: Keep on-premises workloads running while you validate cloud equivalents. Accept the temporary cost of duplication as a risk management investment.
Establish clear promotion criteria: Define what “working correctly” means before you migrate, not after. Latency thresholds, data consistency checks, and failover behavior should all be specified in advance.
Migrate stateful workloads last: Databases, streaming platforms, and data warehouses carry the most migration risk. Move them only after you have confidence in your tooling and process.

A hybrid cloud migration also gives you the option to leave some workloads on-premises permanently – which, for sovereignty or cost reasons, may be the right long-term answer for a portion of your stack.

How do you avoid vendor lock-in during a cloud migration?

Avoiding vendor lock-in during a cloud migration requires deliberate architectural choices: use open standards, prefer open-source tooling over proprietary managed services where the operational trade-off is acceptable, and design your infrastructure so that workloads can be moved without re-engineering the application layer.

The most common sources of lock-in during cloud migrations are proprietary data formats, cloud-specific APIs, and managed services with no portable equivalent. Each of these creates a switching cost that compounds over time.

Concrete practices that reduce lock-in exposure:

Use open data formats: Apache Iceberg, Apache Parquet, and open table formats ensure your data is readable outside the platform that wrote it.
Prefer Kubernetes-native infrastructure: Kubernetes runs on every major cloud provider and on-premises. Applications containerized and orchestrated through Kubernetes can move between environments without rewriting deployment logic.
Avoid proprietary streaming and messaging services where alternatives exist: Apache Kafka® runs anywhere. Compared to vendor-neutral alternatives, proprietary equivalents can tie your event architecture to a single provider.
Treat infrastructure as code: Declarative configuration makes infrastructure portable. If your infrastructure is defined in code and that code is cloud-agnostic, you retain the ability to redeploy elsewhere.
Audit managed service dependencies regularly: It is easy to adopt a cloud-native managed service for convenience and discover later that migrating away requires significant re-architecture. Track these dependencies explicitly.

Lock-in is rarely a single decision – it accumulates through dozens of small choices made during migration. Building a discipline around open standards from the start is far less expensive than unwinding proprietary dependencies later.

What questions should you answer before finalizing your migration strategy?

Before finalizing a cloud vs. on-premises migration strategy, you need clear answers to questions about data classification, total cost of ownership, compliance scope, operational capability, and recovery requirements. Skipping any of these produces a migration plan that looks complete on paper but breaks down under real conditions.

Work through these before you commit to a direction:

What data are you actually moving, and where does it need to live? Data classification drives placement decisions. Sensitive, regulated, or sovereignty-constrained data may not have a choice of destination.
What does the full TCO look like over three to five years? Include egress, licensing, support, and re-architecture costs – not just compute and storage.
Which compliance frameworks apply, and what do they require? GDPR, DORA, the NIS-2 Directive, and sector-specific regulations may constrain where and how you can run certain workloads.
Does your team have the skills to operate the target environment? A migration that lands in an environment your team cannot maintain creates operational debt immediately.
What are your recovery time and recovery point objectives? Disaster recovery requirements shape architecture. Make sure your migration plan satisfies them in the destination environment, not just the source.
How will you handle the transition period? Define how long you will run parallel environments, who owns the cutover decision, and what triggers a rollback.
What does “done” look like? Migrations without clear completion criteria tend to drag indefinitely. Define success before you start.

Answering these questions will not make the migration easy, but it will make the hard parts visible early – which is where you want to find them.

How Stackable helps with cloud and on-premises migration decisions

The SDP is built specifically for organizations that need to run open-source data infrastructure across environments without being forced to choose one permanently. Because the SDP is Kubernetes-native and cloud-agnostic, the same platform configuration runs on-premises, in any cloud, at the edge, or across a hybrid environment – without rewriting your deployment logic for each destination.

Specific capabilities relevant to migration decisions:

Environment portability: SDP operators deploy and manage data tools like Apache Kafka®, Apache Spark™, Trino, and Apache Druid™ through Kubernetes-native custom resources. The same configuration works regardless of where Kubernetes is running.
Infrastructure as code: All provisioning, configuration, and lifecycle management in the SDP are declarative. Your infrastructure is reproducible, auditable, and portable by design.
Data sovereignty by default: The SDP runs entirely in your own infrastructure. Your data does not leave your environment unless you choose to move it. No telemetry, no dependency on Stackable’s systems at runtime.
No vendor lock-in: The SDP is 100% open source. You are not locked into Stackable’s commercial offering to run the platform – the source code is available, the formats are open, and the tooling is standard Kubernetes.
Hybrid migration support: You can run SDP workloads on-premises and in the cloud simultaneously, making it a practical foundation for phased migrations that keep options open during transition.

If you are working through a migration decision and want to understand how the SDP fits your specific environment, talk to the Stackable team directly.