Every cloud migration dependency map has the things you expect: application services and their upstream/downstream relationships, database dependencies, authentication paths, third-party integrations. Most of them also have a gap: cloud quota isn’t on the list.
Cloud quota — the per-project, per-region limits on CPUs, IP addresses, load balancers, node pools, VPC routes, specific API rates — is treated as an infrastructure detail, something that will get sorted out when it’s needed. That assumption fails at the worst possible time: mid-cutover, when you’re running both old and new environments simultaneously, consumption is doubled, and you hit a limit on something that wasn’t on anyone’s radar.
Why quota hits hardest during migration
Under normal operations, quota limits are usually not a concern. You’re running one environment, your footprint is stable, and your cloud provider’s default limits are sufficient for your steady state.
A migration changes this in a specific way. For a period — days to weeks depending on the migration approach — you’re running both environments. Traffic shifting models mean the new environment is partially live while the old one is still running. That doubles (or more) your consumption of many resource types: virtual machines, IPs for load balancers, VPC peering connections, SSL certificates, NAT gateway counts.
On GCP, for example, projects have default regional quotas for CPUs, in-use IP addresses, and forwarding rules. The defaults are generous enough for most steady-state workloads, but a migration where you’re running parallel environments can push a project over default limits mid-operation. On AWS, similar constraints apply to Elastic IPs, VPC endpoints, security groups per VPC, and load balancers per region.
The resource you hit depends on your architecture. The timing — mid-cutover — is almost always the worst possible.
Quota as a hard dependency
The fix is to treat quota as a first-class dependency in the migration plan, the same way you’d treat a database migration or an authentication reconfiguration. Specifically:
Map your quota consumption before you start. Inventory every quota-constrained resource type in your target environment and estimate peak consumption during the parallel-run phase. This is the phase where both environments are active and consumption is highest. The estimate doesn’t need to be exact — a conservative upper bound is what you want.
Submit quota increase requests weeks before the migration starts. Cloud providers don’t approve quota increases instantly. GCP quota increases typically take a few business days; more significant requests can take longer. AWS service limit increases go through Support and the timeline varies. If you discover a quota gap during the migration, you are now racing a support ticket while the migration is in-flight.
The rule of thumb I use: quota increase requests go in at least three weeks before the first parallel-run cutover. If the timeline is aggressive, sooner.
Track quota consumption as a migration metric. During the parallel-run phase, quota utilization belongs in the daily status review alongside application health metrics. A quota that’s at 70% with more cutovers to run is a signal; a quota that’s at 90% is a blocker that needs attention now, not when you hit the wall.
The specific resources that catch teams
A few resource types come up repeatedly:
IP addresses. Every external load balancer, every NAT gateway, every reserved static IP counts. During a migration, you may temporarily need far more than your steady state. In-use IP address quota in a GCP region is a common constraint.
VPC routes and peering connections. Large environments with many VPCs or complex routing topologies can hit route table limits. Peering connections have per-VPC limits that can be unexpectedly tight.
Load balancers and forwarding rules. If your migration uses traffic splitting at the load balancer level, or if you’re running parallel load balancer configurations per service, forwarding rule counts accumulate quickly.
API quotas. For GCP, the Cloud Resource Manager and Compute Engine APIs have rate limits. Terraform running at scale against a large infrastructure creates bursts of API calls that can hit rate limits mid-apply. This shows up as intermittent errors that look like flakiness but are actually throttling.
What the conversation looks like
When I do migration planning, quota comes up during the dependency mapping phase — the same phase where we’re documenting service dependencies and data flow. For each target environment component, the question is: what cloud resources does this consume, what are the default limits, and what do we expect peak consumption to be during parallel operation?
The output is a quota checklist: resource type, current limit, expected peak consumption, whether an increase request is needed, and the date the request was submitted. That checklist goes into the project governance tracker alongside the cutover plan.
It’s not glamorous infrastructure work. But it’s the kind of thing that prevents a two-hour maintenance window from becoming a six-hour incident because someone hit a forwarding rule limit at 1am with a support ticket as the only path forward.
Map it early, request increases early, track it during the migration. Quota is invisible until it isn’t.