Migrating legacy systems and applications to the Cloud is hard. And for good reason: it changes everything! Government organisations are increasingly attempting to embrace the digital dream but end up tangled in a nightmare more often than not.
This dream can manifest itself in many ways, from the tools we use, the connectivity to enable access to these tools from more flexible locations, through to the countless bespoke applications developed and run by departments and hosted in managed data centres.
While the above areas are all interconnected, moving legacy applications to a modern Cloud environment is what often provides increased efficiency and massive cost savings – but it is also what often becomes the biggest stumbling block. The reality is that migrating to the Cloud is very difficult – not because the public sector does it badly, but because the odds are so stacked against us, and we are often led into it blindly and with unrealistic expectations.
What are the biggest obstacles to legacy migration?
To begin, we asked a few people close to major government migrations what they think the largest stumbling blocks are. Here are their answers:
“Knowing who has your applications and data and what the contractual obligations, exit clauses and other issues are, but also having capability to run what you migrate – whether in-house or outsourced.” – Himal Mandalia, Lead Architect, Department for Education
“Most organisations woefully underestimate the amount of effort required to migrate systems to the cloud, especially legacy systems. These are often unique operations, begun with a poor understanding of the scope of the work and limited appreciation of the amount of work required to realise the benefits of a modern infrastructure-as-code approach.” – Robin Sillem, Lead DevOps Engineer, Ministry of Justice
At Talent Consulting, we also believe many projects start without thinking ahead about major issues such as changes to the relationship with incumbent suppliers, potential issues with Agile working methods, migrating applications which were never designed for the Cloud and the time it actually takes to migrate a major system, as well as the potential need to rethink the approach to cybersecurity.
Why move to the Cloud?
The main reason for legacy applications to move to the Cloud is to un-encumber the development teams. Solutions hosted in physical data centres tend to have the following characteristics:
- Individual boxes are watered and fed on a daily basis; we know them by name
- Servers reside in a highly secured, trusted network
- Changes to any software, integrations or networking is a tightly controlled rigorous process managed by the hosting provider
- Change is infrequent but when it does occur it does so in large significant chunks
- The hosted solution is managed by a team whose primary job is to safeguard the service and ensure continued operation, that team is typically outsourced
- Integrating with any digital service outside of the trusted network is on a sliding scale of hard to impossible
Solutions hosted in the Cloud tend to have opposing characteristics:
- Instances (boxes) are thrown away and re-created continuously, when running serverless we never even deal with the OS level
- Instances reside in an open untrusted or low trust network
- Change (to software, networks etc) is frequent in small chunks, managed by the delivery team
- The role of the Cloud provider is to run a cloud platform not to manage your solution, they are not responsible if you mess up a release
- Integration with any other Cloud-based digital service is fast and easy
The big change here is the transfer of risk: running on the Cloud enables change but transfers the risk and responsibility to the delivery teams and away from the hosting provider. With this in in mind, organisations need to be sure that they are really committed to these changes. It’s not just a technical change – it’s a change of philosophy to how you develop and run software.
After several years delivering these changes, it’s time for us at Talent Consulting to share what we’ve learnt. Tune in to part two of this blog for more!
This article was originally written by Stephen Strudwick