It is a huge endeavour when organisations wants to move their business to the Cloud. One of the many decisions you have to make upfront is the migration of your applications to the Cloud. Thinking about migrating your applications is always good even if your are NOT going to the Cloud. Applications support the business directly and has a major impact on the success of the business. Besides this, applications are the most determining factor in efficiency and standardisation of the underlying infrastructure and data center. So what reason you have for migrating your applications, it always a good start to think first about what to do with applications.
Before even talking about migrating your application, consider two major issues. The vendor lock-in and the maturity of PaaS and SaaS providers. These issues can kill lateron the reasons for going to the Cloud in the first place.
Here the possible scenario’s and each has its own advantages and disadvantages, costs and value to the organisation.
- Rehosting. Rehost is deploying application to a different hardware environment and this solution changes the application’s infrastructure configuration. The value to the company is medium to high and the applicable solution here to realise rehosting is relocating VM’s with VM-tools or make it possible by executing a P2V if possible.
- Refactor (or wrapping). Refactoring means that your applications applications like Web applications are running on the cloud provider infrastructure ranging from hardware up to programming languages. Mostly you must change the coding or configuration in order to get these application connected to the new infrastructure services. The value of this solution is medium to good and the costs are medium. The solution to do refactoring is to use third party tools.
- Replace. Replacing means to discard an existing application (or set of applications) and use commercial software delivered as a service to satisfy those business requirements. Maintenance of the whole stack – besides data – is responsibility of the Cloud Provider. Important is to remember is that you might lose functionality and flexibility. Typically, existing data requires migration to the SaaS environment. Application data import/export is achieved with an API or configuration/admin console. In this scenario the cost can vary! It depends of the economical life span of the application. You lose your technological knowledge and becomes more dependent to the vendor. Especially when core-business applications are put in the Cloud. And in the event you shift to another Cloud Provider and have no technical knowledge, this can be costly. The solution here is to execute a selection process in a very careful way.
- Rebuild. This technique uses a provider s’ application platform while discarding code for an existing application platform, while discarding code for an existing application. Rebuild requires re architecting the application for a new container. Re architecting means that the applications is build to run on virtualised platforms and with SOA and proper security in mind and can extremely benefit from the Cloud functionalities. Although the cost is very high, the value of this solution is also very high.
- Retire. The good news is that your get rid of the legacy applications that are very costly to maintain and to connect to your landscape of applications.
- Revise. Modifying or extending the existing codebase to support legacy modernisation, then use rehost or refactor options to move to the cloud. Revising can be costly and most of the time is the start of large change projects. Upfront costs are high. E.g. Redesigning a monolithic Java application decomposing the functions into smaller parallel chunks.
Here a reference to a case of a Dutch Telco about migrating more than 800 applications between two data centers and the steps the migration took to crack this case: Key decisions of a complex application migration.
Greetings Herman Rensink, Infrastructure – / Data center – / Cloud Architect