This document focuses on how to apply predefined businessconsiderations when planning a hybrid and multicloud strategy. It expands onguidance inDrivers, considerations, strategy, and approaches.That article defines and analyzes the business considerations enterprises should account for when planning such a strategy.

Clarify and agree on the vision and objectives

Ultimately, the main purpose of a hybrid or multicloud strategy is to achievethe identified business requirements and the associated technical objectives foreach business use case aligned with specific business objectives. To achievethis goal, create a well-structured plan that includes the followingconsiderations:

• Which workloads should be run in each computing environment.
• Whichapplication architecture patterns to apply across multiple workloads.
• Which technology andnetworking architecture pattern to use.

Know that defining a plan that considers all workloads and requirements isdifficult at best, especially in a complex IT environment. In addition, planningtakes time and might lead to competing stakeholder visions.

To avoid such situations, initially formulate a vision statement that addressesthe following questions (at minimum):

• What's the targeted business use case to meet specific business objectives?
• Why is the current approach and computing environment insufficient tomeet the business objectives?
• What are the primary technological aspects to optimize for by using thepublic cloud?
• Why and how is the new approach going to optimize and meet your businessobjectives?
• How long do you plan to use your hybrid or multicloud setup?

Agreeing on the key business and technical objectives and drivers, thenobtaining relevant stakeholder sign-off can provide a foundation for the nextsteps in the planning process. To effectively align your proposed solution withthe overarching architectural vision of your organization, align with your teamand the stakeholders responsible for leading and sponsoring this initiative.

Identify and clarify other considerations

While planning a hybrid or multicloud architecture, it's important to identifyand agree about the architectural and operational constraints of your project.

On the operations side, the following non-exhaustive list provides somerequirements that might create some constraints to consider when planning yourarchitecture:

• Managing and configuring multiple clouds separately versus building aholistic model to manage and secure the different cloud environments.
• Ensuring consistent authentication, authorization, auditing, andpolicies across environments.
• Using consistent tooling and processes across environments to provide aholistic view into security, costs, and opportunities for optimization.
• Using consistent compliance and security standards to apply unifiedgovernance.

On the architecture-planning side, the biggest constraints often stem fromexisting systems and can include the following:

• Dependencies between applications
• Performance and latency requirements for communication between systems
• Reliance on hardware or operating systems that might not be available inthe public cloud
• Licensing restrictions
• Dependence on the availability of required capabilities in the selectedregions of a multicloud architecture

For more information about the other considerations related to workloadportability, data movement, and security aspects, seeOther considerations.

Design a hybrid and multicloud architecture strategy

After you have clarified the specifics of the business and technical objectiveswith the associated business requirements (and ideally clarified and agreed on avision statement), you can build your strategy to create a hybrid or multicloudarchitecture.

The following flowchart summarizes the logical steps to build such a strategy.

To help you determine your hybrid or multicloud architecture technicalobjectives and needs, the steps in the preceding flowchart start with thebusiness requirements and objectives. How you implement your strategy can varydepending on the objectives, drivers, and the technological migration path ofeach business use case.

It's important to remember that a migration is a journey. The following diagramillustrates the phases of this journey as described inMigrate to Google Cloud.

This section provides guidance about the "Assess," "Plan," "Deploy," and"Optimize" phases in the preceding diagram. It presents this information in thecontext of a hybrid or multicloud migration. You should align any migration withthe guidance and best practices discussed in themigration path section of the Migrate to Google Cloud guide. These phases might apply toeach workload individually, not to all workloads at once. At any point in time,several workloads might be in different phases:

Assess phase

In theAssess phase, you conduct an initial workload assessment. Duringthis phase, consider the goals outlined in your vision and strategy planningdocuments. Decide on amigration plan by first identifying a candidate list of workloads that could benefit from beingdeployed or migrated to the public cloud.

To start, choose a workload that isn't business-critical or too difficult tomigrate (with minimal or no dependencies on any workload in other environments),yet typical enough to serve as a blueprint for upcoming deployments ormigrations.

Ideally, the workload or application you select should be part of a targetedbusiness use case or function that has a measurable effect on the business afterit's complete.

To evaluate and mitigate any potential migration risks, conduct amigration risks assessment.it's important to assess your candidate workload to determine its suitabilityfor migration to a multicloud environment. This assessment involves evaluatingvarious aspects of the applications and infrastructure including thefollowing:

• Application compatibility requirements with your selected cloud providers
• Pricing models
• Security features offered by your selected cloud providers
• Application interoperability requirements

Running an assessment also helps you identify data privacy requirements,compliance requirements, consistency requirements, and solutions across multiple cloud environments. The risks you identify can affect the workloads you chooseto migrate or operate.

There are several types of tools, likeGoogle Cloud Migration Center,to help you assess existing workloads. For more information, seeMigration to Google Cloud: Choose an assessment tool.

From a workload modernization perspective, thefit assessment tool helps to assess a VM workload to determine if the workload is fit formodernization to a container or for migration to Compute Engine.

Plan phase

In thePlan phase, start with the identified applications and required cloudworkloads and perform the following tasks:

1. Develop a prioritized migration strategy that definesapplication migration waves and paths.
2. Identify the applicablehigh-level hybrid or multicloud application architecture pattern.
3. Select a networking architecture pattern that supports theselected application architecture pattern.

Ideally, you should incorporate the cloud networking pattern with thelanding zone design.The landing zone design serves as a key foundational element of overallhybrid and multicloud architectures. The design requires seamlessintegration with these patterns. Don't design the landing zone inisolation. Consider these networking patterns as a subset of the landingzone design.

A landing zone might consist of different applications, each with adifferent networking architecture pattern. Also, in this phase, it'simportant to decide on the design of theGoogle Cloud organization, projects, and resource hierarchy to prepare your cloud environment landing zone for the hybrid or multicloudintegration and deployment.

As part of this phase you should consider the following:

• Define the migration and modernization approach. There'smore information about migration approaches later in this guide.It's also covered in more detail in themigration types section ofMigrate to Google Cloud.
• Use your assessment and discovery phase findings. Alignthem with the candidate workload you plan to migrate. Then developan applicationmigration waves plan.The plan should incorporate the estimated resource sizingrequirements that you determined during the assessment phase.
• Define the communication model required between thedistributed applications and among application components for theintended hybrid or multicloud architecture.
• Decide on a suitabledeployment archetype to deploy your workload, such as zonal, regional, multi-regional,or global, for the chosen architecture pattern. The archetype youselect forms the basis for constructing the application-specificdeployment architectures tailored to your business and technical needs.
• Decide on measurable success criteria for the migration,with clear milestones for each migration phase or wave. Selectingcriteria is essential, even if the technical objective is to havethe hybrid architecture as a short term setup.
• Define application SLAs and KPIs when your applicationsoperate in a hybrid setup, especially for those applications thatmight have distributed components across multiple environments.

For more information, seeAbout migration planning to help plan a successful migration and to minimize the associated risks.

Deploy phase

In theDeploy phase, you are ready to start executing your migrationstrategy. Given the potential number of requirements, it's best to take aniterative approach.

Prioritize your workloads based on the migration and application waves that youdeveloped during the planning phase. With hybrid and multicloud architectures,start your deployment by establishing the necessary connectivitybetween Google Cloud and the other computing environments. To facilitatethe required communication model for your hybrid or multicloud architecture,base the deployment on your selected design and network connectivity type, alongwith the applicable networking pattern. We recommend that you take this approachfor your overall landing zone design decision.

In addition, you must test and validate the application or service based on thedefined application success criteria. Ideally, these criteria should includeboth functional and load testing (non-functional) requirements before moving toproduction.

Optimize phase

In theOptimize phase, test your deployment: After you complete testing, andthe application or service meets the functional and performance capacityexpectations, you can move it to production. Cloud monitoring and visibilitytools, such asCloud Monitoring,can provide insights into the performance, availability, and health of yourapplications and infrastructure and help you optimize where needed.

For more information, seeMigrate to Google Cloud: Optimize your environment.To learn more about how to design such tools for hybrid or multicloudarchitecture, seeHybrid and multicloud monitoring and logging patterns.

Assess candidate workloads

The choice of computing environments for different workloads significantlyaffects the success of a hybrid and multicloud strategy. Workload placementdecisions should align with specific business objectives. Therefore, thesedecisions should be guided by targeted business use cases that enable measurablebusiness effects. However, starting with the most business-criticalworkload/application isn't always necessary nor recommended. For moreinformation, seeChoosing the apps to migrate first in the Migrate to Google Cloud guide.

As discussed in theBusiness and technical drivers section, there are different types of drivers and considerations for hybrid andmulticloud architectures.

The following summarized list of factors can help you evaluate your migrationuse case in the context of a hybrid or multicloud architecture withopportunities to have a measurable business effect:

• Potential for market differentiation or innovation that is enabled byusing cloud services to enable certain business functions or capabilities,such as artificial intelligence capabilities that use existing on-premisesdata to train machine learning models.
• Potential savings in total cost of ownership for an application.
• Potential improvements in availability, resiliency, security, orperformance—for example adding a disaster recovery (DR) site in the cloud.
• Potential speedup of the development and release processes—for example,building your development and testing environments in the cloud.

The following factors can help you evaluatemigration risks:

• The potential effect of outages that are caused by a migration.
• The experience your team has with public cloud deployments, or withdeployments for a new or second cloud provider.
• The need to comply with any existing legal or regulatory restrictions.

The following factors can help you evaluate the technical difficulties of amigration:

• The size, complexity, and age of the application.
• The number of dependencies with other applications and services acrossdifferent computing environments.
• Any restrictions imposed by third-party licenses.
• Any dependencies on specific versions of operating systems, databases,or other environment configurations.

After you have assessed your initial workloads, you can start prioritizing themand defining yourmigration waves andapproaches.Then, you can identify applicable architecture patterns and supportingnetworking patterns.This step might require multiple iterations, because your assessment couldchange over time. It's therefore worth re-evaluating workloads after you makeyour first cloud deployments.