This article is based on a piece originally published at devops.com.
Why Legacy Migration Is a Pressing Problem
Modern organizations grow in two broad ways: organically, by building internal capabilities over time, or through acquisition, by absorbing companies that already have what they need. Both paths leave behind the same artifact—legacy infrastructure that was never designed for today’s cloud-native world.
For organically grown businesses, years of incremental decisions accumulate into a tightly coupled, difficult-to-change stack. For companies that grow through acquisition, the problem compounds: each acquired company arrives with its own tooling, platforms, and operational practices. The result is a heterogeneous environment that is expensive to run, difficult to automate, and slow to evolve.
Cloud adoption promises real relief. Moving workloads to cloud infrastructure can significantly reduce IT overhead costs and gives teams the elasticity to scale resources up or down on demand. Cloud environments also lend themselves well to automation, freeing engineering time that would otherwise be spent on manual operations.
Greenfield vs. Brownfield: The Reality Most Teams Face
In an ideal world, every team would start with a greenfield: a blank slate on which to design the optimal infrastructure from scratch. In practice, most engineering organizations operate in a brownfield—an environment layered with old systems, accumulated technical debt, and operational habits that resist change.
A brownfield environment is not inherently bad. Legacy systems often still deliver meaningful business value; that is precisely why they have not been decommissioned. The challenge is integrating them with modern cloud capabilities without breaking what already works, or writing off the investment those systems represent.
Hybrid cloud—a model that spans on-premises or legacy infrastructure alongside public or private cloud resources—has emerged as the practical answer for most enterprises. It allows organizations to modernize incrementally rather than all at once, which reduces risk and preserves continuity.
The Core Technical Challenge: Infrastructure Fragmentation
Even after you commit to a cloud strategy, fragmentation remains a serious obstacle. The major cloud providers each offer their own proprietary services and managed platforms. Teams that distribute workloads across providers quickly discover that each environment operates differently, making it hard to build consistent deployment pipelines, monitoring setups, or operational runbooks.
The result is what some engineers call “islands of infrastructure”—clusters of compute and storage that are built, deployed, and operated in incompatible ways. A DevOps team cannot maintain a truly consistent software delivery practice if the underlying platform changes significantly from one environment to the next.
Normalization: A Strategy for Consistency Across Environments
One of the most effective responses to infrastructure fragmentation is normalization—deliberately choosing tools and abstractions that behave consistently regardless of the underlying provider or hardware.
Open source technologies are well-suited to this role because they are not tied to any single vendor and can be deployed across a wide range of infrastructure targets. A normalized stack might look like this:
- Kubernetes for container orchestration, providing a consistent API for deploying and managing containerized workloads whether you are on AWS, GCP, Azure, or on-premises hardware.
- OpenStack for managing virtual machines in private cloud or data center environments, giving teams a familiar control plane that works independently of hyperscaler APIs.
- Serverless frameworks (such as Fission or OpenFaaS) for function-based workloads, abstracting away the underlying compute so that functions can run on any compliant platform.
The goal of this kind of normalized stack is not to eliminate all complexity—that is impossible. Instead, it is to contain complexity. Proprietary or environment-specific concerns get isolated to defined boundaries, while the majority of your application code and operational tooling can remain platform-agnostic.
Migration Approaches: Choosing the Right Strategy
There is no single right way to move a legacy system to the cloud. The appropriate approach depends on the system’s complexity, business criticality, and how much architectural change is acceptable. Common strategies include:
- Rehosting (lift and shift): Moving workloads to cloud VMs with minimal or no code changes. Fast and low-risk in the short term, but does not take advantage of cloud-native features and may carry the same operational overhead into the new environment.
- Replatforming: Making targeted changes—such as migrating from a self-managed database to a managed cloud database service—without rewriting the application. A middle path that captures some cloud benefits without full re-architecture.
- Refactoring (re-architecting): Fundamentally redesigning the application for cloud-native patterns, such as breaking a monolith into microservices. Delivers the greatest long-term benefits but requires the most time, skill, and risk tolerance.
- Retaining: Deliberately keeping certain systems on-premises because migrating them is not cost-effective or technically feasible at this time. A valid choice, and often part of a hybrid cloud strategy.
- Retiring: Decommissioning systems that no longer serve a business purpose. Often uncovered during migration planning and represents real cost savings.
For many organizations, the most pragmatic path is a combination: lift-and-shift in the short term to get off aging hardware, followed by incremental refactoring as time and budget allow.
Embrace Change as an Organizational Capability
Technical strategy alone is not enough. One of the consistent lessons from DevOps practice is that tooling changes succeed or fail based on whether the organization has also changed how it thinks about work.
The infrastructure ecosystem has evolved dramatically over the past fifteen years. Configuration management tools like Puppet and Chef established the idea that infrastructure should be defined as code. OpenStack brought open source principles to private cloud. Vagrant and later Docker made reproducible development environments mainstream. Kubernetes moved container orchestration from a niche concern to an industry standard.
Each of these shifts required teams to retire familiar practices and invest in new ones. Organizations that built a habit of adaptation moved through these transitions faster and with less disruption. Those that resisted found themselves repeatedly catching up rather than keeping pace.
For legacy migration specifically, this means building internal processes that support ongoing change: structured learning time, blameless retrospectives, cross-functional migration working groups, and executive support for the inevitable period of reduced velocity during transition.
Containing Complexity Rather Than Eliminating It
A useful mental model for legacy migration is that complexity cannot be destroyed—it can only be moved or reorganized. Every system that has run in production for years has accumulated essential complexity: edge cases that the code handles, operational knowledge that lives in runbooks, integrations with other systems that depend on specific behaviors.
The goal of a migration is not to produce a magically simple system. It is to move complexity from places where it is hard to manage—tangled codebases, undocumented server configurations, manual deployment processes—into places where it is easier to reason about and operate, such as well-defined service boundaries, infrastructure-as-code repositories, and automated pipelines.
Normalization supports this by providing consistent abstractions. When your containerized workloads all run through Kubernetes regardless of cloud provider, the operational complexity of multi-cloud management is largely contained at the cluster configuration layer rather than scattered throughout your application code and deployment scripts.
Practical Recommendations for Teams Starting a Legacy Migration
- Inventory before you migrate. Understand what you actually have. Document dependencies, data flows, integration points, and SLAs. Many migrations stall because teams discover mid-flight that a system has more connections than anyone realized.
- Prioritize by risk and value. Not every system needs to move at the same time or in the same way. Identify which systems are expensive to run on-premises, which are under active development, and which are stable but business-critical. Use that analysis to sequence your migration.
- Standardize your toolchain early. Decide on your container runtime, orchestration platform, CI/CD pipeline, and observability stack before you begin migrating workloads. Retrofitting these after the fact is significantly harder.
- Use infrastructure as code from day one. Whether you use Terraform, Pulumi, Ansible, or another tool, define your cloud infrastructure in version-controlled code. This makes environments reproducible and makes changes reviewable.
- Plan for the hybrid period. Most migrations take longer than initially projected. Design your architecture so that legacy systems and cloud-native systems can communicate reliably during the transition, not just after it is complete.
- Measure operational outcomes. Define what success looks like before you start: deployment frequency, change failure rate, mean time to recovery, infrastructure cost. Track these throughout the migration so you can demonstrate progress and catch regressions early.
Summary
Migrating legacy systems to the cloud is one of the most consequential and difficult infrastructure challenges an engineering organization can face. There is no silver bullet, and the right approach varies by organization, system, and business context. However, a few principles hold broadly: invest in normalization through open source, provider-agnostic tooling; choose your migration strategy based on the specific needs of each system; build organizational practices that support ongoing change; and treat complexity as something to be contained rather than eliminated.
A hybrid cloud model that combines the best of legacy investment with cloud-native capabilities gives most organizations the most realistic path to a modernized, cost-effective, and operationally sustainable infrastructure.