Application modernisation
Let’s admit it. Every company has a skeleton in the closet – where one of the biggest skeletons is often a legacy system.
What is a legacy system? Wikipedia defines a legacy system as: an old method, technology, computer system, or application program, “of, relating to, or being a previous or outdated computer system,” yet still in use.
In other words, something old, based on technologies which are no longer mainstream, probably having a few compliance and security issues, difficult to extend and adapt, but still perhaps working well and doing what the business needs.
Why modernise applications?
Users might be used to them, everything somehow works, so why modernise?
A number of good reasons are:
- Compliance and security – processes and requirements are not meeting current demands (GDPR, HIPAA)
- Extensibility – complexity, outdated technology. and architecture makes any changes difficult.
- Cost – hosting these applications, and paying experts to maintain them is expensive. Very often the costs are hidden in different pots and so the TCO (Total cost of ownership) might be tricky to calculate precisely.
- Limiting growth of the business – instead of building applications to meet business needs, the business often needs to adapt its delivery outcomes to meet what legacy systems can achieve.
- Training new team members – who are expecting standard application behaviour, and instead must learn various tricks to operate an outdated legacy system.
- Scalability – to serve more customers to support business growth is often an issue, and can be expensive to achieve with legacy systems.
- Disaster recovery – The Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are two business critical objectives. If they are not defined, and recovery time could be days or even weeks, then it’s a disaster waiting to happen.
One example in the news recently was the spike in demand for Cobol developers during the coronavirus crisis, when those legacy systems were struggling with a sudden spike in users and requests.
However, for business these systems are big investments that contain critical data and processes, and therefore could be very expensive and risky to replace.
“Over the years Loft has helped many clients to choose the best strategy for upgrading, modernizing and maintaining their legacy systems.”
How to modernise?
The typical solution these days is to move systems to the cloud – to improve security, scalability and business continuity.
This shift to a cloud based solution leads to the need to choose the best migration strategy. This could be:
- Rehosting – Lift and shift approach of existing infrastructure and setup
- Replatform – Modify application and infrastructure to utilise cloud solution advantages
- Refactor – Replace application or its parts with new modern, scalable, secure solution
Migration could happen in a phased approach – Rehosting -> Replatform -> Refactor -> Containerise – which would minimise the risk of things going wrong and keep the costs under control.
The ultimate goal here is often to break monolithic systems into more independent subsystems, and utilise architecture such as microservices, cloud native applications, containerisation and DevOps best practice.
But even if a company uses a very specific solution, for example Mainframes (z/OS), it can utilise modern technology with infrastructure such as hybrid cloud to connect modern cloud native applications with legacy systems, achieving the best from both the old and new worlds.
However each system is unique and requires a good analysis and understanding before the correct strategy can be drafted.
We at Loft, have a huge amount of experience working with large multi-billion dollar global organisations, as well as smaller brands. We are working together with companies to replace and digitise their legacy systems, and integrate and migrate data, to create robust, future-ready digital platforms.
If you would finally like to get your “legacy system” skeleton out of the closet, find out how we can help, by contacting us here.