Hiring the wrong cloud consulting partner is expensive in a way that’s easy to underestimate.
It’s not just the invoice. It’s the quarter you lose.
It’s the migration that has to be redone. It’s the internal team that inherits a mess nobody documented.
This is a checklist, not a sales pitch. Some of it will point you toward Obsium, and most of it won’t.
That’s fine. The goal is to help you pick well, whoever you pick.
The short version
If you only read one section, read this one.
- Know why you’re hiring before you start looking. “We need cloud help” isn’t specific enough to evaluate anyone against.
- Ask who’s actually doing the work, not just who’s selling it. The person in the sales call is rarely the person on your project.
- Get pricing in writing, and understand what drives it. Some pricing models quietly reward a worse outcome for you.
- Check for a real exit plan. A good partner makes themselves replaceable. A bad one makes you dependent.
- Talk to a reference, and ask what went wrong. Every project has something. If they can’t name one, that’s the red flag.
The rest of this page walks through each of those in more detail.
Step 1: Get clear on why you actually need help
Before you look at a single vendor, answer this for yourself:
- What specifically can’t your team do right now?
- Is it a skills gap, a time gap, or a “we’ve never done this before” gap?
- Is this a one-time project, or ongoing work?
These answers matter because they point you toward different kinds of help.
| Your situation | What you probably need |
|---|---|
| One big project (migration, a security audit) with a clear end date | A project-based consultant or boutique firm |
| Ongoing work, but you don’t want to hire full-time | A managed service provider |
| You have the skills in-house, just not enough hands | A contractor or staff augmentation |
| You’ve never done this before and won’t do it again soon | A specialist consultant, for this project only |
| You’ll need this capability forever | Hire internally, use a consultant to help you get started |
If you can’t tell which row you’re in, that’s worth figuring out first. A lot of bad engagements start because the buyer skipped this step and let the vendor define the problem for them.
Step 2: Understand the different types of cloud consulting partners
Not all “cloud consulting” companies do the same thing. Here’s a quick breakdown.
| Type | Good for | Watch out for |
|---|---|---|
| Large global consultancy (Accenture, Deloitte, etc.) | Large enterprises, complex compliance needs, big budgets | High cost, junior staff doing the actual work, slow to start |
| Cloud provider’s own consulting arm (AWS ProServe, Google Cloud Consulting) | Deep platform expertise, credibility with your leadership | They’ll usually recommend more of that provider’s services |
| Boutique / specialist firm | Deep expertise in one area (Kubernetes, cost optimization, a specific migration) | Smaller team, less bench strength if someone leaves |
| Reseller / MSP | Ongoing support, single point of contact for billing | May earn margin on your cloud spend, which can bias their advice |
| Independent contractor | Cheapest option, direct access to the person doing the work | No backup if they’re unavailable, no institutional continuity |
None of these is automatically the right or wrong choice. The mismatch happens when the type doesn’t fit the job.
A boutique Kubernetes specialist is a poor fit for an enterprise-wide compliance overhaul. A global consultancy is often overkill, and overpriced, for a single cluster migration.
Step 3: The actual checklist
This is the core of the page. Work through it with any partner you’re seriously considering.
Technical fit
- ☐ They’ve worked with your specific cloud provider (AWS, Azure, GCP) before, not just “cloud” in general.
- ☐ They’ve worked with your specific technology, if it’s specialized (Kubernetes, a particular database, a legacy system you’re moving off of).
- ☐ They can explain, in plain terms, how they’d approach your specific problem, not just their general methodology.
- ☐ They ask you hard questions in the first conversation, instead of just agreeing that everything you want is a great idea.
Track record
- ☐ They can show you real, verifiable client work, not just logos on a website.
- ☐ Any certifications they claim (like an AWS or Azure partner tier) are checkable on the provider’s own partner directory.
- ☐ They’ll give you a reference at a similar size and complexity to your company, not just their biggest, most polished client.
- ☐ When you talk to that reference, they’ll tell you something that didn’t go perfectly.
Who’s actually doing the work
- ☐ You know the names of the specific people who’ll be on your project, not just the name of the firm.
- ☐ You’ve confirmed those people will still be on your project in month three.
- ☐ The people who showed up to the sales call are the same people (or close to it) who’ll do the hands-on work.
This one matters more than most buyers expect. It’s common for senior people to run the sales process, then hand the actual work to a more junior team. Ask directly who will be doing what.
Pricing and incentives
- ☐ You understand exactly how they’re paid: fixed fee, hourly, retainer, or a percentage of savings.
- ☐ If any part of their fee depends on results (like “we save you money”), you know exactly how that’s measured, and by whom.
- ☐ You’ve asked whether they earn any commission, margin, or rebate tied to your cloud spend or to specific tools they recommend.
- ☐ The pricing is in writing, with a clear scope, before work starts.
A quick note on that third point, because it’s easy to miss. Some consulting firms are also resellers of cloud services or specific software.
If a firm earns a percentage of what you spend on AWS, or gets a kickback for recommending a particular monitoring tool, that’s not automatically a dealbreaker.
You should still know about it. Factor it into how much you trust their “unbiased” recommendations.
Communication and fit
- ☐ They communicate in plain language, not buzzwords, when explaining technical decisions to you.
- ☐ You’ve agreed on how often you’ll talk, and through what channel (a shared Slack channel is very different from a monthly status email).
- ☐ Their working hours reasonably overlap with yours, especially if they’re in a different time zone.
- ☐ Someone on your team has a direct line to someone on theirs, without going through account management first.
The exit plan
- ☐ They’ve told you, upfront, what “done” looks like for this engagement.
- ☐ They’ve agreed to document what they build, so your team can maintain it without them.
- ☐ They’ve named who on your team will own this after they leave.
- ☐ Nothing about their pricing or tooling locks you into needing them indefinitely.
This last point is the one worth thinking hardest about. Some consultants build things that are quietly hard to maintain without them, whether on purpose or not.
A good partner wants to make themselves replaceable. Ask directly: “What happens if we want to end this engagement in three months?”
A vague answer is a signal.
Green flags vs. red flags
A quick-reference version of everything above.
| Green flags | Red flags |
|---|---|
| Asks detailed questions about your setup before quoting a price | Quotes a price or timeline before understanding your environment |
| Names the specific engineers who’ll work on your project | Only talks about “our team” in the abstract |
| Gives you a reference where something went wrong, and how they handled it | Only offers their best-case success stories |
| Explains pricing and any conflicts of interest clearly, in writing | Pricing is vague, verbal, or “we’ll figure it out as we go” |
| Talks about handing the work back to your team | Every conversation steers toward a longer engagement |
| Comfortable saying “you don’t need us for that part” | Recommends buying or building everything through them |
| Certifications are checkable on the provider’s own site | Certifications and claims can’t be verified anywhere |
Questions to ask on the first call
Ask these directly. How someone answers tells you as much as what they say.
- Who specifically will work on our project, and what have they built before?
- Can you walk me through a project that didn’t go as planned, and what you did about it?
- How exactly are you paid, and does any of that depend on what we spend elsewhere?
- What would you recommend we do ourselves, without hiring you?
- What does a successful handover look like, and when would that happen?
- Can I talk to a client where the engagement is now over?
- What happens if we need to pause or end this early?
If a question makes someone visibly uncomfortable, pay attention to that. The honest answer to most of these questions is rarely a perfect one, and that’s fine. What matters is whether they’ll give you a straight answer at all.
What cloud consulting actually costs
Pricing varies a lot depending on scope, so a single number isn’t very useful. But here’s the general shape of it.
| Pricing model | How it works | Best for |
|---|---|---|
| Fixed fee | One price for a clearly defined project | Well-scoped, bounded work (a migration, an audit) |
| Hourly / time and materials | You pay for hours worked, no fixed cap | Exploratory work where the scope isn’t fully known yet |
| Monthly retainer | A recurring fee for ongoing support | Long-term or open-ended engagements |
| Percentage of savings | They’re paid a cut of what they save you | Narrow, well-defined cost-optimization work only |
A general rule of thumb: the more clearly you can define what “done” looks like, the more you should push for a fixed fee. Open-ended pricing works best when the scope genuinely can’t be known upfront, not as a way to avoid committing to a number.
Where Obsium fits
We’re a cloud consulting partner that focuses on Kubernetes, DevOps, and observability, mostly for teams that have outgrown a do-it-yourself setup but don’t want to hand everything over to a giant consultancy.
We’d rather lose a deal than take on work we’re not the right fit for. If your problem is a compliance-heavy enterprise rollout across a dozen business units, we’ll tell you that honestly and point you somewhere else.
If it’s Kubernetes cost, observability, or DevOps work, book a free 30-minute call. No sales deck. We’ll tell you plainly whether this is something we’re a good fit for, or whether you’re better off elsewhere.
Related reading: FinOps consulting: what to look for · Top AWS consulting companies · Top Azure consulting companies · Should you hire a DevOps engineer or a consultant
FAQ
How do I know if a cloud consulting company is legit?
Check their claimed certifications against the cloud provider’s own partner directory (AWS, Azure, and Google Cloud all publish these). Ask for a reference and actually call them. A company that can’t produce a verifiable client or certification is worth being cautious about.
Should I hire a cloud consultant or just hire someone in-house?
Depends on whether you’ll need the skill ongoing. A one-time project (a migration, a security review) usually makes more sense as a consulting engagement. A capability you’ll need permanently is usually cheaper to build in-house over time, with a consultant helping you get started.
How much does a cloud consulting partner cost?
It depends heavily on scope, company size, and whether you’re hiring a boutique firm or a large consultancy. Ask for pricing tied to a specific, defined outcome rather than a general day rate, so you can actually compare quotes.
What’s the difference between a cloud consulting partner and a reseller?
A reseller sells you cloud capacity (and often earns margin on it). A consulting partner is meant to be paid for advice and implementation work. Many companies are both, which isn’t automatically bad, but it’s worth knowing which hat someone is wearing when they make a recommendation.
What questions should I ask a cloud consulting partner before signing?
At minimum: who’s actually doing the work, how they’re paid, what happens if things don’t go as planned, and what the exit plan looks like. The full list is above.
Is it normal for the sales team and the delivery team to be different people?
It’s common, but you should know about it upfront. Ask specifically who will be hands-on with your project, and make sure that’s someone you’ve actually spoken to before signing.
