Choosing a cloud computing consulting partner

Cloud computing consulting: four kinds of firm sell the same label

Cloud computing consulting covers four different businesses: hyperscaler resellers, global systems integrators, boutique specialists, and software vendors with a consulting arm.

To choose a partner, match the firm type to your project. Then test the firm on how it is paid, how it designs a landing zone, how it controls cost, and who runs the system after go-live.

In our experience, buyers often compare the four types as if they were interchangeable, then wonder why a proposal feels mismatched. Here is where each type tends to fit and where it tends to disappoint:

• Hyperscaler reseller. Best fit: buying credits and support on one platform. Typical failure: advice that favours the platform they resell.
• Global systems integrator. Best fit: multi-year estates with heavy governance. Typical failure: junior staff doing the work after the pitch team leaves.
• Boutique specialist. Best fit: a defined migration or modernisation. Typical failure: thin cover if the one expert you met is unavailable.
• Software vendor consulting arm. Best fit: adopting that vendor's product. Typical failure: architecture shaped around the vendor's roadmap.

None of these is wrong. The mistake is hiring one for the job another type does better. A buyer who needs a single well-scoped migration and hires a global integrator pays for governance layers they do not need. A buyer with a sprawling regulated estate who hires a two-person boutique carries the opposite risk.

A checklist to take into every sales call

Each question below is explained in the sections that follow, so you can use this list as a quick reference when comparing proposals.

• Payment: How are you compensated by the cloud provider, and does that affect your sizing advice?
• Landing zone: Who designs it, can you show an example, and who owns the infrastructure code?
• Migration: Which applications would you put in each of the seven migration buckets, and why?
• Cost: How would you find and cap data transfer charges and idle non-production environments, and can you show a past cost report with the client's name removed?
• Security: Which side of the shared responsibility line does each control sit on, in writing?
• Operations: Who is on call at 2am, what do the runbooks cover, and does the build team stay involved?
• References: Can I speak to a client whose system has been live for six months?
• Assessment: What is the price, duration and deliverable of a small assessment, and can I see a sample report?

Ask how the reseller gets paid

Resellers of AWS, Microsoft Azure and Google Cloud often earn part of their income through the provider, for example through partner programmes such as the AWS Partner Network. Their advice can therefore lean toward higher consumption. Ask how they are compensated before you trust a sizing recommendation.

This is not an accusation. Many resellers give honest guidance, and the billing consolidation they offer is useful. But if their revenue rises when your bill rises, you need an independent check on instance sizing, reserved capacity and storage tiers.

A simple test: ask for the smallest configuration that meets your stated load, and the reasoning. A good adviser will give you one and explain what breaks if traffic doubles. A weak one will answer with the largest tier on the price list.

Judge the firm by its landing zone design

A landing zone is the account structure, network layout, identity setup and guardrails that every workload will sit inside. Ask who designs it and see an example, because mistakes here are expensive to undo later.

AWS documents its approach in the Control Tower landing zone guidance, and Microsoft publishes an equivalent in the Azure Cloud Adoption Framework. A competent consultant can walk you through either without slides.

Look for separate accounts or subscriptions for production and non-production, central logging, and identity federation with your existing directory. If a firm proposes putting everything in one account "for now", expect a painful re-platforming within a year.

Ask also who owns the infrastructure code. It should live in your repository, not theirs.

Migration strategy decides the bill

Rehosting moves a workload unchanged and is fast. Refactoring rewrites it for the cloud and is slow. Many programmes end up mixing both, and a consultant who defaults to only one is selling their preference.

AWS describes the options as the seven common migration strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor. Ask which applications the firm would put in each bucket and why.

The trade-off is plain. Lift-and-shift gets you out of a data centre quickly but carries over every inefficiency, so you often pay more to run it. Refactoring cuts run costs but delays the date you leave the old estate.

A sound migration starts with a sorting exercise: list every application, record its dependencies and traffic pattern, and assign it to one of the seven buckets with a written reason. The bucket each application lands in drives the schedule more than any tool, so ask any firm, including ours, to show that list before it quotes dates. Our cloud migration service is one place to see how that sorting works in practice.

Data transfer and idle environments: the two costs nobody quotes

Data transfer out of the cloud and idle non-production environments are the two charges that most often surprise teams after go-live. Ask any firm you are considering how they would find and cap both.

In our experience, egress is rarely in the headline estimate. Development and test environments left running overnight and at weekends can add up to more than the team expects.

The AWS Cost Optimization pillar covers tagging, budgets and rightsizing in detail, and the same ideas apply on Azure and Google Cloud.

Ask the consultant to show a cost report from a past engagement, with the client's name removed. You want to see spend broken down by team or service, plus alerts that fire before the invoice does. A firm without one probably does not run this discipline for itself.

Security: where responsibility splits between provider and consultant

The cloud provider secures the underlying infrastructure, and you secure what you put on it. A consultant should state in writing which side of that line each control sits on for your project.

AWS explains the split in its shared responsibility model, and the other major providers publish close equivalents. The practical gaps appear in identity and access, operating system patching on virtual machines, and logging.

Ask four concrete things: who creates and reviews IAM roles, who patches, where audit logs go, and who is paged when one is tampered with. If the answer to the last question is "the client", find out whether the client knows that.

For regulated work, add the compliance regimes you are bound by and ask for experience with the specific audit, not a general claim of familiarity.

Operations after go-live separates the firms

Many firms are strongest at the migration and thinnest on running what they built. Ask who is on call at 2am, what the runbooks cover, and whether the team that built the system stays involved.

Handover is a legitimate model. You hire a consultant to build, then your own team runs it. But that only works if the documentation, alerting and deployment pipeline are finished before they leave.

If you want ongoing cover, check the time-zone overlap between your team and theirs, and ask which hours are staffed by engineers rather than by a ticket queue. A firm that cannot name the hours it covers is not offering cover.

For the build-and-run side, DevOps consulting covers pipelines, monitoring and on-call practice.

Reference calls: speak to a client six months after go-live

Reference calls taken at launch tell you little, because everyone is relieved. Ask for a client whose system has been live for at least six months, when the first real bills, incidents and handover gaps have shown up.

Ask what broke, how quickly the firm responded, and whether the final cost matched the estimate. Ask whether the people named in the proposal did the work.

Longevity is a fair signal here, but only if it is checkable, so ask every firm to name the clients it has permission to name and to put you in touch with an engineer who worked on the project.

Be wary of references limited to logos. A named engineer you can speak to is worth more than ten brand names on a slide.

Start with a small paid assessment

A short, fixed-scope assessment before the full programme lets you test a firm's thinking at low risk. It should produce a workload inventory, a recommended migration path per application, and the risks they see.

Scoping is normally done per project after a discovery call, so any firm quoting a programme figure without one is guessing. The assessment is where that guess becomes a plan. Ask for its price, duration and deliverables in writing before it starts, and for a sample of the report it produces, so you know what you are buying.

If the migration is part of a bigger rebuild, system modernisation work may need to run alongside it. If you lack senior technical leadership to evaluate any of this, a fractional CTO can sit on your side of the table during selection.

Sometimes the assessment shows that the pain is not hosting at all, but a manual process that keeps failing whatever it runs on. Moving that process unchanged only relocates the failure, so if your inventory turns up a workflow like that, book a broken workflow assessment to map and fix it before you migrate it.

Pick the firm that has run your workload

Choose the firm that has already operated a system shaped like yours, with similar traffic, data volume and compliance load. Then check them on landing zone, migration choices, cost reporting and who answers the pager.

Size matters less than that match. A large integrator that has never run your kind of workload will learn on your budget. A small team that has will tell you early where the plan is weak.

If you want a second opinion on a proposal you already hold, send it through the contact form and we will mark up where the scope, security split or cost controls are thin. That review is worth doing before signature, since changing a landing zone afterwards means rebuilding what sits on top of it.