Trilogix Cloud

Moving Apps to the Cloud

Application Transformation Methodology

Every modernized datacenter or cloud will provide, at a minimum, the basic VM infrastructure, storage, and network services. When you transform mission- critical applications for use in the cloud, your applications can avail themselves of the unique benefits that the cloud offers. Purchasing or deploying a basic IaaS- focused cloud service is just an initial step in an overall enterprise IT transition to cloud. It is the application porting or redevelopment that will become the long-term path to complete the transition to cloud.



You must assess each application to determine whether a simple porting is possible or if the application will require a complete redesign to migrate to the cloud.



There are four types of application modernization strategies to migrate legacy applications in the cloud.

App modernization


Figure. Application modernization strategies


You first need to carry out a careful analysis of each legacy application to determine the best method to maximize long-term benefits, taking into account time, costs, and user impact. Some legacy applications are mission critical and unique to your business such that the long- term effort to redesign and recode them is worth the time and cost. Then, there will be relatively simple applications that you can quickly port (i.e., re-host or refactor) to a cloud platform, or even eliminate and replace with a SaaS offering from a cloud provider.



Re-hosting (or porting) of applications is essentially a “copy and reinstall” technique to take relatively simple legacy applications and host them in the cloud. These applications typically include one or more VMs and, possibly, a database that includes traditional applications which were not originally designed for the cloud. In a perfect scenario, a physical-to-virtual (P2V) migration is possible. Testing and minor configuration changes are often required, but the overall effort to port a single application is usually measured in only days or weeks. Although you might be able to re-host on the cloud quickly and without modifying the application architecture, many of the cloud characteristics (e.g., scalability, resiliency, and elasticity) might not be fully realized.



Refactoring an application is similar to re-hosting, but some components of the application are enhanced or changed. You might break up the application into components such as frontend web servers and backend databases so that you can cluster each tier and load balance to provide higher availability, elasticity, and handle more traffic and workload. In this scenario, the core application itself needs little or no reprogramming, because the cloud infrastructure and hypervisors provide some of the scalability without the application having any of the “awareness” that a cloud-native app would.



If there are legacy applications that you cannot re-host or refactor (because doing so would not produce the desired performance, quality, or ROI), you should consider redesigning. These applications are often the oldest and most complex legacy applications, possibly mainframe-based, that might require multi-layered platforms, databases, middleware, and frontend application servers to be deployed in the cloud. More complex legacy software might require significant assessment and planning just to come up with a project plan and budget to determine the feasibility, risk, and business decision to proceed with the reprogramming. The long-term benefits of a new, properly designed cloud-native application include dynamic elasticity, resiliency, distributed processing, high availability, faster performance, and lower long-term code maintenance.



Purchasing services from an existing SaaS cloud provider and retiring the legacy application is often a fast and effective cloud-transition strategy. If the ROI to transition a legacy application to the cloud is poor, the organization should consider if the application is truly mission critical or necessary, and whether you could use a custom-off-the-shelf [cots] or SaaS cloud provider, instead. Technically, you can consider an application hosted in a private cloud as SaaS, but most SaaS applications in the industry are hosted with public cloud providers. Excellent examples of this are public cloud email providers such as Microsoft Office 365 and GoogleApps, or CRM software. Sometimes these SaaS applications provide more features than your legacy software, but they also might not be as configurable as you are accustomed to because they are normally hosted on a shared public cloud infrastructure.


Below:  Lifecyle of developing Cloud apps

Continuous App Dev


Leave a Comment

Your email address will not be published. Required fields are marked *