DevOps as a service covers four genuinely different engagements, and most disappointing contracts come from buying one while needing another. A team that wanted pipeline automation ends up paying for a transformation programme, or a team that needed cultural change buys tooling support and wonders why nothing improved.
This guide separates the four models, gives you the questions that expose which one a vendor is actually selling, and sets out what belongs in the contract.
The four engagement models
"DevOps as a service" is a category, not a product. Before comparing vendors, decide which of these you are buying.
Automation is bounded work with a deliverable: pipelines built, infrastructure coded, deployments automated. You can define done.
Managed service is ongoing operation. Someone runs your pipelines, monitoring and environments so your engineers do not. Done never arrives, which is the point.
Support is reactive. You keep ownership, and you buy expertise for incidents and escalations.
Transformation changes how your teams work. Tooling is a side effect. This is the longest, most expensive and most frequently mis-sold of the four.
The commonest mismatch: buying transformation when you needed automation. Transformation engagements are priced on programme length and produce strategy documents. If your actual problem is that deployments take four hours and break, you wanted automation and you can measure whether you got it.
What to ask before you shortlist
Four questions separate vendors who will do the work from vendors who will describe it.
- Who owns the pipeline at the end? If the answer involves their proprietary platform, you are renting capability, not building it. That can be a reasonable trade, but it must be a decision rather than a discovery.
- What happens when we leave? Ask for the exit process in writing. Infrastructure as code in your repositories, under your version control, is the answer you want.
- Which engineers, specifically? Named people with named certifications, not a pool. The gap between the pre-sales engineer and the delivery engineer is where most dissatisfaction originates.
- Show me a runbook you wrote for a client of our size. Redacted is fine. A vendor who cannot produce one has been selling strategy, not operations.
Pricing models and what each one hides
Every model has a failure mode. Fixed scope encourages narrow interpretation of the scope. Time and materials encourages slow progress. Dedicated team encourages filling seats. Outcome-based sounds ideal and founders on defining the outcome precisely enough to measure.
The practical answer for most mid-sized buyers: fixed scope for a bounded first project, then a dedicated team or managed service once you know how the vendor actually works. Do not sign a multi-year managed contract with a vendor you have never delivered with.
What the contract must say
Six clauses that are cheap to add now and expensive to be missing later.
- Deliverable definition in artefacts, not outcomes. "Working CI/CD pipeline" is unenforceable. "Pipeline in our GitHub Actions, building, testing and deploying to staging on merge, with documented rollback" is.
- Infrastructure as code in your repositories. Not theirs, not a shared drive, from day one rather than at handover.
- Named escalation path with response times. Severity levels defined in the contract, not in a support portal that changes.
- Knowledge transfer as a scheduled deliverable. Sessions with dates, and documentation reviewed by your engineers, not a final-week handover.
- Exit assistance. A defined number of days of transition support at agreed rates, written before you need it.
- Security and access boundaries. Which environments, which credentials, and how access is revoked when a named engineer rolls off.
Measuring whether it worked
Agree the baseline before the engagement starts. Measuring after the fact means arguing about what the numbers were.
These four are the DORA metrics, and they are useful because they resist gaming individually. Deployment frequency alone rewards shipping trivial changes. Paired with change failure rate, it rewards shipping safely and often.
Take the baseline in the first week, with the vendor present and agreeing the figures. A baseline collected afterwards is a negotiation.
Evaluating the vendors on your shortlist
Once you know which model you are buying, the comparison gets easier, because you are judging one kind of capability rather than four.
Ask for the delivery team, not the company. Vendor case studies describe organisations. You are buying three or four specific engineers. Ask who they are, what else they are assigned to, and what happens if one leaves mid-engagement. A vendor unwilling to name people is telling you the team is not allocated yet.
Check their default toolchain against yours. Every vendor has a stack they are fastest in. If they build everything in Jenkins and you run GitHub Actions, you will either pay for their learning curve or inherit a tool nobody on your team wants. Neither is fatal, both should be priced in.
Ask what they would refuse to do. A vendor who agrees with every request is selling availability rather than judgement. The useful answer sounds like "we would not automate that deployment until the tests are reliable, because you would be shipping failures faster."
Talk to a reference whose engagement ended. Current clients are a filtered sample. The client who finished and did not renew will tell you what the handover was actually like, which is the thing you cannot assess from inside a sales process.
Running the first ninety days
The early weeks decide whether the engagement produces work or documents.
Week one: baseline and access. Capture the four metrics below with the vendor present, and resolve environment access. Access delays are the commonest cause of a slow start, and they are entirely within your control.
Weeks two to six: one artefact that runs. Insist the first deliverable is something executable rather than a plan. One pipeline, for one service, deploying to one environment. It proves the vendor can work inside your constraints and exposes integration problems while the contract is still young.
Weeks six to twelve: widen and transfer. Extend to further services, and start knowledge transfer in parallel rather than saving it for the end. Handover deferred to the final fortnight is handover that does not happen.
If nothing executable exists by week six, that is your signal. It is far cheaper to have that conversation at six weeks than at six months.
Where these engagements go wrong
The failure modes are consistent enough to list.
Tooling replaces practice. A pipeline is built, nothing else changes, and deployment frequency does not move because approval still takes three days. The bottleneck was process, and a tool cannot fix process.
The vendor becomes the dependency. Every change needs a ticket to them. This is comfortable for the vendor and expensive for you. Knowledge transfer written into the contract is the defence.
Scope defined as activity. "Implement DevOps best practices" cannot be delivered or disputed. Define artefacts.
No baseline. Six months in, nobody can say whether it improved, so renewal is decided on the relationship rather than results.
Choosing between the four
If your deployments are slow and manual, buy automation and measure lead time.
If you have no platform engineers and do not want to hire any, buy a managed service and check the exit terms carefully.
If you have a capable team that occasionally hits problems outside its expertise, buy support and keep ownership.
If your engineering organisation genuinely works in silos and releases quarterly, you need transformation, and you should expect it to be slow, expensive and mostly about people.
Buy the smallest engagement that addresses your actual bottleneck. You can always expand the scope; unwinding an oversized contract is harder.
If you want to talk through which of the four fits your situation, our DevOps services cover automation, managed operations and transformation.