DevOps for legacy services – it’ll never happen!

Publish date:

It is not possible to run your legacy services with DevOps teams, but with a bit of care you can mold your service to your team, or your team to the service.

It’s not possible to run a legacy IT estate with DevOps teams.

I would absolutely agree with this statement: throw a bunch of DevOps teams at your legacy services and you’re as asking for trouble, not least because your DevOps teams, while they know much about modern ways of working, are unlikely to know anything about these older, albeit core and vital business services. That’s if you even have such teams ready to deploy.

Hurrah for legacy

Firstly I think there has to be a mind-shift. These services are likely to be at the core of your business proving ongoing business value. Some services you might be able to switch off quietly without anyone noticing, but doing that to most of the services labelled “legacy” would likely cripple the business. So let’s reconsider that meaning of the label – it carries negative connotations that nothing can be done with these services. That’s just not true. A “legacy” is something that the business created before you arrived and then handed it to you (thanks, business). It is as much to be cherished and built upon as ripped apart and discarded. So let’s consider the former.

Life in the old dog

The operation of legacy services via DevOps can bring great benefits for the organization that chooses to invest. You can:

  • Breathe new life into older services – those monoliths can be changed in an incremental way, and using updated tooling. The culture shock of switching to a new service can debilitate an organization, so change the service little by little. Drop the bits that don’t work and build on those that do. And do it with updated tooling where possible.
  • Understand your services better – take advantage of improved real-time monitoring techniques and tooling; improve and update the integration with the rest of the estate – enable access for other services to all that valuable data
  • Control your requirements; improve backlog management – move to agile and more rapid incremental change and enable closer working with your customers (be they internal or external)
  • Shift left QA and use service driven design and development – improving the quality of the output and stability of the service. While your legacy service is likely to be stable, there can be a certain degree of nervousness about making radical change to such a service. Take control of the QA and assure your customers that a DevOps process can manage this risk.
  • Cost savings and efficiency savings, through:
  • Lower operational costs through fewer defects
  • Rapid deployment of resources between operational issues and new development
  • Rapid response to your customers changing requirement
  • Drive innovation – the whole team is exposed to service operations giving larger base for service innovation – and everyone gains exposure to modern tooling
  • Take a step to the cloud – change your teams to DevOps footing and then they, and your service, become more cloud ready.

OK then, given the prize…

I want it now!

As with life, so with DevOps; there is no single destination, you cannot simply force the change and then forget – it is a journey. Once we accept that we must invest time in making our DevOps dreams a reality, it will make it easier to plan our way forward towards our new goal. Plan incremental change within an overall strategy and roadmap. And remember that the journey doesn’t end – a central tenant of DevOps should be continuous improvement. Some suggestions to start might be:

  • Standardization – of process and ‘scripting’ were possible remove the variations that have crept into the service over the years
  • Standardization – of infrastructure, where possible
  • Monitoring: improve system knowledge – this can a relatively straightforward fix – e.g. pull this together via something like Splunk and visualize. The intelligence gained can be invaluable and it also fosters service ownership.

The journey towards DevOps is one you might already be on. For many years now, a number of industries have changed their way of thinking by operating Lean management, focusing on continuous, incremental improvements. An organization that has bought into the ideas that change as positive for business and customer outcomes change should come from those doing the work; and change is measured, are already a good step towards a DevOps culture. Secondly, embracing Agile ways of working is core in the transformation to managing work in a DevOps team; again changing the culture of an organization is key.

Circling the square

Legacy is almost synonymous with waterfall, and the move to an integrate an agile change process operating against a monolithic, aging service is a whole other topic. But without thought about how you can enable this, a move to DevOps can stall. It is possible – I have seen it done successfully in a number of teams that are prepared to think at the level of change that agile requires, or are prepared to think outside the box to change parts of the service that are outside of the service crown jewels, for example via microservices or recognizing what parts of the service can stand this level of change.

Please fasten your seat belts

This is not an easy journey. But on the way, we can try and avoid those pockets of trouble, or at least be aware where the turbulence lies.

  • Clash of old and new technologies – how to introduce new tooling requirements of DevOps while maintaining the level of service?
  • No one wants to change – how to use your champions, and enthuse the detractors? Who will support me?
  • The customer doesn’t want to work like this – how to bring the customer on your journey and to see the benefits to them of moving to DevOps?
  • There’s no time to do this – remember this is a journey not a single step implementation. How to break it into small steps?

DevOps, your way

The answers to each challenge will differ by team and organization depending on the make-up and experience of the team and the culture and commitment of the organization, and the attitude you bring.

It is not possible to run your legacy services with DevOps teams, but with a bit of care you can mold your service to your team, or your team to the service. Or most likely, some of both. The benefits for your people, and your services make it a prize worth chasing.

If you’d like to learn more about how Capgemini can assist with a DevOps journey for your legacy services contact me via LinkedIn.


Related Posts


Product-oriented delivery, enabled by POD models

Rishi Kulkarni
Date icon May 11, 2021

Why POD models are the future


DevOps implementation – lessons from the practitioner’s lens

Venky Chennapragada
Date icon November 10, 2020

Key takeaways from the field that you can apply to drive your DevOps transformation towards...


Innovation, revolution, and your future as a leader in Business and IT

Randy Potter
Date icon March 18, 2020

How the democratization of IT is disrupting the way Business and IT work together, and why...