If you’ve been running workloads on-premises for years, migrating to the cloud can be a daunting prospect. You probably already have some workloads in the cloud (public, private or both), but they’re most likely workloads that were considered ‘low-hanging fruit’ and relatively easy to lift and shift.
What’s left is often core to the business, like mission-critical SAP or Oracle workloads, which can be complex, expensive and difficult to migrate. These workloads aren’t a quick lift and shift; you need to factor in aspects related to people, process and technology. And you’ll have to consider whether you have the resources or skill sets in-house for such a complex undertaking or if you’ll need to supplement your team with a trusted Google Cloud partner.
Maybe you’ve chosen to move some of your workloads to Google Cloud—perhaps as part of a hybrid or multi-cloud approach. But, with the open nature of Google Cloud, you may be wondering how to get started and what approach to take, so you can make the most of your data after the migration.
Do an assessment: Before you get started, you’ll need to assess your current landscape—including legacy products, third-party interfaces and integrations—to ensure it’s compatible with Google Cloud. It may make sense to bring in a trusted party to do a thorough (and unbiased) assessment of your environment.
Understand your workloads: Identify the types of workloads that need to be migrated. Are they legacy or cloud-native? A legacy workload could be difficult to modify for the cloud and expensive to operate in the cloud. Also consider its hardware, performance and licensing requirements, the criticality of the workload and whether it has dependencies on other workloads.
Understand your migration approaches: Different workloads require different migration approaches. That could include a lift and shift to the cloud, a modification to the workload during migration that adopts a cloud-native approach or a rip-and-replace that requires decommissioning the workload, writing a new one and then adopting a cloud-native approach. While a standardized approach can be helpful, you don’t have to take the same approach for all workloads.
POC and TCO: Before the migration, test different use cases by conducting a proof of concept (POC), especially for more complex workloads. At the same time, calculate the total cost of ownership (TCO) so you’ll have a sense of your cloud expenditure when you move to Google Cloud from your current environment, whether on-prem, private cloud or hybrid cloud. A trusted partner can help bring to light any hidden costs you might miss if moving from a CapEx to an OpEx model.
Moving from cloud to cloud: You may be migrating on-prem workloads into Google Cloud, but you may also want to shift workloads from one cloud to another—whether from a private cloud or from another public cloud such as AWS or Azure. You’ll need to assess whether you can create a seamless pipeline between the two and which technologies will help you get there. Tip: It helps to work with a partner who is experienced in multi-cloud environments, and with the public cloud platforms.
Our team has migrated hundreds of critical workloads to, from and within public, private, hybrid and multi-cloud environments. We’re also a Google Cloud Partner with 200-plus Google Cloud certifications and 25 years of experience in consulting, databases, DevOps and analytics.
Our roadmap assessment services include an analysis of your current estate to determine the technical difficulty of the migration, the creation of a migration roadmap (which includes future state architecture, risk, timelines and estimated cloud consumption costs) and recommendations for next steps.
Looking for more advice? Schedule a call today with a Pythian Google Cloud expert.