Migrating to Google Cloud is, first and foremost, a decision about risk and cost, and only then a technical decision. Companies that start with technology often spend months choosing a service and find out too late how many servers they had, whose databases they were, and how much it would cost to keep all of that running.
The topic gained urgency in Brazil. In September, during the Google Cloud Summit Brasil 2026, Google announced that it will double by 2030 the capacity of cloud computing in the country, and that the web version of Gemini Enterprise will start processing data locally with Gemini 3.5 Flash from October 15, according to MobileTime. For those still running on their own servers, leased data centers, or traditional hosting, the practical question is how to get there without stopping operations. This guide answers with the phases, strategies, tools, and cost considerations.
When migrating to Google Cloud makes sense
Not every company needs to be in the cloud, and anyone who says otherwise is selling something. In my view, migration is justified when at least one of these signs shows up:
- Hardware reaching end of life or a data center contract close to expiring—forcing investment either way.
- Demand spikes that force you to buy capacity for the worst day of the year and leave it idle for the rest of the time.
- Data scattered everywhere across spreadsheets, legacy systems, and tools that don’t talk to each other—preventing serious analysis and the use of AI.
- Requirements for availability, backup, and security that the internal team can’t handle on its own.
- Need for AI and analytics at scale, where services like BigQuery and the Gemini models are already ready to use.
On the other hand, a small, stable application with low fixed costs and no expected growth rarely justifies the effort of a migration. Migrating just because of trends is the shortest path to a larger monthly bill with no visible benefit.
The four phases of a migration to Google Cloud
Google itself organizes the journey into four phases in its official migration guide. The order matters, and skipping the first step is the most expensive mistake in the process.
1. Assess: evaluate the current environment
This is discovery. You inventory servers, databases, applications, and the dependencies between them, and measure the real consumption of each one. The goal is to answer three questions: what exists, what is in use, and what depends on what. The Migration Center automates much of this, with environment scanning, total cost of ownership reporting, and a dependency map—without changing the applications.
2. Plan: build the foundation in the cloud
Before moving any workload, you need to build the ground: the structure of accounts and projects, network, identity and access, security policies, and cost controls. This is the least “visible” phase and the one that most prevents rework. A poorly designed network at the start becomes a security and performance problem two years later.
3. Deploy: execute the migration in waves
The migration happens in waves, starting with the workloads with the lowest risk, so the team learns throughout the process. Each wave follows the same cycle: replicate, test in an isolated environment, rehearse the cutover, and only then switch the traffic—using a defined rollback plan.
4. Optimize: adjust for the cloud
With everything up and running, the value-creating part begins for real: right-size machines, adopt managed services, automate scaling, and lock in discount commitments based on actual usage. This is also the moment to enable monitoring and alerts for availability and cost.
Six migration paths: which one to choose for each system
The word “migration” hides very different strategies. Google’s documentation describes six, and the choice is made system by system, not for the entire company.
| Strategy | What it is | When to use it | Effort |
|---|---|---|---|
| Rehost (lift and shift) | Move the system with minimal changes | Short timeline, hard-to-change legacy | Low |
| Replatform | Move and swap specific parts with managed services, such as the database | Fast gains without rewriting the code | Medium |
| Refactor | Change the system to take advantage of cloud capabilities | An application that needs to scale | Medium to high |
| Re-architect | Break down a monolithic system into smaller services | A large system with independent teams | High |
| Rebuild (rip and replace) | Rebuild the application as cloud-native | Outdated system with little to reuse | High |
| Repurchase | Replace the system with a ready-made service (SaaS) | Shelf software, such as email and collaboration | Low to medium |
The most common mistake I see in the market is applying rehost to everything and expecting the bill to drop. Without any adjustments, the company ends up paying for cloud at the price of an oversized server. Rehost works as a first step to get out of a data center in a hurry, as long as the optimization phase comes right after.
Google tools for each type of workload
Google provides specific tools for each type of asset. Knowing which one to use saves weeks.
| Tool | What it’s for |
|---|---|
| Migration Center | Discovery of assets, assessment, cost estimation, and planning |
| Migrate to Virtual Machines | Migrate vSphere VMs and disks, AWS, Azure, and Google Cloud VMware Engine |
| Database Migration Service | Migrate MySQL, PostgreSQL, SQL Server, and Oracle databases to Cloud SQL and AlloyDB, with continuous replication and minimal time out of service |
| Storage Transfer Service | Transfer large volumes of storage data |
| Transfer Appliance | Physical device for data volumes too large for the network |
| BigQuery Migration Service | Migrate data warehouses and queries to BigQuery |
For those who centralize marketing, sales, and operations data, the natural destination is often BigQuery, with Looker Studio or Power BI in the visualization layer. This is the foundation of an analytics data agency, and it’s where migrations often deliver the biggest business return.
São Paulo region, latency, and LGPD
Today, Google has a single cloud region in Brazil, the southamerica-east1, in Osasco (SP), with three zones, according to MobileTime. Details and other regions of the world are listed in the official locations list.
Running the application closer to the user reduces latency, which matters for e-commerce, apps, and customer support. It also simplifies the legal conversation. The LGPD allows the international transfer of data in specific cases (Article 33), and keeping data within a region in the country reduces the need to debate that point. This doesn’t replace legal analysis or a well-written contract, but it removes a common obstacle in projects involving banking, healthcare, and the public sector.
The Gemini update with local processing, starting October 15, points in the same direction. Architecture designs with AI in Brazil are increasingly likely to rely on infrastructure within the country.
How much it costs and how to avoid surprises in the bill
There is no single price, because cost depends on region, machine type, storage, network, and time of use. What exists is a method. Before migrating, use the Migration Center estimate to have a reference number. Then apply these controls:
- Budgets and alerts from day one. Set limits per project, with an email warning before you exceed them.
- Labels (labels) on every resource. Without them, nobody knows which area, customer, or system generated the expense.
- Right sizing. Adjust machines based on the real measured usage, not what the old server had.
- Discounts only after a history. Discounts for continuous use can reach up to 30% automatically for machines that run the full month, according to the Compute Engine documentation. Discounts for 1- or 3-year commitments are higher (third-party studies cite 28% and 46% in the flexible model, and you should check the official table before deciding). A long-term commitment should only be signed after two or three months of stable usage.
- Turn off what isn’t used. Test environments and orphaned disks are the most common source of invisible spending.
The most common mistakes
- Skipping the inventory. Migrating without knowing what exists guarantees surprises during cutover.
- Ignoring dependencies. A migrated system that talks to a database left behind starts suffering from latency.
- Permanent rehost. It works to get things moving, but without optimization the bill disappoints.
- Security handled at the end. Identity, network, and backup need to be designed before the first workload.
- No rollback plan. Every production cutover needs a tested path back.
- Nobody owns the account. Without a person responsible for costs, spending grows without anyone questioning it.
Step-by-step for a safe migration
Summarizing the process in a work sequence, from inventory to fine-tuning:
- Do a complete inventory of the environment
List servers, databases, applications, dependencies, and real usage. Tools like Migration Center automate this scan.
- Classify each system by strategy
Decide for each workload whether it will be rehosted, replatformed, refactored, rebuilt, repurchased, or retired.
- Build the foundation in the cloud
Create the project structure, the network, access control, security policies, budget alerts, and labels.
- Choose a low-risk pilot workload
Migrate first a not-so-critical system, to train the team and validate the process.
- Replicate, test, and rehearse the cutover
Use migration tools to replicate, test in an isolated environment, and rehearse the cut before touching production.
- Switch traffic with a rollback plan
Pick a low-traffic window, monitor closely, and keep the old environment available until things stabilize.
- Optimize and measure the cost
Right-size resources, adopt managed services, and only then lock in discount commitments.
How Superplural works in migrations to Google Cloud
Superplural is certified as a Google Cloud Partner and helps businesses host, scale, and integrate applications on Google Cloud infrastructure. The work ranges from provisioning servers, network, and storage to migrating and connecting existing systems, with security, firewalls, backups, and resource tuning to control costs. If you’d like to discuss a project, you can explore our Google Cloud Partner agency page and our IT consulting page.
After the migration, monitoring availability matters as much as the project itself. The Superplural Status provides uptime monitoring for the infrastructure, and the Superplural Analytics delivers access metrics with privacy as the top priority, on our own infrastructure. For those starting with a smaller project, we’ve already written a step-by-step guide on how to install and configure WordPress on Google Cloud, and also an analysis of the competition between the major clouds.
Frequently asked questions about migrating to Google Cloud
It depends on the size of the environment and the chosen strategy. A single site or application can migrate in days or weeks, while environments with many systems and dependencies are done in waves over several months.
Rehost is usually the starting point when the timeline is short, because it moves the system with few changes. The ideal is to plan optimization right after, so the cloud bill doesn’t end up higher than the old server’s cost.
Yes. The southamerica-east1 region is in Osasco, in São Paulo, and has three zones. It’s the only Google cloud region in the country today, and Google has announced it will double capacity in Brazil by 2030.
In many cases, yes. Tools like the Database Migration Service keep continuous data replication up to the cutover moment, which significantly reduces downtime.
Use budgets and alerts, labels on all resources, sizing based on real usage, and—only after a few months of history—discounts for commitments. Turning off environments and disks that aren’t in use also generates immediate savings.
If I had to summarize it in a single sentence, I’d say that migrating well is an organization task before it’s a technology task. The cloud delivers what it promises to those who know what they have, where they want to go, and who will manage the account. For those who don’t yet know any of those three things, the best first step is an honest inventory—and we’re happy to have that conversation.
