![](https://cdn.mos.cms.futurecdn.net/8KyQTpRGfAJ86XhCPZLMVb-1200-80.jpg)
As organizations evolve, they need platforms and services that are resilient while being responsive to change. The simple reality is that most also have a huge legacy of data and applications running on old platforms. So, what should organizations do about their legacy estate on their journey to cloud?
Although many organizations are adopting digital by default and cloud first strategies, it makes little sense to move the entirety of a legacy estate to the cloud. Firstly, not all applications are cloud-capable or cloud-ready. Secondly, simply moving current applications to the cloud can result in transferring and perpetuating old problems as well as creating new ones.
Cloud is not right for everything; taking cloud-first too literally can result in avoidable issues including increased operating costs, delays to digital transformation and under-investment in critical business functions served by legacy. The many benefits of cloud should always be assessed on a case-by-case or needs basis.
About the author
David Waite is a member of the Technology Leadership Team at Atos
Locked-in value of legacy
The primary challenges around supporting and making safe and predictable changes to legacy systems are the cost and time resulting from manual build, deployment, test and integration methods. This latency also affects cybersecurity posture given the increased time taken to patch, upgrade and test.
In this context, it can be easy to fall into a mindset that legacy has no value when in reality, many legacy systems have considerable locked-in value in terms of the data held, the functionality provided and the deep knowledge that surrounds them.
The question is therefore how best to manage and unlock this value so that it can be readily and rapidly exploited to support a wider digital transformation agenda, which often requires a shift in focus away from the application centricity of legacy towards a data-driven enterprise.
Nuanced approach
If the embedded value of legacy is not to be lost, dealing with legacy requires a balanced approach. Not all workloads can or need to be moved to the cloud, nor do they necessarily need to be moved in short shrift; legacy may be more easily and rapidly exploited in-situ and processes optimised through targeted intervention, thereby avoiding or delaying the need to move.
Fully understanding the role that legacy should play in digital transformation is key to success. If gaps in knowledge exist, then these should be closed through a programme of targeted discovery framed against a pre-defined digital vision and strategy. To avoid missed opportunity, the historical questions ‘what do we have?’; ‘do we still need it?’; ‘how long do we need it for?’ need to be supplemented with ‘does it make sense to re-use/exploit it?’; ‘can we improve it?’; ‘what role does it play in transformation?’ and most importantly, a focus on the fastest way of delivering benefit as efficiently as possible.
On the principle that proactive legacy interventions typically fall into the four categories below, we can start to define the role of legacy in terms of actions that will be needed on the overall journey.
Protective: Address a specific maintenance-related concern
Exploitative: Release locked-in value for a specific purpose
Evolutionary: Effect incremental change from within with multiple transformation steps
Transformative: Effect a wholesale change in a single step
Exploitative techniques such as data scraping to provide data-centric platforms; construction of Application Programming Interfaces (APIs) and microservices to open up legacy systems; and application virtualisation and containerisation can all provide useful alternatives to rip and replace type approaches both in the short and long term. Similarly, evolutionary techniques such as Domain Driven Refactoring can both help de-risk transformation and support benefits-related prioritisations. Where Redevelop or Retire is the preferred approach, protective measures for legacy as the System of Record may still need to be applied in the interim or during the transition.
Realistic targets
Cloud is a technology enabler, not a cure-all, and its advent has further confused the picture by adding new technology paradigms into the mix. Whilst it represents an important component of the overall cost base, it is far outweighed by the cost of people and processes. Redesigning fully automated processes around capabilities from the bottom up and underpinning these with cloud and other enabling technologies such as edge and IoT is where efficiencies are truly realised. Migrating legacy to cloud is not a precursor to this, nor should it be, but the value in legacy and its exploitation is an input and often an accelerator along the way.
Making sustainable and proportionate decisions about legacy systems and data is not straightforward and setting the wrong targets can be detrimental to outcome. Nevertheless the ultimate transformation goals remain the same – targeting and measuring outcomes and progress based on business efficiency (cost, throughput of change, quality, availability) aligned to growth and innovation are the key to providing the freedom to make informed and balanced decisions on roadmaps and priorities. The evolution and exploitation of legacy and its associated data is fundamental to achieve these goals given that cost and timeline constraints will always restrict any wholesale transformation.
Legacy treatments
When considering legacy in the context of cloud, treatments traditionally fall into six main categories:
Retire
Decommission applications that are obsolete, redundant or will become so as a result of a planned replacement or policy/process change.
Retain
Leave the application as is, either as a result of other priorities, dependencies, levels of investment, or compatibility.
Migrate (rehost)
Entry-level move to cloud IaaS (Infrastructure as a Service) with minimal change or ‘Lift and Shift’.
Modernize (refactor/rearchitect/replatform/encapsulate)
Mid-range move to cloud addressing some application component level concerns such as exploiting cloud PaaS (Platform as a Service) in addition to the underlying IaaS migration activity above.
Redevelop (replace/rearchitect/refactor)
Re-instantiate on cloud using cloud-native technologies.