<!-- show content if JS disabled --> <style> .delay-enter { opacity: 1 !important; } </style>
Roadmap Header

How to migrate your first application in 5 simple steps

Written by Peter-Mark Verwoerd

Every day, I speak with enterprise IT leaders who are excited and motivated to embrace new digital technologies. But when it comes to making that first move, they feel anxious, intimidated, even paralyzed. And I totally get it. Not only is change hard, but we’re constantly told that digital transformation is an all-or-nothing proposition. Just look at the headlines: “Your Business Has Two Options: Adapt or Die”; “Transform Now…or Struggle To Survive”; “The digital-transformation train has left the station — is your company on board?” Who wouldn’t feel overwhelmed?

My colleague Jen Bennett, a technical director for Google Cloud’s Office of the CTO, puts it this way: “Instead of chipping away at a project in an agile fashion, they think they need to solve everything at once. CIOs end up stuck in the status quo due to the perception that a project is too big and risky.’”


Here’s the thing: You don’t need to immediately launch a full-scale transformation to save your company from imminent doom. You don’t even need to move all your workloads and data to the cloud in one fell swoop. In fact, it’s often better to start with something small and manageable, like migrating a single — and simple — application. Take your time to do this correctly, and you’ll develop the skills and processes you need to make any future migrations much easier and faster.


Let’s take a look at the five basic steps of this sequential approach.

Define — and communicate — your goals

Before you do anything else, identify what you hope to accomplish by moving an application — whether it’s the only one or the first of many — to the cloud. If your objective is simply to adopt cloud technology, take a step back and consider how the migration will support your strategic imperatives and deliver short-term value.


Paul Strong, one of Jen’s teammates at Google, says that the cloud is a vehicle, not a destination. “It’s a means to an end,” he explains, “and that end should be a compelling and measurable business outcome that everyone at your company, from executives to developers, can get behind.”


The goal of your first migration should reflect your company’s business model, your team’s current financial picture, and so much more. But if you need a little inspiration, here are eight common business objectives for cloud initiatives, according to Forrester:

  • Improve customer experience

  • Deliver high-quality services to customers

  • Strengthen the business partnership

  • Ensure market agility

  • Reduce operational costs

  • Achieve process and management efficiency

  • Improve staff effectiveness

  • Become more proactive


Once you’ve defined your goal, connect with key stakeholders and brief them on what you hope to gain from migrating to the cloud. When IDG Enterprise asked IT decision makers about barriers to cloud adoption within their organizations, 44 percent cited employees’ lack of knowledge as a primary challenge. Thirty-one percent said they can’t fully embrace the cloud until they educate certain senior business executives on its value versus its risks.

Choose an application to migrate

Your organization may have hundreds of active workloads, from ERP systems and database services to mobile apps and ecommerce websites. How do you decide which should be the first to leave the familiar cocoon of your corporate data center?


I encourage businesses to start with something relatively simple and independent. This initial migration is all about your team’s learning experience, so your most difficult and challenging application is not the best candidate for your pilot run.


Since some workloads can only move if another one goes first, start by mapping out all the dependencies between your applications. Then separate them into three categories:


Easy to move

  • Few, if any, dependencies

  • Written internally so they have no licensing considerations

  • Running modern versions of Linux or Windows

  • Tolerant to horizontal scaling

Examples: internal web applications, dev/test/QA environments, batch processing systems, disaster recovery


Harder to move

  • Complex licensing requirements

  • Highly visible to customers

  • Critical to your business’s ability to function

Example: customer-facing websites


Not yet cloud-ready

  • Run on specialized or older hardware

  • Tied to corporate data center for compliance or regulatory reasons

Example: legacy applications that run on older hardware or operating systems


Once you’ve identified your top contenders, evaluate each one through the lens of your desired business outcome. Which potential migration has the greatest capacity to help you achieve the goal you’ve already set?


Along the same lines, Jen recommends taking another factor into account: visibility. “Choose a project that’s impactful enough to catch people’s attention and get them excited,” she suggests. “Not only will it be easier to get buy-in, but you’ll create momentum for the next phase.”


Next, price out the compute and storage capacity your application currently consumes using several cloud providers’ online calculators. Remember that the migration will free up space in your data center and potentially reduce your power, cooling, network, real estate, security, and operations costs, leading to additional savings.

Prepare your environment

Prepare your environment

Migration is like building a house. Before a single virtual machine gets moved, you need to put in the plumbing and lay the foundation. You do this by:

  1. Establishing governance
  2. Designing your network
  3. Defining your workflow

First, gain full control of your resources by determining how your organization will operate in the cloud. The goal here is to assign key responsibilities and permissions in advance, sparing yourself future risks and headaches. Ask yourself questions such as:

  • Do you want to centrally manage billing or create separate accounts for different divisions, teams, or applications?

  • How can you group projects and resources into a hierarchy that mirrors your organization’s structure?

  • What types of identity and access management (IAM) policies can help you enforce the principle of least privilege?

  • Who can access which resource, and for how long?

  • What actions can groups or individuals take, such as launching and deleting instances, managing firewalls and SSL certificates, or creating new policies?

Next, design a network that reflects your company’s overall needs, not just the limited scope of your first application. That way, you won’t have to repeat the process with every new phase of your migration. Depending on the options offered by your cloud provider, you’ll be able to make these types of decisions:

  • Will you have one network for each application or for each environment?

  • How will your applications access shared services?

  • How will you connect the various networks to one another?

  • Will you employ a hub-and-spoke model, a full network mesh, or something else?

  • Do you need to connect to existing resources within your data center?

  • Do you require the high availability and low latency of a leased line or direct peering?

  • Will you allow deployments anywhere, or only in regions closest to your customers?


Finally, it’s a great idea to streamline your developer workflow before moving your first application. If you haven’t already done so, consider adopting continuous integration and continuous delivery tools that automate configuration and deployment tasks. This will help simplify both ongoing work and any future migrations.


What if you don’t have the time and resources to build an automation pipeline right away? I get this question a lot, so I like to emphasize that it’s perfectly fine to migrate your first application now and refine your workflow at some point down the line. However, make sure to educate your developers and operations professionals about your plans, rationale, and goals for migrating to the cloud. Jamie Erbes, another Google Cloud technical director, explains why: “The human element can make or break this type of project. You need to have persistent communication to reinforce the value of this change.”

Migrate

Migrate your first application

Now that you’ve laid the foundation and installed the plumbing, it’s finally time to migrate to your new house. My advice is to work with what you have, changing as little as possible about your existing application. There’s a common misconception that you need to rewrite every line of code before moving to the cloud, but it’s just not necessary — or practical. Optimization can happen later.


So what does an actual migration look like? If your team already uses a continuous integration and continuous delivery pipeline to automate deployment, it might be as easy as redeploying the pilot application to your cloud of choice. (In other words, the more work you completed in the previous step, the faster you’ll fly through this one.) Otherwise, your process will likely resemble one of these typical scenarios:


Lift and shift: An application’s data and virtual machines are moved from a corporate data center to the cloud.


How it works:

  1. Replicate the entire application environment (web tier, app tier, database, static assets, etc.) in the cloud.
  2. Test the application to make sure it performs as expected in the cloud.
  3. Choose a downtime window and notify users about upcoming maintenance.
  4. Cut off traffic to the existing application and sync database changes.
  5. Switch DNS entries to send users to the new application.


Hybrid: Part of an application (typically the front end and possibly the application logic) moves to the cloud, while data and backend services remain in a corporate data center.

How it works:

  1. Connect your data center to the cloud using a VPN, a private or leased line, or another method.
  2. Replicate the elements of the application you want to migrate in the cloud.
  3. Test the link to your existing resources and the application’s performance in the cloud.
  4. Turn off the existing application and switch the DNS entries.
  5. Turn on the application in the cloud.


Dev and testDevelopers and testers can create, scale, and destroy complex environments on demand, increasing efficiency and reducing time to market.


How it works:

  1. Use templating and configuration tools to quickly spin up virtual machines for building applications and running quality assurance tests.
  2. To avoid paying for idle resources, automatically tear down these instances as soon as they’re no longer needed.


Backup and disaster recoveryThe cloud serves as a backup location for critical data and applications.


How it works:

  1. Define the maximum acceptable length of time that your application can be offline (RTO) and the maximum acceptable length of time during which data might be lost (RPO) due to a major incident.
  2. Back up your application and database to the cloud.
  3. Copy over to a redundant geographic area.
  4. Stand up and test your application in the cloud.
  5. Copy data deltas as frequently as your RPO requires.
  6. Configure automatic failover to meet your RTO.

Test, monitor, and optimize

You’ve successfully moved your first application to the cloud, but your work isn’t done yet. Remember that measurable goal you set at the beginning? It’s impossible to know whether you’ve accomplished it without rigorous testing and monitoring of your migrated application.


“It’s so important to close the loop by ensuring that you’re delivering business value and having all your stakeholders sign off on that value,” says Jen. “If everyone agrees that the outcome has been positive, it creates an incentive to start again and keep the project moving forward.”


Last but certainly not least, optimize your application, environment, and workflow to take full advantage of all the capabilities and efficiencies the cloud has to offer. This can happen right away or months down the road, either before you tackle your next application or after you migrate many more.


I could go on forever about the many ways to optimize for the cloud, so I’ll just leave you with a few tried-and-true strategies:

  • Adding redundancy across regions and availability zones

  • Using load balancing and autoscaling to increase availability and elasticity

  • Using a messaging service to decouple components of your application

  • Automating the deployment of resources

  • Adding disaster recovery


Along with better performance, greater stability, and less waste, optimization has another key benefit. The more you do it, the easier it will be to migrate the next application — or the next 100 applications — on your list.

These five steps are the bedrock of every cloud migration. Complete each one to move a pilot application, chosen for its relative simplicity and potential impact. Then lather, rinse, and repeat, using the lessons you learn to improve your process the next time around. When you break it down into these small and achievable pieces, the task of migrating to the cloud may seem a lot less scary. So here’s my message to you: Forget about the ominous headlines. Don’t feel pressured to transform everything at once or plot every detail before taking any action. Just start today with one application, and the rest will follow.


Peter-Mark Verwoerd

Written by Peter-Mark Verwoerd

Peter-Mark Verwoerd is the head of migration architecture for Google Cloud. He works with Google Cloud customers who are engaging in large-scale migrations to the cloud.