When to Bring in Outside Cloud Help: The Questions to Ask First
Bring in outside cloud help when the decision you are about to make is hard to reverse and you have not made it before: the account and network topology of a landing zone, the cutover plan for a database migration, the blast radius of an IAM change. Those are the moments where a wrong call costs quarters, not sprints. Day-to-day operations rarely need help. Structural, one-way-door decisions often do.
That is the honest test. Below are the questions a technical decision-maker actually types into a search box while working this out, grouped by the five areas where outside help earns its keep. Each one is the question behind the question, answered with the specifics you would need to either do it yourself or brief someone who will.
How do we structure a landing zone so it still works in three years?
The trap is designing for the org chart you have today. Accounts and subscriptions are cheap; moving workloads between them later is not.
Start with the boundary that is genuinely permanent. On AWS, an account is the only way to separate items at a billing level, and service quotas are allocated per account, so the account is your unit of isolation for cost, quota and blast radius. AWS Control Tower gives you one landing zone per organization, and it can extend governance over an existing AWS Organizations setup rather than forcing a greenfield start, which matters if you already have accounts in the wild.
On Azure the equivalent lesson is written into the guidance directly: keep the management group hierarchy reasonably flat, ideally no more than three to four levels, and do not mirror your organizational structure into a deeply nested tree. Microsoft is blunt about the failure mode: use management groups for policy assignment, not for billing or RBAC, and do not assign application teams permissions via RBAC at management group scope. Grant those at the subscription or resource group they actually need.
On Google Cloud, the network is the part people regret. The recommended design for most cases uses separate Shared VPC networks for each environment (development, testing, production), which centralises network management while keeping environments isolated. Hybrid connectivity runs over Cloud VPN or Cloud Interconnect.
What to check before you lay anything down
- Decide centralised versus decentralised network control now. Google's guidance makes this the primary factor driving the whole design, and it is expensive to reverse.
- Reserve non-overlapping CIDR ranges across every environment and every on-premises network before the first subnet exists.
- Separate production into its own account or subscription from day one, even if it feels premature.
The trade-off: a stricter separation up front means more plumbing (transit, DNS, shared services) before you ship anything. The cost of skipping it is a re-org of live workloads later. This is the work our cloud architecture and landing zone practice exists for, and it is the clearest case for a second pair of eyes because the mistakes surface years after they are made.
When is our Terraform a liability instead of an asset?
The signal is not lines of code. It is whether two engineers can safely apply changes at the same time, and whether anyone can explain what is in state.
Check your backend first. If you are on the S3 backend, note that DynamoDB-based locking is deprecated and will be removed in a future minor version, replaced by native S3 locking. The migration is small but real:
terraform {
backend "s3" {
bucket = "acme-tf-state-prod"
key = "platform/network/terraform.tfstate"
region = "eu-west-1"
encrypt = true
use_lockfile = true # S3 native locking; drop the dynamodb_table arg
}
}The use_lockfile argument opts into locking via S3 itself, so you can retire the lock table. If you are still relying only on DynamoDB, that is a dated setup worth fixing before it fails on an upgrade.
Beyond locking, the questions that tell you whether to bring in platform and DevOps help are structural: is state split so a blast radius is one team, not the whole estate? Do modules have a stable interface, or does every change ripple? A paved road that engineers avoid is worse than no road, because you pay for it and get shadow infrastructure anyway.
How do we set SLOs the on-call team will actually defend?
The wrong version of this project produces a dashboard nobody trusts. The right version starts before any metric.
Google's SRE guidance is explicit that the first step is bringing product, development and SRE teams together to agree the critical user journeys, often writing them down for the first time. You measure the journey the user cares about, not CPU. Once you have an SLI and a target, the error budget is arithmetic: error budget = (1 − SLO goal) × eligible events in the compliance period. At a 95% goal, 5% of measured events may fail before you miss the objective.
Then you alert on burn rate, not on every blip. The burn rate tells you how fast you are consuming the budget, so a fast burn pages immediately while a slow burn opens a ticket. That single change is usually what turns an unsustainable on-call rotation into one people can live with. If your team is drowning in alerts that do not map to user pain, that is the problem reliability and SRE work addresses, and it needs judgement more than tooling.
What to check first
- Can you name the three or four journeys whose failure would make a customer call you? If not, stop; that is the actual work.
- Is any current alert not tied to an SLO? Each one is a candidate for deletion.
What do we check before tightening IAM, and how far do we go?
The fear is legitimate: over-tighten and you break a workload at 2am; under-tighten and you are the breach. The answer is to derive least privilege from evidence, not guesswork.
The AWS baseline is to grant only the permissions required to perform a task and to start from AWS managed policies and move toward least privilege. The lever that makes this safe is IAM Access Analyzer policy generation: it reviews your CloudTrail logs and generates a policy template containing the permissions the entity actually used in a date range. You replace a broad policy with one grounded in real activity, which removes the guesswork that makes people avoid this work entirely.
The order of operations matters. Check first that CloudTrail is capturing the activity you care about across a representative window, including monthly and quarterly jobs, before you generate anything. A policy built from two quiet weeks will break the batch job that runs on the last day of the month. This is the difference between guardrails and gates that our security and compliance work is built around: restrict by evidence, keep a rollback path, and never tighten a role you have not observed.
How do we plan a migration so the cutover is boring?
Boring is the goal. Drama at cutover means the planning happened at cutover.
First, pick a strategy per workload, not per programme. AWS frames this as the 7 Rs: rehost, replatform, relocate, retire, retain, repurchase and refactor. The guidance is candid that refactor is not recommended for large migrations because it modernises the application during the move, which is the most complex and hardest to manage at scale. Rehost or replatform to get out of the datacentre, then modernise once you are there.
| Strategy | What it is | Costs you later |
|---|---|---|
| Rehost (lift and shift) | Move as-is, often with AWS Application Migration Service | Cloud bill reflects on-prem sizing until you optimise |
| Replatform | Small changes, e.g. self-managed DB to a managed service | Some rework, but you shed operational toil |
| Refactor | Re-architect during the move | High complexity; not advised for large migrations |
For the database, the cutover risk lives in the data. AWS DMS supports full load plus change data capture so the source stays live while you replicate. The best-practice details are where migrations succeed or stall: turn off secondary indexes during the initial load and re-enable them for ongoing replication, and on Amazon RDS targets turn off backups and Multi-AZ until cutover. If the source is straining, consolidate tasks, because each task queries the source for changes independently.
What to check before you migrate anything
- Build a real dependency map. A workload you thought was standalone usually has a chatty neighbour.
- Confirm the source database can carry CDC load. For some sources DMS needs increased change logging, which adds write load you must budget for.
- Rehearse the cutover on a copy and measure the replication lag you can achieve, so the maintenance window is a number, not a hope.
A datacentre exit or database move is the highest-stakes, most reversible-in-theory-but-not-in-practice work on this list, which is exactly why it is worth planning with people who have done it before. That is the shape of our cloud migration engagements: make the cutover the least eventful part of the project.
Frequently asked questions
When should a mid-size company hire outside cloud help instead of doing it internally?
Bring in help for one-way-door decisions your team has not made before: landing zone topology, IAM restructuring, and migration cutovers. These are the choices that are cheap to get right up front and expensive to reverse later. Keep steady-state operations in house, where your team already has the context.
What should I check before changing our AWS or Azure account structure?
Confirm your permanent boundaries first: billing separation, service quotas and blast radius all follow the account or subscription boundary, so decide production isolation before anything else. Reserve non-overlapping CIDR ranges across all environments. On Azure specifically, keep management groups flat and used for policy, not RBAC or billing, because unwinding a deep hierarchy later is painful.
How do I tighten IAM permissions without breaking production?
Derive the policy from real usage rather than guessing. IAM Access Analyzer reads your CloudTrail logs and generates a policy from the permissions an entity actually used over a date range you choose. Make sure that range covers periodic jobs, monthly and quarterly, so you do not strip a permission a batch process needs, and keep a rollback path.
How do I make a database migration cutover low-risk?
Use full load plus CDC so the source stays live, and rehearse the cutover on a copy to measure achievable replication lag before you commit to a window. Apply the standard tuning: drop secondary indexes during the initial load, and disable RDS backups and Multi-AZ until cutover. Build a dependency map first, because the workload that surprises you at cutover is the one you thought stood alone.
Is refactoring during a migration a good idea?
Usually not, if the migration is large. AWS guidance says refactor is the most complex strategy and is not recommended for large migrations because you are modernising and moving at once. Rehost or replatform to exit the datacentre, then modernise from a stable position where each change is smaller and reversible.