A Guide to Migrating Applications to the Cloud

cloud migration
In this article:
    Add a header to begin generating the table of contents

    This week, Kaminario’s Derek Swanson writes about the different ways of migrating applications to the cloud, to establish the most effective option for your business. The full blog is available to read below, as well as a link to the original at the bottom.

    When you’re adopting a new public cloud infrastructure, you need to decide what is the best way to migrate your data. There are three ways you can do this: by refactoring your applications, lifting and shifting them onto a platform, or by containerizing the applications. In this post, we’ll break each of these options down so you can make the most informed choice for your business needs:

    Refactoring

    When we talk about “refactoring” your applications for the public cloud, it’s basically a modern way of saying that we need to rewrite these applications for the specific cloud environment you want to use. Vendors encourage you to refactor your apps to be cloud-native—to THEIR cloud. Doing so ensures that you are getting the maximum efficiency from the application — to run faster, be more cost-efficient, and be able to leverage all of the cool feature functionalities that the vendor offers. In fact, if you are moving one of your core applications to the public cloud, it’s highly recommended that you refactor.

    But a warning bell might have gone off when I explained that refactoring means rewriting the apps… and rightly so. Re-writing an application—especially while keeping all the rich features and high customer experience–can take years depending on how complex it is. On top of the time it takes, the cost, risk, and chance of failure (or disappointing marginal success) are extremely high. The success and failure of refactoring an application can make or break a career, given the time, resources, brainpower, and money that go into the process.

    On top of all this, refactoring for a particular cloud ensures that your applications are no longer cloud-agnostic. In order to shift data and applications from one public cloud to another, you will need to go through the time-consuming and risky refactoring process all over again. But with high risk comes high rewards. Companies that refactor their apps successfully to be truly cloud-native will be able to fully reap the benefits that brought them to the cloud in the first place.

    Get instant Veeam Cloud Connect pricing and start your migration to the cloud today >>

    Lift and Shift

    If you’re not looking to bet your career by refactoring your applications, you can lift and shift instead. Lifting and shifting requires that you copy your applications (installer and file system data) and reinstall it in the cloud, onto a platform (Windows or Linux typically). While this way of migrating applications to the cloud is significantly faster and presents far less risk and cost than refactoring, you also don’t get the cool feature functionalities, scalability, and performance that comes with natively leveraging the cloud. If you are migrating an app that you are planning to retire within the next few years, or you have an application that is going to be too costly, will take too long, or is too risky to refactor, then lift and shift is probably the best option for you.

    Modernization with Containers

    Imagine that you and your friends want to go deep-sea fishing one Saturday. You wouldn’t go out and buy a superyacht for a three-hour tour, would you? You’d rent a fishing boat for a few hours. The third option for moving data to the public cloud is the equivalent of this analogy: putting applications into containers. By leveraging containers, you can strategically use key components of a complex application in the cloud without running the entire operating environment. Containers encapsulate only the runtime code required by your application. You can self-execute these containers without maintaining the overhead of running the whole environment. Need additional features from the complete application? These can be reached through a shared common library. Moving applications to the cloud through containers is quick, simple, and doesn’t require that you fully refactor to a specific new API. If you’re looking to eventually refactor your app for the cloud, containers are a great stopgap to start getting key data, features, and functionalities on the cloud while the entire app is being rewritten.

    One Final Option….

    Refactoring, lift and shift, and containers are the three main options for moving applications to the cloud. But what if none of these options offer what you need? Perhaps you are planning to refactor in the future but need to move the application – the whole application – to the cloud today. Or maybe you want the ease of lift and shift but the full suite of feature functionalities and performance that come with being cloud-native.

    By decoupling data from the underlying infrastructure and providing a virtual control and data plane with uniform data services across any cloud, data can quickly and easily be migrated to any infrastructure of choice, and onto either a platform or to a cloud native solution: whether that be the public cloud, a private cloud, or a hybrid configuration. Plus, by placing the data on this virtual layer, you can turn off expensive cloud resources and reduce your monthly cloud spend.

    Looking to backup your Veeam-protected data offsite?

    Get instant Veeam Cloud Connect pricing using our online calculator. Replicate unlimited VMs with every solution.

    Posted in

    Rob Townsend

    Rob is a co-founder at Nexstor and has dedicated his career to helping a range of organisations from SME to Enterprise to get ahead of the game when it comes to their compute, storage and data needs.

    Subscribe to receive the latest content from Nexstor


      By clicking subscribe you accept our terms and conditions and privacy policy. We always treat you and your data with respect and we won't share it with anyone. You can always unsubscribe at the bottom of every email.