Application and Database Migration Strategies: Don’t Just Migrate Transform Your Apps and Databases to Portable, Cloud-Ready Status

By: Morpheus Data

Refactoring your apps and databases prior to migrating them to the cloud improves efficiency and portability.

The lift-and-shift approach to moving applications and databases to the cloud may seem most efficient in the short run, but the shortcomings of the technique become more obvious over time. By taking the time to refactor your apps – whether partially or completely – you can reap performance rewards while also ensuring that the systems are easier to port to other cloud services.

If you simply “lift and shift” your apps and databases from in-house servers to AWS and other cloud services, you’re missing a golden opportunity to make your data operations faster, more efficient, and more economical. The only way to take full advantage of the best features of cloud-based app and DB management services is to use containers and other technologies optimized for the cloud.

Here are three main options facing many organizations as they devise a cloud-migration plan for their in-house applications and databases: (HT to David Linthicum for the his original post. You can read his article here: 

  1. A direct port with no modification of the code (lift and shift)
  2. A partial refactoring that customizes the app to accommodate cloud features (few changes are made to the app itself)
  3. A complete refactoring that not only adds cloud customizations to the app but also reworks its basic functions

While the lift-and-shift migration approach is fastest and simplest, you lose out in two ways. 1: Your application or database can’t take advantage of elastic scalability and other cloud features. 2: The lifted-and-shifted system will cost more to manage in the long run. If your app uses a well-defined architecture, if its data is tightly coupled to the application logic, and if it runs well in the cloud, then lift and shift may let you avoid a costly and time-consuming refactoring process.

When you completely refactor the migrated app, you’ll realize much greater performance while also reducing the cost of managing the system. However, the migration itself is more expensive because you’re altering so much more of the application, and the process will also take longer to complete. If the app is business-critical but is poorly written to begin with, it’s easy to justify the time and expense of refactoring it from top to bottom.

In many instances, the optimal application migration strategy is the “sweet spot” between a straight lift and shift, and a complete code refactoring. Source: Cloud Technology Partners, Inc., via Slideshare

The middle ground of a partial refactoring may seem like the perfect compromise between a straight-ahead porting of the app and totally rewriting it, but this is really a halfway, stop-gap solution that simply postpones the ultimate development and deployment of the cloud-native version of the app.

Determining whether your app would benefit from being containerized

If you decide against the lift-and-shift approach to app migration, there’s another potential limiter you need to avoid: Locking your system to one service’s cloud-native features. In a July 24, 2015, InfoWorld article, Linthicum offers a solution to this predicament: containers. A prime example of such a cloud-native pickle is use of a specific service’s provisioning and deprovisioning resources rather than using the cloud itself to auto-scale and auto-provision your application.

By contrast, containers let you encapsulate your app’s components and place them in containers that keep them separate from the cloud platform itself. This allows the application to be ported quickly and simply to any other platform that supports the container. Containerization entails more work than a straight lift-and-shift port, but the rewards in terms of app performance and cost savings can more than justify the extra upfront cost.

One of the advantages of containers over virtualization is that containers share OSes, as well as bins/libraries when appropriate. Source: ZDNet

Continuing on Linthicum’s thought leadership, he states that a primary benefit of using containers to migrate apps and databases to the cloud is the ability to create a lightweight abstraction layer without relying on virtualization. This lets you increase efficiency when transporting workload bundles between cloud services in hybrid and multi-cloud environments. Another advantage of containers is that you can apply security and governance services around rather than inside the containers themselves. This improves both portability and deployment.

One of the most complicated calculations when planning a cloud migration is the cost comparison, particularly when you choose to go with multiple cloud providers. However, as TechTarget’s Joel Shore writes in a December 2015 article, by doing so you can realize savings from 58 percent for a “small” application to 74 percent for “large-scale solutions” over using a sole cloud service. A prime example of a cost-efficient hybrid/multi-cloud service is the Morpheus cloud application management platform.

Morpheus’s intuitive dashboard interface makes managing apps in hybrid cloud settings as simple as pointing and clicking. With Morpheus it takes only seconds to provision databases, apps, and app stack components on any server or cloud, whether on-premise, private, public, or hybrid. Because provisioning is done asynchronously, you can provision multiple IT systems simultaneously. When you’re ready to add nodes via the web UI, CLI, or through an API call, Morpheus automatically configures the database or app cluster to accommodate the new nodes. There’s no simpler way to ensure your organization’s important data is both accessible and portable. To start a free trial click here.