This article draws on panel discussion reported by computing.co.uk from Computing’s DevOps Summit. Panellists included Derek Weeks (Sonatype), Tom Padgham (UK Department for Work and Pensions), Aubrey Stern (Pizza Hut), and Rick Allan (Zurich Insurance).
The Question Every Enterprise DevOps Team Faces
“How can DevOps coexist with monolithic legacy applications?” is one of the most practically difficult questions in enterprise software delivery. It was put to a panel of practitioners at Computing’s DevOps Summit, and the answers were refreshingly honest: coexistence is possible, but the right approach depends heavily on business context rather than technology ideology.
Bi-Modal IT Is a Reality, Not a Failure
Many large organisations already operate what Gartner labelled “bi-modal IT” — simultaneously running fast-moving, customer-facing digital products alongside slower, more stable legacy systems. Managing this two-speed enterprise is difficult, but the panellists agreed it is workable. The key is being deliberate about which systems belong in which mode.
The consensus view: a legacy application that is not customer-facing and not a direct source of competitive advantage is often best left alone. Refactoring it may be expensive, carry significant risk, and deliver limited business value — especially when a large number of downstream applications depend on it.
Business Value Should Drive the Decision
Derek Weeks, VP and DevOps advocate at Sonatype, cautioned against treating DevOps as universally mandatory:
“They can coexist. A lot of DevOps practices are about business outcomes. Is the legacy application a competitive differentiator? If so then you need to replace it, or eat the elephant a bite at a time. But that’s going to be hard if it’s supporting the whole business.”
Derek Weeks, VP & DevOps Advocate, Sonatype
This framing is useful: before committing engineering effort to modernising a legacy system, ask what measurable business outcome depends on it changing. If the answer is “not much,” the investment may not be justified.
A Clean Slate Is the Exception, Not the Rule
Tom Padgham, head of operations at the UK Department for Work and Pensions (DWP), noted that starting fresh is a rare luxury:
“We were quite fortunate at the DWP as we were given a clean slate for Universal Credit. But there are plenty of examples where we have done that and it’s quite a challenge. You need to break it down, change the culture. You need to ask whether it’s really necessary.”
Tom Padgham, Head of Operations, UK Department for Work and Pensions
Padgham also pointed out that monolithic architecture does not automatically preclude high-velocity delivery — Etsy was cited as an example of a large monolithic application that operated effectively without decomposition into microservices.
Where the Two Speeds Collide: The Uncomfortable Middle
Aubrey Stern, DevOps lead at Pizza Hut, described the friction that emerges at the boundary between a modern, DevOps-enabled front end and a legacy data back end. Her organisation operated as a genuinely two-speed business, and the interface between the two was frequently the most difficult place to work:
“Very often change comes down to politics — who has clout within an organisation and the power to change things. We still talk to the EDW guys but we had to say we shouldn’t deal with this area because we don’t have enough push within the organisation to make the changes we’d like to see.”
Aubrey Stern, DevOps Lead, Pizza Hut
This is a common pattern: DevOps adoption advances rapidly on the application tier while the data layer — enterprise data warehouses, mainframe databases, ERP systems — remains largely untouched due to risk aversion, organisational politics, or genuine technical constraints.
Culture and Politics Matter as Much as Architecture
Rick Allan, global project delivery assurance at Zurich Insurance, shifted the conversation from technology to people. He argued that a legacy application does not need to be large or technically complex to become an obstacle — a small application with a resistant support team can be just as much of a blocker:
“I have business teams not used to making changes. So you end up with lots of small apps connecting everything up to make up for the ones that can’t change. DevOps appears to be tech driven but it’s the cart driving the horse unless it’s really demanded by the business.”
Rick Allan, Global Project Delivery Assurance, Zurich Insurance
Allan’s observation points to a common failure mode: when the business case for change is not clearly communicated, legacy teams have no compelling reason to adapt. The result is workarounds — additional integration layers, ad hoc connectors, and glue code — that increase overall system complexity without delivering the intended benefits of DevOps.
Practical Principles for Managing DevOps Alongside Legacy Systems
Drawing on the panel discussion, several principles emerge for teams navigating this challenge:
- Assess business value first. Is the legacy system a competitive differentiator? Does it directly affect customer experience or revenue? If not, the cost of modernisation may outweigh the benefit.
- Identify stable boundaries. Rather than attempting a full rewrite, define clear interfaces between the legacy system and newer components. Strangler Fig patterns — gradually replacing legacy functionality behind a stable API boundary — are widely used for this.
- Accept and manage no-go zones. Some systems will remain outside DevOps practices for organisational or technical reasons. Explicitly acknowledging this, as Stern’s team did, prevents wasted effort and reduces friction.
- Communicate the business case to legacy teams. Resistance to change frequently reflects a failure to explain why change is necessary. If the business benefit is real, it should be articulated to everyone affected, not just the DevOps team.
- Avoid workarounds that compound complexity. Adding integration layers to work around immovable legacy systems creates long-term technical debt. Each workaround should be a conscious, documented decision rather than a default response.
- Do not assume microservices are the answer. Decomposing a working monolith carries its own risks. Teams like Etsy have demonstrated that monolithic architectures can support high-frequency deployment with the right tooling and practices.
The Bottom Line
DevOps and legacy monolithic applications can coexist — but only if the organisation is honest about where the business value lies, where the organisational power to drive change actually sits, and which systems genuinely need to move faster. Applying DevOps practices universally, regardless of business context, is as likely to create problems as to solve them. The more useful question is not “how do we DevOps everything?” but “where does moving faster actually matter, and what is blocking us there?”