This article is based on reporting originally published by Computer Weekly, featuring insights from Justin Dean, Senior Vice-President for Technical Operations at Ticketmaster.
The Legacy Problem DevOps Teams Can’t Ignore
The fundamental challenge of legacy IT is straightforward: you can’t just switch it off. Core production systems built before the era of cloud computing often sit at the heart of a business, processing transactions and storing critical data that newer services depend on. For organisations trying to adopt DevOps, these systems represent both a constraint and an opportunity.
Ticketmaster’s journey illustrates this tension in concrete terms. Founded decades ago, the company’s core ticketing software was originally written for a Vax minicomputer. Through acquisitions and platform expansions onto the web, its IT estate grew into a highly heterogeneous environment — ranging from mod_perl powering its websites to Java Virtual Machine and Tomcat-based services running inside Docker containers. The Vax itself still runs, not on physical hardware, but as a software emulator wired into a surrounding ecosystem of supporting software and APIs.
Why Ticketmaster Moved to DevOps
Ticketmaster began its DevOps transformation in 2013. The motivation was a familiar one: speed to market. Justin Dean, Senior VP for Technical Operations, describes the core shift in thinking:
“For us, it really started with DevOps. Part of our transformation was to focus on delivering business value faster and delivering more of it, and the driver was speed to market of product.”
Justin Dean, SVP Technical Operations, Ticketmaster
Critically, the teams also changed how they measured IT value. Rather than measuring output — the volume of work completed — they shifted focus to outcomes: the business impact of what was delivered. This reframing encouraged teams to prioritise higher-value work and move more quickly.
Friction: The Hidden DevOps Blocker in Legacy Environments
Even when development teams and business stakeholders both want to move faster, legacy IT introduces friction that slows everything down. At Ticketmaster, the friction was structural:
- Developers who needed new infrastructure — even something as routine as a new version of Apache — had to submit a helpdesk ticket to a separate operations team.
- Waiting for that ticket to be processed created significant delays.
- The infrastructure was considered too complex and too risky to give individual teams broad access.
- Teams lacked autonomy: they could write code, but depended on others to deploy it.
This pattern is common in organisations with large legacy estates. The operations team becomes a bottleneck not out of negligence, but because the complexity of the underlying systems makes self-service too risky without proper controls and tooling.
Using Containers to Break the Bottleneck
One of Ticketmaster’s practical solutions was to use containers — specifically Docker — not just for isolation of application code, but to isolate units of work in the deployment pipeline. By containerising code and pushing it through a standardised deployment pipeline, teams could take full ownership of deploying their own software without needing to understand the full complexity of the surrounding infrastructure.
The goal was zero friction at the team level:
“The team does not have to get help externally, so they can move as fast or as slow as they want. On the flipside, the operational teams do not require massive support organisations, which means they can spend more time building tools that support a self-service model for software deployment and develop better platform products, instead of doing operations for teams.”
Justin Dean, SVP Technical Operations, Ticketmaster
This is a key insight: reducing friction for development teams also frees operations teams to do higher-value work — building platforms and self-service tooling rather than manually fulfilling deployment requests.
Adapting Legacy Systems to DevOps Principles
Legacy systems like the Vax are typically managed by a small, specialised team of expert administrators. Placing a hand-off boundary between that team and DevOps squads reintroduces exactly the kind of friction the transformation is trying to eliminate.
Ticketmaster’s approach was to apply the same DevOps principles to legacy-focused teams: the team that writes software also carries operational responsibility for it. Where development teams lacked the expertise to manage legacy-dependent deployments autonomously, Ticketmaster embedded experienced application and systems engineers — previously in dedicated operations roles — directly into those development teams.
Importantly, the mission of those embedded engineers changed:
“We really changed their mission from an operations role to a site reliability engineer role or a DevOps engineer role, where their mission is to help the team take control and ownership of their own software.”
Justin Dean, SVP Technical Operations, Ticketmaster
Once a team reaches self-sufficiency — able to deploy and operate its software independently — the embedded operations engineer moves on to support another team. The model is designed to scale knowledge, not to create permanent dependencies.
Risks and Limitations of Embedding Operations Staff
Dean is candid about the limitations of this approach. It does not scale well if the organisation has only a small pool of engineers with the relevant legacy systems expertise. The embedded model is most appropriate where the business case for training a development team in operations can be clearly justified.
The primary risk is siloing: embedded operations engineers can end up permanently attached to one team, functioning as a dedicated ops resource rather than as an enabler of team autonomy. To prevent this, Dean advises reframing the embedded role explicitly around two objectives:
- Identify and eliminate friction points — understand where teams are blocked and why.
- Build self-service tooling and open up access — once the team is trained, give them the keys rather than continuing to operate on their behalf.
Key Takeaways for DevOps Engineers Working with Legacy IT
Ticketmaster’s experience surfaces several practical principles applicable to any organisation navigating legacy constraints:
- APIs are the modernisation layer. Before replacing legacy systems, wrap them with APIs to abstract their interfaces. This allows new services to consume legacy functionality without direct coupling to the underlying platform.
- Containerise to isolate complexity. Containers let teams own their deployment pipeline even when the software depends on complex underlying infrastructure.
- Measure outcomes, not output. Shifting the measure of IT value from volume of work to business impact encourages teams to prioritise and move more purposefully.
- Embed to enable, not to operate. Operations engineers embedded in development teams should build toward team autonomy, then move on. Their goal is to make themselves unnecessary to day-to-day operations.
- Self-service tooling is the long-term answer. Operations teams freed from manual deployment tasks can invest in platforms that give all development teams safe, controlled self-service access to infrastructure.
- Legacy and DevOps are not mutually exclusive. DevOps principles — shared ownership, fast feedback, autonomy, continuous delivery — apply equally to teams working on or around legacy systems.
The Vax emulator at Ticketmaster is an extreme example, but the underlying challenge is universal. Most enterprises carry forward systems that predate modern deployment practices. The question is not whether to tolerate that reality, but how to build DevOps practices around it without waiting for a complete rewrite that may never come.