# Google Cloud Migration Guide for Small Businesses

> A Google Cloud migration for a small business follows six stages: discover workloads with Migration Center, choose a migration approach for each one, build a secure landing zone, migrate in waves using tools such as Migrate to Virtual Machines and Database Migration Service, cut over with a rollback plan, and optimize cost and security after go-live. Small migrations typically take 4-8 weeks.

- URL: https://www.desaiinfo.net/gcp-consulting/gcp-migration-guide
- Publisher: Desai InfoTech (https://www.desaiinfo.net)
- Last updated: 2026-10-17
- Topics: google cloud migration, gcp migration guide, migrate to google cloud, gcp migration steps, migrate vms to google cloud


## Key takeaways

- Inventory every server, application, database and dependency before choosing a migration approach.
- Build the landing zone (projects, IAM, networking, logging, budgets) before moving any workload.
- Use Google's native tools, including Migrate to Virtual Machines, Database Migration Service and Storage Transfer Service, to reduce risk.
- Migrate in waves starting with low-risk systems, and keep a tested rollback path for every cutover.
- Plan an optimization pass 30-60 days after go-live to rightsize resources and apply discounts.

Migrating to Google Cloud is less about moving virtual machines and more about making a handful of good decisions in the right order. This guide is written for small businesses and nonprofits with a modest server footprint, typically a few to a few dozen servers, one or more databases, and file shares. It complements our broader [Google Cloud consulting](https://www.desaiinfo.net/gcp-consulting) overview.

## What does a Google Cloud migration involve?

A Google Cloud migration moves workloads from on-premises servers or another cloud into Google Cloud Platform (GCP), then operates them securely and cost-effectively. It covers compute, data, networking, identity and the processes your team uses to run systems.

For most small organizations, the scope includes:

- **Servers** running line-of-business applications, moved to Compute Engine virtual machines or containers on Cloud Run.
- **Databases** such as SQL Server, MySQL or PostgreSQL, moved to Cloud SQL or kept on VMs.
- **Files** on a Windows file server or NAS, moved to Filestore, Cloud Storage, or replaced by Google Drive if you use Google Workspace.
- **Identity** integrated with Google Workspace or Cloud Identity so users sign in with accounts they already have.
- **Connectivity** from offices to the cloud via Cloud VPN or, for larger needs, Cloud Interconnect.

## Step 1: How do you discover and assess workloads?

Start with a complete inventory. You cannot plan what you have not found, and undocumented dependencies are the most common cause of migration delays.

Google Cloud **Migration Center** can collect inventory and utilization data from your environment and produce cost estimates for running equivalent resources in GCP. Pair that with short interviews with each application owner to capture what the data cannot show: business criticality, acceptable downtime, licensing restrictions and upcoming changes.

Record at minimum:

| Item | Why it matters |
|---|---|
| CPU, memory and disk utilization over several weeks | Rightsizing instead of copying oversized servers |
| Operating system and version | Support status on Compute Engine and upgrade needs |
| Application dependencies and ports | Grouping servers into migration waves |
| Database engine, size and change rate | Choosing a database migration method |
| Licensing (Windows, SQL Server, third-party) | Cost estimate and compliance |
| Recovery time and recovery point objectives | Backup design and cutover window |

Our [cloud readiness assessment](https://www.desaiinfo.net/cloud-migration/cloud-readiness-assessment) explains how to evaluate organizational readiness alongside the technical inventory.

## Step 2: Which migration approach fits each workload?

Assign each workload one of the "7 Rs": rehost, relocate, replatform, refactor, repurchase, retain or retire. For small organizations, three dominate.

- **Rehost (lift and shift):** move the VM as-is to Compute Engine. Fastest and lowest risk, ideal for retiring hardware on a deadline.
- **Replatform:** make a small change for a big benefit, such as moving a self-managed MySQL server into Cloud SQL so Google handles patching, backups and failover.
- **Repurchase:** replace a self-hosted application with SaaS, such as moving an on-premises email or file server to Google Workspace.

Refactoring an application to run on Cloud Run or Google Kubernetes Engine (GKE) delivers the most long-term flexibility, but it is a software project rather than a migration task. The full decision framework is in [cloud migration strategy: the 7 Rs](https://www.desaiinfo.net/cloud-migration/cloud-migration-strategy-7rs).

## Step 3: Why build a landing zone before migrating?

A landing zone is the secure, standardized foundation every workload lands in. Building it first prevents the most expensive mistakes, which are hard to undo once production systems depend on them.

A small-business landing zone typically includes:

1. **Resource hierarchy:** an organization node, folders for production and non-production, and separate projects per application or environment.
2. **Identity and access:** Google Groups mapped to IAM roles, 2-Step Verification enforced and no routine use of the basic Owner role.
3. **Networking:** a Shared VPC with planned IP ranges that do not overlap your office networks, firewall rules and Cloud NAT for outbound traffic.
4. **Organization policies:** constraints such as blocking public access to Cloud Storage, disabling service account key creation and restricting resource locations.
5. **Logging and monitoring:** centralized Cloud Logging sinks and Cloud Monitoring alerts.
6. **Billing controls:** budgets with alerts per project and billing export to BigQuery.

Define the landing zone in Terraform so it is reviewable and repeatable. See the [Terraform infrastructure as code guide](https://www.desaiinfo.net/devops-consulting/terraform-infrastructure-as-code-guide) for practices that apply here. Security controls are covered in more depth in [GCP security best practices](https://www.desaiinfo.net/gcp-consulting/gcp-security-best-practices).

## Step 4: How do you migrate servers, databases and files?

Use Google's native migration services wherever they fit. They are designed for minimal downtime and are generally included at no additional charge beyond the resources they create, though you should confirm current terms.

| Workload | Recommended tool | Notes |
|---|---|---|
| VMware, Hyper-V, physical or other-cloud VMs | Migrate to Virtual Machines | Replicates in the background, then cuts over with a short outage |
| MySQL, PostgreSQL, SQL Server | Database Migration Service | Continuous replication minimizes downtime for supported engines |
| File and object data | Storage Transfer Service | Scheduled, incremental transfers to Cloud Storage |
| Very large offline datasets | Transfer Appliance | Physical device shipped to Google for bulk transfer |
| Analytics data | BigQuery Data Transfer Service | Scheduled loads from supported SaaS and cloud sources |

Migrate in waves of related systems. A typical sequence is a test or low-risk internal application first, then file data, then line-of-business systems, and finally the most critical database. Each wave should include functional testing by the application owner, not just IT. For data-heavy moves, our [data migration guide](https://www.desaiinfo.net/cloud-migration/data-migration-guide) covers validation and reconciliation.

## Step 5: How do you cut over safely?

Plan every cutover as a rehearsed event with a decision point and a rollback path.

- Schedule the window during low-usage hours and communicate it in advance.
- Lower DNS time-to-live values a few days before cutover.
- Freeze changes on the source system, complete final replication and validate data.
- Switch DNS, connection strings or user mappings.
- Run a short test script covering the most important business transactions.
- Keep the source system intact and powered off, not deleted, until the new environment has run cleanly for an agreed period.

## Step 6: What happens after go-live?

The migration is not finished at cutover. Plan an optimization pass 30 to 60 days later, once real utilization data exists.

- Apply rightsizing recommendations from Google's Recommender.
- Purchase committed use discounts only for steady, predictable usage.
- Schedule non-production VMs to shut down outside business hours.
- Review IAM grants and Security Command Center findings.
- Confirm backups and test a restore.
- Decommission on-premises hardware and cancel associated support contracts.

Detailed tactics are in [GCP cost optimization](https://www.desaiinfo.net/gcp-consulting/gcp-cost-optimization) and the general [post-migration optimization](https://www.desaiinfo.net/cloud-migration/post-migration-optimization) guide.

## How Desai InfoTech runs Google Cloud migrations

Desai InfoTech runs small-business migrations foundation-first: a short discovery, a Terraform-defined landing zone, then waves sized so each one can be tested and rolled back. If you are still deciding between providers, compare options in [AWS vs GCP](https://www.desaiinfo.net/compare/aws-vs-gcp), or request a [free cloud assessment](https://www.desaiinfo.net/free-cloud-assessment) to get an inventory-based plan and timeline.

## How to migrate a small business to Google Cloud: steps

1. **Discover and assess:** Inventory servers, applications, databases and dependencies using Migration Center discovery and interviews with application owners.
2. **Choose a migration approach per workload:** Decide whether each workload will be rehosted, replatformed, refactored, replaced with SaaS, retained or retired.
3. **Build the landing zone:** Create the organization, folders, projects, IAM groups, VPC networking, logging and budget alerts, ideally as Terraform code.
4. **Migrate in waves:** Move low-risk workloads first using Migrate to Virtual Machines, Database Migration Service and Storage Transfer Service, testing each wave.
5. **Cut over and validate:** Switch DNS and users to the new environment during a planned window, validate functionality and keep the rollback path available.
6. **Optimize and decommission:** Rightsize resources, apply committed use discounts, harden security and retire on-premises hardware once stable.

## Frequently asked questions

### How long does it take to migrate to Google Cloud?

A small business with fewer than ten virtual machines and one or two databases typically completes a Google Cloud migration in 4-8 weeks, including discovery, landing zone setup, migration waves and cutover. Larger environments, complex dependencies or applications being refactored to Cloud Run or GKE usually take 8-16 weeks or more.

### What tools does Google provide for migration?

Google Cloud provides Migration Center for discovery, assessment and cost estimation; Migrate to Virtual Machines for moving VMware, physical and other cloud VMs to Compute Engine; Database Migration Service for MySQL, PostgreSQL and SQL Server moves into Cloud SQL and related targets; and Storage Transfer Service for moving file and object data.

### Can we migrate Windows servers to Google Cloud?

Yes. Compute Engine supports Windows Server, and Migrate to Virtual Machines can move existing Windows VMs. Windows Server and SQL Server licensing can be included in the hourly price or, in some cases, brought from your own agreements under specific rules. Review licensing early, because it often has a significant effect on the total cost estimate.

### Should we lift and shift or modernize?

Most small organizations rehost first to retire aging hardware quickly, then modernize selected applications once they are running in the cloud. Modernizing during the move makes sense when an application is already being rewritten, or when a managed service such as Cloud SQL or Cloud Run is a near drop-in replacement with clear benefits.


## Related

- [Google Cloud (GCP) Consulting Services](https://www.desaiinfo.net/gcp-consulting)
- [The 7 Rs of Cloud Migration: Choosing a Strategy for Each Workload](https://www.desaiinfo.net/cloud-migration/cloud-migration-strategy-7rs)
- [Cloud Migration Checklist for Small Businesses and Nonprofits](https://www.desaiinfo.net/cloud-migration/cloud-migration-checklist)
- [Google Cloud Cost Optimization for Small Businesses](https://www.desaiinfo.net/gcp-consulting/gcp-cost-optimization)
- [Google Cloud Security Best Practices for Small Businesses](https://www.desaiinfo.net/gcp-consulting/gcp-security-best-practices)
- [Data Migration Guide: Moving Databases and Files to the Cloud](https://www.desaiinfo.net/cloud-migration/data-migration-guide)