Moving to Cloud? Know Which of These Four Categories Your Applications Fall Under

While designing a new application may be the hot development path right now, enterprise organizations have a multitude of legacy applications that should not be ignored when undertaking a cloud initiative.

If you’re preparing to migrate some or all of your applications to a cloud environment, you’ll need to examine them and determine which of these four categories they fall under. With careful planning and perhaps some investment in development, your applications will work just as well in the cloud as they did on-premise.

Lift and Shift-able Apps

Ahh, the easy category. Applications that fit under Lift and Shift are more or less ready to migrate. They are either already virtualized or ready/compatible with hypervisor platforms. You can migrate applications that are cloud-ready by moving them over the network using native cloud tools like VMware Virtual Machine Importer.

You’ll still need to adjust and test these VMs of course, but most of the changes will be relatively simple, like changing the location of storage volumes or adjusting network settings. You shouldn’t need to adjust any business practices except maybe how your engineers/admins access the VMs. If you are using the same type of virtualization, you might not even need to change that management pane, either.

Legacy Enterprise Apps

These can turn into a real bear as you migrate more of your newer infrastructure into the cloud. Legacy enterprise applications may or may not play nice with your new cloud servers, and they may not be able to be rewritten or rearchitected for their own cloud deployment. Many of the larger enterprise vendors like Oracle and SAP have their own cloud offerings, or offer support to move your instance onto a cloud server, but you may also need to upgrade to a newer version and migrate legacy records. If you’re running custom enterprise applications, they could be twenty years old and very resistant to moving off a mainframe.

Rebuilt / Rewritten Applications

To go truly cloud-native, your applications should take advantage of cloud APIs and instead of being built to run on top of Windows or Linux, be designed with the cloud in mind. Cloud-native apps use microservices in order to run on whatever server is most efficient, even when spread across various service/availability areas. Container technology is one cornerstone of the cloud-native app.

Of course there are a few types of middle ground here as well. Many applications can be Lifted and Shifted to the cloud simply by running them inside a virtual machine that in turn is running Linux or Windows server, with little or no adjustments to their code. Other applications may be recoded to use cloud-native APIs to pull or push information between databases and other applications. They might need to be rewritten to use cloud-native datastores instead of traditional databases.

Of course, rewriting applications takes both time and money, meaning many enterprise organizations will look to Lift and Shift their existing applications until they are too expensive to maintain, migrating to a SaaS platform or a newly developed cloud-native app when the time comes.

Brand New Apps

If you’re a scrappy startup, a new app is more likely to be a realistic option than if you’re an established enterprise. For one, enterprises need more functional and powerful software that can be used for a variety of business processes. A smaller organization can do more with less, or may only need a very specialized tool. A cloud-native app may also be their singular product, while most enterprises are selling or dealing with a wide variety of products and services.

Once you know how your app might need to change when moving to the cloud, you can better evaluate if it is a good fit for a virtualized environment, or if you might want to migrate that business functionality to a new app better suited to cloud computing.

One way to arrive a conclusion is to tackle other categories, like the security requirements, core business functions and requirements, technical requirements, dynamic volumes, and CapEx or OpEx involved at all stages. From these criteria you can gain better insight into what kind of cloud you might need, or if an application needs to be replaced.