Since the arrival of AWS, Azure and Google Cloud in the mid-2000s, over 90% of businesses have adopted cloud computing for some or all of their computer services.1 A Deloitte survey of fifty CIOs found that 68% cite migrating to public clouds as their biggest IT spending driver.2
As more businesses and organisations plan to migrate fully to the cloud, it’s worth getting a refresher on the ins-and-outs of what that involves. To help out, we’ve put together this explainer guide on everything you need to know to complete the best Google Cloud migration possible.
Why Google Cloud?
While AWS, Azure and Google Cloud share the majority of the public cloud market, Google Cloud’s primary advantages over Azure and AWS are its flexibility for SMBs and SMEs, price model and seamless integration with other Google services.
Google Cloud is optimised for companies with cloud-native operations and workloads. For example, Google Cloud AutoML assists in developing high-quality machine learning models, without the need for extensive expertise from the user.3 The platform also offers features that enable workflows, like Google Workspace and Google Meet to streamline communication and collaboration.
Some other benefits for Google Cloud are:
- Leading global infrastructure: Google has invested heavily in its network infrastructure, which now outguns Azure and contends with AWS. Google Cloud covers 27 regions and 82 zones in 200+ countries with 99.9% uptime.
- Seamless access to Google Services: Google Cloud benefits from seamless integration with Google Workspaces, a suite of class-leading tools for productivity and collaboration. Many businesses already use these tools — Google Cloud extends their functionality and increases their potential.
- Taking advantage of BigQuery: BigQuery’s performance for complex Big Data analytics is becoming hard to match, whereas BigQuery ML enables users to execute machine learning models using SQL queries. Google is leading innovation in cloud-based AI and machine learning.4
Before you take any practical steps to migrate infrastructure and architecture to Google Cloud, it’s vital to prepare correctly.
Preparing the migration
Whether you’re migrating from traditional on-premises database architecture, private cloud, or public cloud, the migration process heavily depends on your current infrastructure. While some cloud migration processes are quick and can take weeks or months, enterprise-level infrastructure with complex legacy systems can take years to fully migrate.
How your migration takes place depends on your current IT environment. The hosting environment, workload, and operations will dictate the plan and process.
There are three core types of hosting environments (though these can be mixed):
- Private hosting
- Public cloud
And two workload and operation types:
- Legacy workload and operations, which may involve on-premise POS systems, CRMs, customer databases, etc.
- Cloud-native workloads and processes.
So your migration is likely to involve one of these three starting points:
- An on-premise or private hosting environment combined with legacy workloads and operations. This is typical of organisations that built their entire IT systems pre-cloud.
- An on-premise or private hosting environment combined with cloud-native workloads and operations. This is typical of organisations that use on-premises or private hosting combined with primarily cloud-based workload infrastructure.
- A public cloud or private hosting environment combined with legacy workloads and operations. This is typical of organisations that host traditional legacy workloads on the cloud.
Want further information about the benefits of a well-designed tech eco-system?
The three types of cloud migration
Cloud migration often occurs as part of a broader IT modernisation strategy. There are three broad types of cloud migration:
- Lift and shift (AKA rehosting): Moving workloads and operations from the source to the target environment (Google Cloud).
- Improve and move (AKA re-platforming): Move workloads and operations whilst updating to take advantage of cloud-native capabilities.
- Remove and replace (AKA refactoring): Where you decommission an existing app or data and redesign and rewrite it for the cloud.
Let’s take a closer look at what each method involves.
Method 1. Lift and shift
Lift and shift involves moving existing applications and operations from the source to Google Cloud with little to no refactoring or modifications. Not all workloads can operate as-is in the cloud, but even specialised hardware systems can be moved to cloud-based virtual machines.
Benefits and limitations of ‘lift and shift’
Lift and shift is a quick, non-invasive approach that suits organisations with low-impact workloads and operations. Since this method allows for applications to be moved without having to restructure them, it enables you to move your off-the-shelf applications in a way that’s cost-efficient and less risky than others.
The downside of lift and shift is that your end result workloads are non-cloud-native and can suffer from inefficiency and security issues. Lift and shift is also harder to do if you’re dealing with customised applications.
Method 2. Improve and move
Unlike lift and shift, which aims to leave applications and workloads as unchanged as possible during migration, improve and move seeks to upgrade applications along the way. Instead of lifting existing systems to the cloud, improving and moving involves reworking applications to ensure they take full advantage of cloud capabilities and the latest versions of software.
Benefits and limitations of ‘improve and move’
The main benefit to this method is the efficiency it brings to your applications and migration processes in turn. For example, a relational database that uses SQL would be redesigned to utilise BigQuery if it was migrated to Google Cloud with the improve and move approach.
On the other hand, if further refactoring of an application is required, then it would have to be measured against the app’s lifecycle and potentially lead to a depletion of resources. If the app is likely to become redundant in a few years, then the effort of refactoring might not be worth it compared to replacing the app. Since specific applications will change (as in the SQL > BigQuery example), IT teams will also need to change and update their skills on a constant basis, which may not be feasible for many businesses.
Method 3. Remove and replace
Not all legacy operations and workloads are suitable for the ‘lift and shift’ or ‘improve and move’ approaches, especially if they are already failing to meet your organisation’s modernisation goals. In this situation, ripping out the application and replacing it with full cloud-native compatibility is the more futureproof option.
Remove and replace is the most comprehensive, but time-consuming, of the three options. This involves decommissioning and removing source apps, before redesigning and refactoring them for the cloud. Consider replacing old apps with their cloud-native counterparts if this isn’t possible.
Benefits and limitations of ‘remove and replace’
The remove and replace method ensures that your end infrastructure and architecture takes full advantage of Google Cloud. This intensive refactoring is ultimately the most comprehensive approach to preparing applications and systems for the cloud, as opposed to simpler methods such as rehosting or re-platforming.
This involves taking further technical steps, like replacing off-the-shelf applications in your stacks altogether, as they would otherwise be unable to be refactored due to inaccessible source codes.
For organisations that use many interdependent applications, refactoring is an expensive and complicated process that can take years to complete. Most remove and replace migrations are staged and involve rehosting and re-platforming to ‘park’ applications in the cloud while others are refactored.
The four steps to Google Cloud migration
There are four phases to go through to effectively and efficiently migrate to Google Cloud. Some smaller organisations with compact workloads will transition through these steps chronologically, but migrating complex SME and enterprise architecture and infrastructure is usually a staged, iterative process.
Step 1. Assess
The assessment stage involves auditing your business’ current hosting, operations, and workload infrastructures and architectures. Take an inventory of all of the databases, data warehouses, network technology, hardware, and applications that make up your business operations.
- Figure out your migration budget and inform IT teams of what will be happening. Consider the benefits of working with an IT provider who can support the migration project.
- Define how simple or hard it’ll be to move particular applications to the cloud and what needs to be done. For example, SQL data warehouses will need to be rewritten in BigQuery.
- Identify app dependencies that force certain apps to be moved in a specific order.
- Consider identifying first-movers – typically applications which don’t require refactoring in the cloud.
Step 2. Plan
The planning stage involves first constructing a roadmap for migrating business-critical applications and minimally impacting overall workflow. Your IT project management skills are crucial to build a timeline for migration and inform teams of what’s happening.
- Establish Google Cloud identities, e.g. Google Accounts and Workspace domains. Assign permissions on essential apps to remove administrative friction.
- Design network topology and connect existing environments to Google Cloud using public internet, Cloud VPN, peering or Google Interconnect.
Step 3. Deploy
This step begins with configuring and establishing your new data, operation, and workload structures. Automated deployment pipelines can be built in Cloud Build and Google Deployment Manager. Always deploy the simplest and most business-critical operations first.
- Avoid deploying applications until they’ve been tested and configured. Configuration management (CM) tools enable you to test configurations in a non-destructible user-controllable environment.
- Deployment may be automated, semi-automated or manual. Full manual deployment is only recommended where there is no other option.
Step 4. Optimise
Cloud optimisation is usually an iterative process that unfolds over months. Monitor the performance of your cloud-native and non-cloud-native apps and listen to feedback from IT teams and employees. Be prepared to change configurations to boost performance, particularly if you’ve refactored apps for the cloud.
- During cloud migration, Google Cloud Monitoring offers metric dashboards for monitoring Google Cloud environments.
- Codify apps and configurations to ensure replicability and repeatability.
- Explore horizontal and vertical scaling and improve system performance to take advantage of cloud capabilities.
- Train IT teams and adjoining departments to extract maximum value from new cloud services.
Ease your migration with an IT partner
The benefits of working in the cloud have been recognised across the industry — businesses and organisations of all shapes and sizes are taking on cloud migrations for their IT systems.
AWS, Azure and Google Cloud take the majority share of this multi-billion industry, and they are notoriously hard to split in terms of features and performance. However, the increasing popularity of BigQuery and ongoing support and innovation for semi-codeless AI and ML are starting to erode Google Cloud’s deficit with market-leader AWS.
Migrating to Google Cloud may be straightforward in the case of a compact, already-modern business tech stack. More planning is required to ensure a minimally disruptive migration where legacy systems are involved.
The path to cloud migration can be long and confusing. Partnering with an IT provider like Dr Logic will help smooth out the journey, avoiding common issues and pitfalls along the way. We will work with you to plan and orchestrate your migration with minimal friction and downtime for your business.
Contact us today and discuss your cloud migration requirements with our specialist team.
We are looking to partner
Like what you’ve read and would like to know what else we know? Then get in touch.