Signs You Have Outgrown Your Cloud Provider

Migration is a project with real cost and real risk, so the bar for starting
one should be high. But staying on a platform that no longer fits has a cost
too, paid continuously and quietly. These are the signals worth acting on, and
the ones that feel urgent but are not.

Signals that genuinely indicate it is time

You are building something the platform already sells elsewhere

If your team is writing its own failover for a database, its own
autoscaling, or its own managed queue, you have begun paying in engineering for
something another platform sells as a product. That is sometimes the right call
and often is not, and it is worth pricing honestly.

The constraint has changed category

You chose a provider because cost was binding. Now the binding constraint is
compliance, or latency for users on another continent, or a capability your
current platform does not offer. The original reasoning no longer applies, which
means the original conclusion probably does not either.

You cannot get the hardware

Needing accelerator instances, very large memory configurations or a specific
region that your provider does not offer is a hard limit. No amount of
optimisation resolves it.

Support is failing you at moments that matter

If an outage was prolonged because nobody responded, and that has happened
more than once, support quality has become a business risk rather than an
inconvenience. This is a legitimate reason to move even when everything
technical is fine.

The economics have genuinely inverted

Growth changes which pricing model wins. A workload that was cheapest on
flat-rate plans may become cheaper on committed capacity at scale, and a
workload that outgrew its included transfer allowance may now be paying far more
in egress than the compute saving justifies. This is worth recalculating
annually rather than assuming the original comparison still holds.

Signals that feel urgent and usually are not

One bad month on the bill

A cost spike is a reason to investigate, not to migrate. Nearly always it is
a forgotten resource, an egress event or an expired credit, all of which follow
you to the next provider. Work through
reading a cloud invoice and
the five changes that matter
before concluding the platform is the problem.

A single outage

Every provider has outages. The question is whether the frequency and
handling are out of line, which needs more than one data point. Your own
architecture usually contributes more to your availability than your provider’s
does.

Something cheaper exists

Something cheaper always exists. The comparison that matters is total cost
including the migration, the retraining and the period during which your team is
less effective on an unfamiliar platform.

A conference talk

The architecture that suits a company with hundreds of engineers is rarely
the architecture that suits yours. Scale-driven advice is frequently correct for
the person giving it and wrong for the person receiving it.

A way to decide without guessing

1. Write down the constraint that is actually binding now. Not the one that was
   binding when you chose.
2. Check whether your current provider can satisfy it. Often it can, through a
   service or configuration you have not used.
3. If it cannot, price the move properly: data transfer out, engineering time,
   parallel running, and the productivity dip on a new platform.
4. Compare that against the annual cost of staying.
5. If the numbers are close, stay. Close means the benefit does not cover the
   risk.

The partial move is underrated

Migration is usually discussed as all or nothing, and it rarely needs to be.
Moving object storage alone, or moving batch processing to wherever accelerators
are available while serving stays put, captures most of the benefit for a
fraction of the risk.

Hybrid arrangements have a real cost in cross-provider transfer and in
operational complexity, so they are not free. But for a specific, bounded
problem they are frequently the better answer than relocating an entire estate.
The planning side is covered in
planning a migration between cloud
providers.