July 7, 2020
The cloud has transformed business. A great majority of organisations now use it to drive digital capabilities and the cloud migration market has been growing at around 30 per cent a year. The Covid-19 pandemic, which has caused major problems for the management of on-premises IT systems, is accelerating this trend.
However, for many organisations, cloud migration is still work in progress. And this is particularly true of large organisations with business-critical legacy systems. All too often there is inadequate documentation. And the specialist developers who originally implemented the code may well be long gone from the organisation. Migrating these robust and time-proved systems to a new environment can be a major risk to operational effectiveness.
In addition, simply migrating old applications to the cloud as they stand is likely to be ineffective and risks undermining advantages of cloud economics. There are many technical challenges to be faced when moving legacy applications to the cloud, such as refactoring applications to adopt modern capabilities such as APIs and microservices.
And yet the pressures to migrate to the cloud, including lower costs, security, and the need for operational flexibility, are still as strong as ever.
Organisations faced with the need to migrate legacy systems have three approaches that they can take: rehosting, rewriting or refactoring.
The quickest and easiest approach is to rehost all business operations in the cloud, simply taking applications and their associated data from local servers and placing them on cloud servers. This approach, often known as “lift and shift”, has its benefits. However, organisations cannot simply lift and shift all of their applications as this would be suboptimal use of cloud economics for complex applications. It would also mean that some of the cloud-native benefits such as continuous real-time deployment may not be possible.
This is because in a lift and shift context, the underlying code of the applications being migrated is not examined or altered in any way during rehosting. It runs as it did before, simply in a different environment. And in some cases, it runs sub-optimally.
An alternative approach is to rewrite business applications in a cloud environment, potentially re-architected in a cloud native architecture. And, if the developers have done their jobs well, the application will be perfectly adapted to new cloud environment. But, with potentially millions of lines of code involved, a rewriting project comes at considerable cost, and can take many months.
The third approach, and one that is increasingly popular, is to refactor the code of the applications. This involves restructuring the code so that it is optimised for the cloud. Often when refactoring the code, engineers rearchitect the application and try to adopt modern frameworks and concepts such as APIs and macro/micro-service architecture that, once deployed on cloud, significantly increase resilience and improve scalability, flexibility and elasticity. All of this means that, while it is more efficient than building code from the ground up, refactoring can still be a slow process with high implementation costs because it requires substantial human intervention.
One way to make refactoring more efficient is to automate it. For instance, code assessment, a process that must be undertaken at the start of any software migration, can be finished in hours when it is automated, rather than taking days and weeks as it would with a team of human developers.
Of course, automation can only go so far. Any code will need detailed configuration, and tweaks to address any environment dependencies such as checking and changing URLs. And once code has been refactored, the application will need to be tested and validated by a human. However, it is realistic to assume that three quarters of the refactoring work can be automated, representing a major saving of time and money.
One company pushing the boundaries of automated cloud refactoring is Hexaware. Its amaze® re-platforming service provides a number of key benefits over other migration methods. These include lower total cost of application ownership and lowered licensing costs. Other benefits are faster cloud migration at lower cost, and faster lifecycles for applications once they are in the cloud, such as real-time updates.
Hexaware claims it can deliver considerable benefits including a 50 per cent reduction in the total cost of transforming and refactoring an application, a 30 per cent increase in productivity and a 40 per cent reduction in time to market.
Successful refactoring is down to effective due diligence and analysis of the existing application architecture, complexity, dependencies, and integrations. The Amaze™ platform starts with this step. It conducts a thorough automated analysis of existing application architecture and creates a cloud-readiness report which identifies the changes required to make the application cloud ready: amaze® can pinpoint the exact line of code which needs to be changed.
Amaze®’s automation-based discovery tool plays a major part in mapping the existing technology stack and identifying any cloud-based requirements, thereby ensuring a comprehensive, rapid and lower-cost solution, when compared with a traditional approach.
Implementation comes next, with the code changes happening. Again, there is an opportunity to reduce costs and increase speed by automating code generation. In addition, standard practices such as adopting opensource software can be used to reduce the licensing costs. For instance, Postgres SQL can be used instead of an Oracle database, while WebLogic app servers can be migrated to cost -effective open-source options.
Refactoring also involves modernising the application. This involves breaking a monolithic application into smaller API-led macro/micro services, which amaze® does automatically. The newer architecture allows applications to expose capabilities over APIs, and scale independent services based on a containerised deployment. This helps the customer realise all the major benefits and flexibility that the cloud has to offer.
Testing the newly refactored application with production data also needs to happen before the newly “cloudified” application is deployed into the operational environment.
At the organisational level, it is likely that a pilot implementation would be run, with migration tested on one or two applications. Next, a fuller implementation involving perhaps a single business unit or function might be run; a limited number of applications would be migrated but at this stage key activities such as agreeing metrics and benchmarks, and agreeing guidelines and best practice, can be established. With these in place, the third stage can be to scale up the migration across the organisation. Running cloud migration this way may take a little longer, but risks are mitigated and a better outcome is likely as early lessons can be incorporated in the final architecture.
The cloud is here to stay, and pressures for migration are only increasing. Given these, it makes sense to use emerging technologies such as automation and machine learning to achieve successful migration of legacy applications at lower cost and higher speed.
This article was originally published on Forbes.com and The Business Reporter