Cloud Migration. The Final Frontier. | Mollis Group Limited
cloud migration
1286
post-template-default,single,single-post,postid-1286,single-format-standard,bridge-core-2.0.9,ajax_fade,page_not_loaded,,qode-title-hidden,qode_grid_1300,qode-theme-ver-19.6,qode-theme-bridge,disabled_footer_bottom,qode_header_in_grid,wpb-js-composer js-comp-ver-6.7.0,vc_responsive

Cloud Migration. The Final Frontier.

What you need to know about cloud migration

Cloud migration. The Final Frontier. And one of the most complex when you’ve been running workloads on-premises for years, but it can be done.

To be successful, you need a clearly defined, well-researched, and coherent strategy. Any approach that doesn’t match this requirement will fail.

In this article, we’ll cover what you need to know about cloud migration with an emphasis on Google Cloud (we’re a Google Cloud Partner after all!).

What is cloud migration?

Cloud migration is the process of moving digital assets and workloads to cloud infrastructure. An example is moving apps running on on-premises servers to Google Cloud; another example is moving desktop workflows into Google Workspace.

Cloud migration phases

There are five main phases of cloud migration:

Phase 1: Determining the maturity of your organisation

Determining the maturity of your organisation in adopting cloud technologies is necessary to figure out your capabilities. This will identify skill and knowledge gaps and enable you to lead, scale and secure your cloud migration.

Phase 2: Identifying what workloads to migrate

The next phase of cloud migration is figuring out what workloads need to be migrated. You need to understand what workloads (data, apps and services) should be moved over so you can determine the types of cloud migration required.

Phase 3: Plan the foundation

The next phase of cloud migration is planning the foundational pieces of your cloud environment. You need to establish users and services, resource hierarchy, define access roles and design your network and connectivity.

Phase 4: Deploying the workloads

The next phase is to determine the best approaches to deploying workloads to your new cloud environment. For example, you could use manual deployments, automated deployments, configuration tools or container orchestration tools.

Phase 5: Optimising your environment

The next phase involves optimising your cloud environment to improve on the basic deployment. You could use autoscaling, move to managed workloads, automate certain deployment processes, train your team and start logging.

Types of cloud integration

Cloud integration falls into three categories:

IaaS integration

Google Cloud Platform covers this. It provides resources (infrastructure, i.e. bandwidth, data storage, servers) as a service. You configure and manage resources and are responsible for operating systems and apps running on the infrastructure.

PaaS migration

Google App Engine covers this. It provides the same compute resources as IaaS but with a development backend app within a PaaS environment. It’s a serverless platform for developing and deploying applications.

SaaS integration

Google Workspace covers this. It provides a suite of secure, cloud-native collaboration and productivity apps powered by Google. It includes Gmail, Calendar, Drive, Docs, Sheets, Slides, Meet and much more.

The different migration approaches

Lift and shift

This is when you migrate a workload with no changes. You migrate an exact copy of a workload or app from one environment to another.

Lift and shift is the least time-intensive approach. It works for workloads and apps that are ready to run in a cloud-native environment. You can also sometimes be forced into a lift and shift migration if you cannot refactor the workload.

Improve and move

This is when you modify a workload to adopt cloud-native approaches. This is necessary when the new environment doesn’t support an app.

Improve and move lets you leverage cloud features in incompatible but adaptable workloads. These migrations take longer due to refactoring. By modifying workloads, you make what you have work better for you.

Rip and replace

This is when you decommission a legacy workload and write an entirely new one designed for a cloud-native approach.

Rip and replace is time-intensive and disruptive but necessary when legacy workloads are incompatible with a cloud-native environment. If the application is not worth maintaining or evolving, rip and replace may also be the best option.

Get expert advice

If you require help from professionals who have a track record of successful cloud migrations, call us on 0208 012 8489 or email us at [email protected] We’re here to help you migrate to Google Cloud with simplicity #evolvewithus