Legacy Platforms Are Not the Enemy
You access the repository.
You delve into the Terraform code.
You examine the CI/CD pipelines.
And suddenly… confusion sets in.
Your initial thought—particularly if you’ve participated in courses, studied reference architectures, or attended cloud conferences—is often the same:
It appears wise. It seems professional. Yet, it’s one of the riskiest choices a platform engineer can make.
Why the “Just Rewrite It” Approach Can Be Misleading
The platform that’s causing you frustration isn’t merely theoretical. It has been operational, managing real production workloads for months, sometimes years. It has weathered:
- Incidents and outages
- Compliance audits
- Security exceptions
- Scaling challenges
- Real customer pressures
Every awkward conditional, peculiar module boundary, or makeshift pipeline trick likely has a backstory, rooted in past issues. This very platform enables applications to deploy, teams to deliver features, and the business to generate revenue.
Engineering Maturity Begins with Respect
When I guide platform engineers grappling with legacy Infrastructure as Code (IaC) or DevOps setups, I focus on curbing their misguided enthusiasm. Not because improvement is inherently bad—but because hasty improvements can be costly.
Real skill lies in enhancing an active platform without jeopardising the business.
The Fallacy of the “Big Rewrite”
A complete rewrite presumes you can:
- Uncover years of hidden business rules
- Pause feature delivery without affecting the business
- Prevent overlooking edge cases learned the hard way
- Deliver something significantly better—not merely aesthetically pleasing
In reality, extensive rewrites often lead to loss of functionality, new security vulnerabilities, more incidents, and—most painfully—eroded trust from stakeholders.
How Competent Platform Engineers Approach Legacy Platforms
Understand Before Judging – Chesterton’s Fence
Prior to removing anything, ask yourself why it exists. That peculiar Terraform condition or pipeline exception likely has a purpose:
- A regulatory scenario someone negotiated under duress
- A workaround for a pivotal enterprise customer
- A remnant from a past incident that caused major disruptions
Implement the Strangler Pattern for Platforms
You can’t reconstruct a landing zone overnight. Instead:
- Introduce new, well-designed Terraform modules alongside the existing ones
- Create new pipelines aligned with superior standards for new workloads
- Encourage new workloads to adopt updated patterns from day one
Adhere to the Boy Scout Rule in IaC
Whenever you interact with the platform—even for minor fixes—make an improvement:
- Refine a variable name
- Extract a reusable module
- Eliminate duplication
- Add a missing comment or update the README entry
Establish Safety Measures Before Refactoring
In platform engineering, safety measures are essential before making any changes:
terraform planvalidations in each pipeline- Policy-as-Code to identify drift and violations
- Drift detection within live environments
- Integration and canary environments to validate changes safely
The Key Takeaway
Engineering maturity is not about disliking legacy platforms. It’s about acknowledging what has sustained the company and evolving it thoughtfully.
This mindset shift represents one of the most challenging lessons in platform engineering:
From “I understand best practices” → To “I know how to implement them in a production environment.”
That transition differentiates engineers who can design platforms from those who can manage and evolve them responsibly. And this is the essence of true Platform Engineering.
Share this content:
