Google Cloud Infrastructure Partners

Hierarchy and identity, which every workload inherits

Google Cloud arranges resources as an organization containing folders, which contain projects, which contain the actual resources. Policies and permissions flow downwards, so this hierarchy is the primary control surface. Most organizations end up with folders reflecting either business units or environments, and the choice has consequences: environment-first folders make it simple to apply one rule to all production, while business-unit-first folders make delegated administration and cost attribution cleaner. Projects are the natural unit of isolation, quota and billing, so the common mistake is using too few — one enormous shared project produces a permissions model where everyone can affect everything.

Identity is the other half. Access should be granted to groups synchronised from your existing directory rather than to individuals, using predefined or custom roles at the folder level, with project-level grants as the exception. organization policy constraints then set the guardrails that cannot be argued with locally: restricting which regions resources may be created in, preventing external IP addresses on virtual machines by default, disabling service account key creation. These are decisions to make once, early, because retrofitting an organization policy across hundreds of running resources means finding and fixing every existing violation first.

Networking and security baseline to settle first

• Shared VPC or separate VPCs — whether workload projects attach to a centrally managed network, which centralizes control and simplifies connectivity, or hold their own networks with peering, which gives teams autonomy and more routing complexity.
• Address planning — non-overlapping ranges across cloud and on-premises, including room for future regions, because overlapping CIDR ranges are discovered at the worst possible moment.
• Connectivity to existing estate — Cloud VPN or Interconnect, with bandwidth, redundancy and the lead time for physical circuits, which is frequently the longest item on the plan.
• Egress and perimeter control — Cloud NAT for outbound access, firewall rules built from tags or service accounts rather than IP lists, and whether VPC Service Controls are needed around sensitive data services.
• Encryption and key management — where Google-managed keys suffice and where customer-managed keys in Cloud KMS are required, since key placement affects region choices.
• Logging and audit from day one — centralized log sinks, admin activity and data access logs, and retention aligned to your actual audit requirement rather than the default.

Sequencing waves and proving you can go back

A migration plan is mostly a dependency problem. Applications share databases, authentication services, file shares and batch schedules, and moving one without its dependencies produces traffic crossing back and forth between environments — slow, expensive and fragile. Wave design groups applications that must move together, then sequences the groups so that shared services move before the things depending on them. The first wave should be deliberately low-risk and genuinely representative: something with real users but a tolerant recovery window, chosen to exercise the landing zone, the network path and the cutover runbook while the stakes are manageable.

Rollback is the part most often written down and least often tested. For each wave, the plan should state the point of no return, how long the old environment stays available and warm, how data written after cutover is reconciled if you revert, and who decides. A rollback that depends on restoring a backup taken before cutover is not a rollback for anything transactional, because the writes made in the new environment are lost. Ask for a wave where rollback was actually exercised in a rehearsal rather than merely documented. The distinction matters more than the size of the estate being moved.

What a wave plan should state explicitly

• Dependency map per application — inbound and outbound integrations, shared databases and scheduled jobs, built from observed traffic rather than from an outdated architecture diagram.
• Data migration method and cutover window — continuous replication with a short switch, or a bulk copy with a freeze, and the downtime each implies for the business.
• Performance baseline before the move — the current latency and throughput figures, without which nobody can settle the inevitable argument about whether the application got slower.
• Validation steps and who signs them off — the specific functional and integration checks performed after cutover, in order, with an owner for each.
• The rollback decision point — the time by which the decision must be made, the criteria for making it, and what happens to data written in the meantime.
• Decommissioning of the source — the date the old environment is switched off, since parallel running that never ends is how a migration doubles its own cost.

Deciding per workload, not per program

Lift and shift means moving virtual machines broadly as they are. It is faster, lower risk, and leaves you running the same operational model in a more expensive place — which is fine if the driver is a data center exit with a fixed date. Re-platforming means changing how the workload runs: a self-managed database becoming Cloud SQL, an application moving into containers on GKE or into Cloud Run, batch jobs becoming managed services. It costs more up front and returns lower operational effort and better cost efficiency afterwards. The program-level version of this argument is unproductive. The decision belongs to each workload.

Useful criteria are concrete. How much life remains in the application, since re-platforming something due for replacement in eighteen months is wasted effort. How variable its load is, because idle capacity is where managed and autoscaling services pay for themselves. How much of its operational burden is undifferentiated — patching, backups, failover — which managed services absorb. Whether anyone still holds knowledge of its internals. And whether the migration deadline allows the extra work at all. A reasonable pattern is lift and shift to meet the date, with named workloads flagged for modernisation afterwards and actually scheduled, because unscheduled modernisation does not happen.

Signals that favor re-platforming a given workload

• Highly variable demand — load that peaks and collapses pays repeatedly for statically sized virtual machines and benefits immediately from autoscaling or serverless execution.
• Heavy database administration — a self-managed database consuming ongoing effort on patching, backup verification and replica management is a strong candidate for a managed equivalent.
• Stateless application tiers — services that hold no local state are the cheapest things to containerise and the quickest to show the benefit.
• Licensing tied to cores — commercial licences priced per core sometimes cost more than the compute, and a managed or open-source alternative changes the arithmetic entirely.
• Long remaining lifespan — the effort only returns over time, so an application with years ahead of it justifies work that a soon-to-be-replaced system does not.

Cost control designed in, not reviewed later

Cloud cost management fails for a structural reason: the people who create the spend are not the people who see the bill. Fixing it starts with attribution. Agree a small labeling standard — environment, business unit, application, cost center — enforce it through organization policy or infrastructure-as-code templates, and apply it from the first resource, because labels added later never cover historical spend. Billing data should export to BigQuery from day one so cost can be analyzed by any of those dimensions rather than through the console's summary views. Without attribution, every cost conversation stalls at the point where nobody can say whose workload moved the number.

Then set the controls. Budgets with alert thresholds per project, routed to the team that owns the workload rather than only to finance. A rule that non-production environments shut down outside working hours, which is often the single largest saving available. Committed use discounts purchased only once several months of steady baseline usage justify them, sized to the floor rather than the average. And a named person accountable for cloud cost overall, with the standing to ask why a figure moved. Structure without that ownership produces excellent dashboards that nobody acts on.

Running it after the engagement ends

Operational handover is more than credentials and documentation. Your team needs to be able to answer, unaided, how a new project is created with the correct policies attached, how patching happens for the virtual machines that remain, what the monitoring alerts mean and who receives them, how backups are verified rather than merely scheduled, and how access is reviewed and revoked. Each of those should have been performed by your staff at least once before the engagement ends, with the partner watching, rather than demonstrated to them in a presentation.

Identity hygiene deserves particular attention because it degrades silently. Service accounts accumulate, broad roles granted during migration are never narrowed, and keys outlive the people who created them. Leave the engagement with a recurring review: privileged role holders listed and confirmed, unused service accounts disabled, key-based authentication replaced with workload identity federation where possible, and organization policy violations reported. Infrastructure defined as code makes all of this tractable, since the environment can be inspected and reproduced from a repository. Where infrastructure was created by hand, insist it is brought under code before handover, or you inherit an estate nobody can safely rebuild.

Programs rarely stop at one product. Buyers hiring for Google Cloud Infrastructure often pair it with BigQuery partners , Campaign Manager 360 partners or Display & Video 360 partners , or review the whole Google Cloud landscape before committing.