Migrating two-tier web applications to Google Cloud

Stay organized with collections Save and categorize content based on your preferences.

This article introduces Google Cloud options to organizations who are conducting an internal assessment of moving a two-tier web application to the cloud.

Application types

Two-tier web applications consist of a web server running an application, and a database to store application data. Running Linux, Apache, MySQL, and PHP—commonly referred to as a LAMP stack, is a common example of a two-tier web application. Variations on the Linux distribution, web server software, database, or programming language affect the technical details of any migration, but the migration overview and steps are consistent.

Migration phases

Cloud migrations occur in the following four phases.


Identify all the characteristics of your workload, list the resources needed to run your workload in the cloud, and call out all the key dependencies and connections to other workloads. Using the complete list of characteristics, you can then start to plan what applications and workloads should move, and in what order.

In modern enterprises, there are many different kinds of applications, from customer-facing apps, to back office apps, to developer tools, to experimental applications. Moving all of these applications at the same time and the same way would be risky and inefficient.

One example would be to sort applications into the following three broad buckets:

  • Applications that are easy to move. These have fewer dependencies, are newer, are written internally so have no licensing considerations, and are more tolerant to scaling and supporting of cloud design patterns.
  • Applications that are difficult to move. These have more dependencies, are less tolerant to scaling, are difficult to run with cloud services, or have complex license requirements.
  • Applications that can’t be moved. Some applications that might not be good candidates to migrate run on specialized or older hardware, have business or regulatory requirements that make it necessary for them to stay in your data center, or have complex license requirements that don’t allow them to move to the cloud.

These are just some examples of ways to sort applications. It is likely that your applications have many more deciding factors that you can use to create a prioritization matrix of all applications. From that ranking, you can choose your first application to move, and begin planning your Google Cloud foundation.


Architect and plan specific details to deploy the new cloud environment. These include:

  • The cloud architecture and security model to provide an infrastructure foundation for your workloads.
  • Network resources to allow for secure and reliable communication between applications. This requires extensive planning for Identity and Access Management (IAM), Virtual Private Cloud (VPC) design, and external access methods.

  • The end-state technology and tools that your workloads will run on.

  • Accounting for dependency management, timelines, and methods of moving data.


Move the data and deploy services, infrastructure, and code to your destination. You should use automation and tooling to support these operations.


Validate whether the decisions and assumptions you made in the assessment and foundation phases match the reality after the migration phase. You identify any changes you might need. Consider how to explore other cloud-native options, such as moving from infrastructure as a service (IaaS) to platform as a service (PaaS), or taking advantage of managed service offerings. Depending on the outcome of the optimization phase, you might begin the cycle again to address changes or modifications. Always start back at the assessment phase and use your experience to become more efficient with each iteration.

Types of migrations

The three most common migration strategies for moving applications to the cloud are described in the following sections.

Lift and shift

Use lift and shift when you want to move applications while changing as little as possible in how they function. This works best for applications that can run unmodified within the cloud, when moving the application quickly is a priority, or when the business has little appetite or need for change. This migration requires more work from infrastructure and operations personnel to support the foundational changes in where the service will run, and less work from developers since very little, if any, code should need to be changed.

For example, if both tiers of your web application are hosted on VMs, you can migrate them as-is by using Migrate to Virtual Machines. When those VMs are on the cloud, you can then consider upgrading to a more cloud native compute platform for additional benefits.

Improve and move

Use improve and move when you want to modernize your application in the process of migrating it to the cloud. This is commonly used when the application isn't supported in the cloud as-is, or when major updates in software or hardware are already scoped and planned. This migration requires infrastructure, operations, and developers to work together to improve the function of the application in the cloud, and allows the application to take advantage of cloud-native benefits like more portability, scalability, and reliability.

Another variation of this strategy is to improve and move in one motion. If both tiers of your web application are hosted on VMs, you can use Migrate to Containers to automatically move and convert those VMs into containers running on Google Kubernetes Engine (GKE).

Rip and replace

Use rip and replace when you want to build a new solution in the cloud, and sunset the current version of your on-premises solution. This is commonly used when the following conditions apply:

  • The existing application isn't worth maintaining in the cloud, technically or financially.
  • Licensing the software in the cloud is prohibitive or impractical.
  • The application stops meeting the business needs altogether.

Because rip and replace requires rewriting an application from the ground up, it isn't covered in this migration guide.

Assessment phase

Before any migration can begin, you must have a thorough understanding of your starting point.

Any unanswered questions pose a risk to the success of the migration. Spending time in the assessment phase helps to ensure a smooth and uneventful migration phase. Spend as much time as you can to capture as much relevant information as possible in support of your migration.

Application software stack

Work with your infrastructure, operations, and development teams to identify the following details:

  • Operating system: Exact distribution, version, patches, packages installed.
  • Web server: Exact software package, version number, packages or other software modification, and all configuration files and rules for web server software.
  • Database: Exact software name, version, schema, replication strategy, and backup schedule.
  • Runtime environments: Exact versions, of all backend and frontend environments.

System hardware resources

For the web server and database tiers, answer the following questions:

  • How many servers are running now?
  • What is the total allocation of CPUs, including generation, architecture type, and speed?
  • What are the RAM and disk space allocated to each server? Are HDDs or SSDs in use? RAID?
  • What is the current utilization, average utilization, and the peak utilization of CPU, RAM and disk space? Look at your average and peak in the context of your specific business use. For example, a company supporting the Olympics might need to look back two years to see what true peak looks like, while other applications might have a more steady run rate. Look at the most typical use case timeline for average, and your heaviest use timeline for peak. Also look for cyclical use patterns, such as weekends, evenings, and workdays.
  • For the database, what backup, replication, or sharding strategy is in use, and how does that impact disk space requirements and the number of required servers?

Network resources

Analyze the network architecture that allows your application to function. Ensure that you have accurate and up-to-date logical and physical network topology diagrams of the infrastructure that supports your application. The diagrams must clearly outline all connections, dependencies, and network services.

Answer the following questions:

  • How do customers access your application? Through a web browser? Directly through an IP address? Through a mobile app? Using a virtual private network connection?
  • Do you have a list of all applicable SSL/TLS certificates and encryption keys?
  • Where are all applicable SSL/TLS certificates hosted? When do they expire? How do you renew certificates? How do you obtain new certificates? Do you have access to all current certificates?
  • Do you have a list of all applicable domains that support the application?
  • Where are these domains hosted? When do they expire? How do you renew them? Do you have access to the accounts that control the registration?
  • Where is your DNS hosted and controlled?
  • Do you have access to all of the systems and tools that control DNS? What are the current CNAME to IP mappings for each domain, and do you have a backup?
  • What are your DNS time-to-live (TTL) settings?
  • Where do your firewalls and other network access and control devices fit into the architecture? What rules are now in place to allow or deny traffic? Who is responsible, and what is the procedure for changing or updating those rules?
  • Do you use any external network services? For example, a content delivery network (CDN) provider, or a distributed denial of service (DDoS) protection service?

Foundation phase

Google Cloud offers many options for running compute and database workloads for multi-tier applications like LAMP. This section introduces those options and explains why you might choose one over another.

Compute-centric options

Compute Engine

Compute Engine is an IaaS offering that allows you to run a virtual machine (VM) on Google Cloud. You can install web frameworks, server software, databases, and any other software that your operating system supports. If you are running your own LAMP application on bare metal, on a VM, in a data center, or on another cloud provider, this option could closely, if not exactly, replicate your existing server. This option offers the greatest control over the operating system configuration and web server software settings. Compute Engine allows for deep control over machine types, instance groups, storage options, load balancers, and numerous other details. Refer to the complete Compute Engine documentation for more Quickstarts, Tutorials, and more.

Moving your application directly to Compute Engine is the most common lift-and-shift migration. For guidance on mapping on-premises resources to Compute Engine, see Best practices for migrating virtual machines to Compute Engine.

Cloud Deployment Manager

The Google Cloud Marketplace also offers a simple LAMP installation through Deployment Manager. You can launch a server with Debian Linux, Apache, MySQL, PHP, and phpMyAdmin already installed and configured in a default setup. You get a fully functioning web server and credentials for the MySQL installation in just a few minutes.

Google Kubernetes Engine

GKE is a managed, production-ready environment for deploying containerized applications. Using GKE you stop managing an operating system by containerizing your web server software. For example, the Apache and NGINX web servers are available from every public container repository. If you use containers to run workloads in your environment, GKE is an efficient service to maintain a similar deployment and testing workflow as you migrate your LAMP workload to Google Cloud. If you don't use containers, consider exploring GKE for faster deployments and recovery, greater efficiency in using resources, and not having to manage the underlying operating system and VM.

For more about container application management at scale, refer to the GKE documentation for quickstarts, tutorials, concepts, how-to guides, and other resources to help you get started.

Moving your on-premises LAMP application to GKE is an improve-and-move migration, while moving from a self-managed container-based infrastructure is a lif-and-shift migration.

App Engine

App Engine is a serverless platform for building highly scalable applications. Depending on the type of application you are running, App Engine can eliminate the need to manage servers, containers, or deployments, allowing your developers to focus on writing code and lowering the complexity of managing any underlying infrastructure. Not all workloads are good candidates for moving to App Engine, but those that are see cost and complexity reductions while increasing the speed of scaling and the resiliency of the application under load.

App Engine comes in two flavors: standard environment covers a variety of languages (including PHP for our LAMP application), and flexible environment allows for more customization of runtimes, performance, and infrastructure. Explore the documentation for your language of choice to learn more.

Database options

Self-managed on Compute Engine

You can install MySQL, PostgreSQL, or any other SQL-based database on a Compute Engine instance. This provides the same level of control you would have when running MySQL on a workstation, on a server in a data center, or as a VM in another cloud provider. When you run your database on a VM, it is your responsibility to configure, monitor, and maintain failover, replication, partitioning, and high availability.

You can treat the database as a compute workload, considering CPU, RAM, and disk space to ensure there are enough resources for the application to run reliably.

Like moving the compute workload to Compute Engine, this approach represents a lift-and-shift migration.

Cloud SQL

Cloud SQL is a fully managed database service that offloads the installation, setup, and maintenance of your database to Google Cloud. It automates backups, replication, patches, and updates, and lets you focus on your application. Cloud SQL databases can be used by workloads running on any of Google's compute services, including Compute Engine, GKE, and App Engine. Unless you need a deep level of control over your MySQL database, Cloud SQL is an easy-to-set-up and fully featured option for running a LAMP workload.

Cloud SQL can natively run and support MySQL and PostgreSQL. If you are migrating from one of those databases to Cloud SQL, this is a lift-and-shift migration. If you are exploring new methods for replication, backup strategy, or simplicity in managing your infrastructure, this might be an improve-and-move migration.

Other storage options

Cloud Storage is a scalable, fully managed, highly reliable, and cost-efficient object or blob store, ideal for storing images, static assets and other unstructured data. Cloud Storage can be used to host a static website but isn't designed to store active database content. It is also an ideal location to store backup and disaster recovery objects, and data to use for streaming.

Consider using Cloud Storage as a location to store backups of your database during and after your migration.


Firestore is a fully managed, serverless, cloud-native NoSQL document database that simplifies storing, syncing, and querying data for your mobile, web, and Internet of Things (IoT) applications at global scale. Its client libraries provide live synchronization and offline support, while its security features and integrations with Firebase and Google Cloud accelerate building truly serverless apps. If your application has content that could benefit from a NoSQL format, such as user profiles, product catalogs, or game state, you should explore Firestore in the optimization phase of your migration.


Firebase is a comprehensive mobile development platform that includes storage and database options. If your application supports a mobile workload, the Firebase platform should be considered in your optimization phase.

Cloud Spanner

Spanner is an enterprise-grade, globally-distributed, and strongly consistent database service built for the cloud. It combines the benefits of relational database structures with the horizontal scalability of non-relational databases. If your application could benefit from enhanced manageability, scalability, and transactions with strong consistency, consider migrating your database to Spanner in your optimization phase.

Google Cloud offers many other storage options to support a variety of workloads.

Migration phase

After you've completed your assessment and planned your migration, you can begin the work of moving data, services, and resources to Google Cloud. Each application has its own needs. This section walks through a few examples to help demonstrate what this phase involves.

Lift and shift: Compute Engine

The first step to beginning your lift-and-shift migration to is establish a compatible multi-tier service in Compute Engine. While there are many approaches to this; the following are the three most common:

  • Manual setup. Launch a VM with the operating system you want, then manually update repositories, install and configure the software, and provision and configure the database and runtime environment by hand. This approach offers a high level of control, but takes more time, is more error prone, and is less reproducible than other methods.
  • Automated. Use Migrate to VMs to migrate a stack of VMs (in a specified order) from on-premises into right-sized, automatically provisioned, and configured VMs in Compute Engine.
  • Cloud Marketplace. Launch a pre-configured LAMP stack in your Google Cloud project. Be sure to check that the provided operating system and software versions will work with your application. Explore the Cloud Marketplace documentation to learn more.
  • Automated deployment. Create production-ready VMs using continuous integration / continuous deployment concepts and a variety of configuration management tools (Chef, Puppet, Ansible, Salt), infrastructure as code tools (Deployment Manager, Terraform), and automation frameworks (Cloud Build). Automated deployment allows testable, repeatable, and automated methods to deploy VMs and software that meet your application and governance needs.

Improve and move: GKE and Cloud SQL

To move to a managed container solution, you must first establish the foundation for your cluster and managed SQL solution.

Launching a GKE cluster

Creating a cluster on GKE and managing that cluster are the first steps. Use the information from your assessment and foundation phases to size and configure your initial cluster appropriately and to apply security hardening best practices.

Launch options for Cloud SQL

Using the database information gained in your assessment and foundation phases, create a new Cloud SQL instance, and follow other how-to guides to build the database for your application. Google provides a list of Cloud SQL best practices, guides for setting up high availability, and other tutorials for horizontal scaling. Explore the options for connecting from Google Kubernetes Engine to Cloud SQL and choose the option that makes sense for your application and experience level.

Serverless improve and move: App Engine and Cloud SQL

If you decide to migrate your LAMP application to a serverless framework, you might need to modify your application to support App Engine. Every application is different, and there are many strategies. Start by reviewing the following:

Depending on your organizational and personal experience and familiarity with running serverless code, the serverless improve and move strategy could take significantly more time than the lift-and-shift options. However, bringing the best of serverless to you could be a huge asset to your organization.

Optimization phase

Ater your application is running on Google Cloud, you can validate your assumptions and decisions from the previous three phases. Full migrations can take a long time and many details can change throughout the process. Optimization covers many areas, but here are a few common categories.

Cost optimization

Moving from on-premises to the cloud changes the way you spend money on applications, services, and infrastructure. You might complete an assessment of a legacy on-premises service and discover after migration that modern hardware, faster memory, and newer CPU architectures run it more efficiently. This might mean that your VMs are over-provisioned and wasting money.

You might investigate using preemptible VM instances on Compute Engine. Perhaps you didn't need as many load balancers as you thought, or you managed to clean up your database in the move and now have space you aren't using. Finding ways to save money and lower operational cost in the cloud can become a full-time job that pays for itself. Google Cloud has a number of cost management tools that can assist you in understanding cloud pricing.


Correctly automating your compute workloads in the cloud can lead to cost savings and efficiency benefits. Deployment Manager is a Google Cloud product designed to help you create and manage cloud resources using simple templates. Scripting with gcloud is an option if you prefer writing your own automations. While financial benefits come with automation, other advantages include the following:

  • Standard and repeatable processes to lower error rates.
  • Auditable tracking for compliance and governance.
  • Increased understanding of how your application works, how it breaks, and how to fix it.

Automation increases uptime by lowering the reliance on alerting and human reaction time, lowers technical debt by documenting workflow, and lets your engineers focus less on keeping-the-lights-on and more on building better products, tools, and services. These concepts are at the core of Site Reliability Engineering (SRE). Google Cloud offers a free-to-read-online book on Site Reliability Engineering, as well as an SRE Workbook providing practical examples and case studies.

Decoupling your infrastructure and code

You decouple services many times as an application grows. Breaking apart connected services, and knowing how to scale them independently, improves the availability and reliability of your applications. There are generally three steps to this process:

  • Implement infrastructure as code (IaC) everywhere. By implementing IaC and configuration management processes, you gain traceable, auditable, and reproducible building blocks for the provisioning and configuration of your whole infrastructure.
  • Decouple your existing services into microservices. Use message-oriented middleware, like Pub/Sub, to allow every microservice to be its own failure domain.
  • Begin migrating services from infrastructure as a service to platform as a service, or even functions as a service or serverless as a service. The journey from "monolithic code and infrastructure" to "decoupled microservices running efficiently across the IaaS spectrum" is a valuable goal that will take time, effort, and dedication.

Performance tuning

Performance tuning can yield significant gains in system utilization and response time. Every workload has a different method for performance tuning, from software configuration files down to tuning kernel flags. For LAMP applications, performance tuning usually falls within three categories:

What's next