Pulling the plug on legacy systems won’t solve your problems when it’s business-critical software that you’re dealing with. It could be that you’ve inherited the system during mergers or acquisitions, or it’s an in-house product or function that’s become onerous over time. Either way, it’s not uncommon for it to feel like legacy applications are trapping your business.
Applications built ‘pre-cloud’ generally run on-premises are difficult to maintain and come with expensive licensing costs. Over the last decade, the cloud mindset has forged new ways of working which ease these challenges, however, knowing where to start with replatforming an application–while keeping things up and running–opens up a can of works for IT and development teams. So how do you break free?
Take the first step
Over the past two years, there’s been a stark change in how digital transformation is viewed. In the 2017-2018 Logicalis Global CIO Survey, the view was the CIO roles were dominated by day to day IT management and they could only dream of spending more time on strategy. A year on, and the 2018-2019 Logicalis Survey shows that half of CIOs are now measured on their ability to deliver service innovation and 35% are expected to make a direct contribution to revenue growth that could easily be enabled by digital transformation.
Alongside this, 22% of the average CIO’s IT estate is now managed by third parties which in turn frees up their time for strategy and innovation. This innovation is focused (34%) on enabling small scale, everyday experimentation. Replatforming can be made possible, and far less daunting, in this way too.
Keep the core…
Replatforming allows you to optimise and move your business forward without necessarily having to change the core architecture of the application. By making minimal changes to the code to adapt it to the cloud, you can keep the codebase intact, restructure it into smaller, more manageable chunks, and retain all of the features or functions it provides.
Applications may or may not be able to become fully cloud-native, in which case–instead of suggesting a complete rebuild–there is the option to look at the minimum changes to get the application up and running on the cloud. In some cases, it can make sense to completely rebuild the application, although for many
…before jumping all in
Ensuring the factors needed for your legacy application to run on the cloud are covered may only provide a basic level of benefits, compared to being cloud-native. However, for some applications that’s all that’s needed.
If your application could gain from the full benefits, it’s possible to refactor code to move towards a fully cloud-native app, all while keeping the application live and in-use. This transforms your application, helping you overcome operational challenges while taking advantage of far faster software releases, automated infrastructure and effortless migration to the public cloud.
Grow together
Legacy monoliths can feel like they are set in stone, but replatforming can offer scalability without the cost and complication of updates on previous platforms. The demands of your growing business can be met with whilst also being futureproofed.
Cloud platforms scale up and down in seconds, and unlike the limitation of vertical scalability, it can be dynamic and automated. Platforms that scale vertically do so based on resource, adding additional RAM, CPU, disk and storage to a particular machine when needed. Horizontal scale is based on increasing the nodes within a cluster and reducing the responsibility of each one. Each node has a fixed capacity but the load is shared amongst the overall pool, making scale far easier.
Horizontal scaling eliminates downtime caused by human error, provides consistency across any size of deployment, and allows for the allocation of resources to be based on the ongoing needs of the application.
Containerisation also helps in this because by using neat, little standalone containers, you can take away some of the complexity that comes with working with big, legacy applications. If you have a problem with one container or part of an application, you can focus in on that container without taking the whole thing offline.
Freedom from risks, and their cost
Aging legacy systems could be posing efficiency, cybersecurity, and mission risk issues. There’s the operational and maintenance budgets to consider, but how much do these ‘issues’ cost you every year?
Hidden costs can be found in data breaches, failure to comply with your industry regulations, lost business due to lack of innovation, and the lack of agility and efficiency over time. Security alone can be improved with zero downtime patches, and rollback is quick and simple.
Reviewing your budgets from multiple angles will provide plenty of reason to modernise sooner rather than later; any outlay investment will be justifiably returned.
Life after migration
Keep life post-migration at the forefront of your thinking – what does ‘good’ look like? Business processes are likely to alter as a result, so knowing where you want to be at the start will help you manage the change in line with replatforming.
Be clear with everyone involved about what you are trying to accomplish through this modernisation, what processes and policies will be impacted and how they will change for the better, and how the change will happen, piece by piece. This is a manageable change that keeps your teams in the loop and is done for the benefit of stakeholders, employees and clients alike.
It’s also important to work alongside a partner who understands what your vision is, what your new world will look like, so that they can help you design the move to work for you and your business.
Guest Blog by James Leavers, Chief Technology Officer at Cloudhelix
The biggest lesson that we have learned here at Cloudhelix from replatforming clients: If replatforming was easy, your application would already have been migrated to public cloud. There is generally a difficulty that has prevented this from happening and often our client’s business just doesn’t have the time to dedicate to solving the problem.
Examples include:
- The application was written by a third party and access to the source code is not available. Or, in some cases, the original application vendor may have ceased trading. Detailed analysis and testing is required to deduce the inner workings of the application and add some tooling around it to ensure it runs in a container – for example, dynamically injecting configuration variables at runtime.
- The application may simply need a complete rewrite to work in a modern fashion – for example, rather than having a web interface it could be a simple Windows executable that users run from their local desktops. Here we might use a modern application remoting tool such as VMware Horizon as a stepping-stone, making the application securely available over the internet without fundamentally changing its workings.
