Skip to main content

Tips for migrating your app to the cloud

(Image credit: Image Credit: TZIDO SUN / Shutterstock)

In this age of falling cloud computing costs and hybrid cloud infrastructures, organisations are trying to find a path to migrate their apps to the cloud.

This article will explore some of the concepts and requirements needed to migrate an app from an on-premises data centre to another location, which is typically a cloud provider, but many of the concepts apply when moving to a DR site, or even a developer’s laptop.

So let’s use WordPress as an example. Here are the aspects of the app as detailed below.

Understand your app

Let’s be honest—apps can be complex. You’ll need to document all aspects, including:

  • Platform
  • Application state
  • Data format and storage
  • Networking
  • Security and governance
  • Platform

The first place to start is understanding your application platform. Does your app run on a dedicated bare metal server, on a VM, or in a Docker container?

What hypervisor are you using for virtualisation? Each of these presents a different “path” when moved. WordPress, in this example is made up of VMware-based VMs. This presents a bit of a challenge if you want to move them to a cloud provider due to hypervisor incompatibility.

Application state

Application state may represent a number of things: configuration settings, blog posts, financial data, etc. You need to transfer this data alongside your app, otherwise you will be starting from scratch.

Databases have different methods for moving data (e.g. replication, backup/restore), so you will need to choose the method that best fits you. For WordPress, we are using snapshot-based backups via CDM. This can be problematic if taken mid-write, as this can result in a non-functional database when restored.

Obtaining consistent backups for stateful apps may require an agent to be installed on the OS or the use of pre- and post-snapshot scripts. One way to address this is to use a pre-snapshot script to lock the database tables and a post-snapshot script to unlock them.

Data format and storage

Once you’ve gained an understanding of your app and state, it’s time to look at the app “mass”.

How much data will you have to move along with your app?

How much will it cost in terms of connectivity and storage fees to move and operate?

This will determine the effort and cost required to move your app. Another concept to consider is that of “data gravity.” As the amount of data increases, it attracts additional apps and services, therefore becoming more difficult to move. It may be possible to keep some apps in different locations even when they’re relying on the same data, but you will typically pay for this in network egress fees.


WordPress has a very straightforward networking setup.

Contrast this with legacy apps made up of hundreds of servers or apps without well-documented TCP/UDP port usage, and it’s obvious moving a large or poorly-documented app can get out of hand quickly. You must have a solid understanding of how your app communicates. If you have network appliances, such as load balancers, evaluate how tightly they are coupled with your app and if there is a replacement at the destination.

Security and compliance

Are there are any data governance laws or compliance regulations that apply to your app or its data? If so, this may place limitations on where you can run your app.

Do you have a well-defined security policy for your app?

Define all your security requirements, including authentication, authorisation, role-based access control, firewall rules, and encryption needs. If you have an existing policy, you will need to determine what needs modifying.

Your security and compliance teams will appreciate being a part of the project, and can provide valuable guidance. You don’t want to spend time planning a migration only to have it cancelled due to security concerns.

Understand the destination

It will always be easier to migrate an app to a destination that is using a similar technology stack. The major clouds offer the best pricing, connectivity, and add-on services, so it’s often worth the trouble.

Completely refactoring your app to a cloud-native architecture is an option for migrating your app, but it may not be feasible due to time or finances.

A major change for most is making the switch from VMs with statically-assigned IP addresses to dynamic addresses assigned by DHCP. You will need to use DNS entries to connect to VMs and services. Major cloud providers make this easy by generating DNS entries for your VMs, as well as managed DNS offerings that can be administered via API.

When migrating these VMs to AWS, adjust the configuration files to use the DNS entries created for each VM, and they should function exactly as expected.

Network planning and considerations

Networking configurations such as routing, firewall rules, network address translation (NAT), VPNs, and load balancing will require planning to ensure they meet your requirements. The implementation will look different than in a traditional environment. Cloud provider networks are completely software defined, so there’s no central firewall or load balancer.

This also means that there are limits on the amount of resources that can be consumed in terms of network prefix routes, public IP addresses, VPN tunnels, etc. Ensure you understand the limits imposed by your chosen provider, and what action to take to increase the limit. This is an important design consideration when operating at scale.

Easing the pain

This article has highlighted several key points to consider when migrating your apps, and there is no shortage of difficult problems to solve.

As long as you take an approach of understanding your app and the changes that will be required to move it, you will be set for success. Combine this with the power of automation and the resources available at Rubrik Build to craft a solution tailored for your exact needs.

Matt Elliot, Technical Marketing Engineer, Rubrik