DevOps transformation: Operating model, roadmap and metrics
Contents
A DevOps transformation is an operating-model change: teams own software from commit to production, and delivery is measured by outcomes, not tool adoption. Pipelines, infrastructure as code and platforms are the means, not the goal.
The work spans team structure, the delivery pipeline, security placement and measurement, and it only holds when a baseline exists before the first pilot. How much of it you need depends on where release pain sits today: handoffs, environments, test cycles or approvals.
DevOps transformation in brief: What changes and what does not
A DevOps transformation works when the team that writes a service also ships and runs it through one automated CI/CD pipeline. Tools alone leave lead time unchanged if releases still wait on a ticket queue or a separate operations handoff.
Netguru builds cloud infrastructure, CI/CD pipelines and platform tooling for product teams, and we recommend baselining DORA metrics before buying anything, because the baseline shows whether approvals, test time or deploy risk is the constraint. Organizations with mandatory change boards should redesign approvals first.
Teams that already deploy on demand with a low change failure rate need platform work, not a transformation. Where in-house capacity is the bottleneck, a dedicated engineering team can own the pipeline and platform work while your product teams keep shipping.
What changes in team structure and operating model
Team structure changes in one direction: stream-aligned product teams own their services from commit to production, while platform engineering and site reliability engineering support them without taking over operations. Team Topologies gives the vocabulary for this split, and roles keep shifting as a project matures, which our web development team structure guide follows stage by stage.
A separate "DevOps team" sitting between development and operations recreates the handoff the transformation set out to remove. It becomes one more queue, with its own backlog and its own on-call rota for code it did not write.
The rule that keeps ownership honest: whoever merges a change owns it through deployment, on-call and incident review. The platform team owns the paved road (pipeline templates, infrastructure as code modules, the golden path) and does not own the services running on it.
Three models fit different organization sizes. The team counts below are our judgment, not a benchmark:
| Model | Favored when | Main risk |
|---|---|---|
| Champions inside product teams | Fewer than about 5 teams; no budget for dedicated platform staff | Champion work becomes a part-time side task and stalls when one person leaves |
| Central platform team | Roughly 5-15 teams sharing a similar stack | The team turns into a ticket queue unless it ships self-service and treats developers as customers, as the CNCF Platforms White Paper advises |
| Embedded SRE | A handful of tier-1 services with explicit SLOs and error budgets | SREs are scarce, and reliability knowledge stays with them instead of spreading to the team |
In our view, past about 15 teams the last two models work best combined: a central platform team builds the road while a small SRE group consults, sets SLO practice and embeds temporarily on the services that burn through their error budgets.
We recommend starting with champions drawn from the pilot teams, then forming a platform team of two or three engineers once a second and third team need the same pipeline. The baseline DORA metrics tell you when that moment has arrived.
In regulated environments, separation-of-duties rules may seem to demand a distinct release team. Policy as code and mandatory pipeline approvals usually meet the control without one. If you want help sizing the platform group, our DevOps services start from that question.
DevOps transformation roadmap: Phases, owners and exit criteria
A DevOps transformation roadmap has five phases (assess, baseline, pilot, standardize, scale to self-service), and each one closes when a named owner shows a measured exit criterion. Installing a tool does not close a phase.
Value stream mapping opens the work and an internal developer platform is where it ends up, and in a company-wide program these five phases sit inside the larger digital transformation lifecycle.
The baseline comes before any pilot, and it needs no new tooling. Pull deployment frequency from release or pipeline logs, and lead time for changes from commit timestamps to production deploys. Derive change failure rate by matching deploys to rollback, hotfix and incident tickets, and time to restore from incident open and close times, which together make up the DORA four keys.
Each phase with its owner and exit criterion:
| Phase | Owner | Exit criterion |
|---|---|---|
| 1. Assess | VP Engineering with a platform lead | Value stream map of two or three representative services, with wait time shown at each handoff, and a pilot team chosen |
| 2. Baseline | Engineering manager of each pilot team | Four DORA metrics plus one SLO-based reliability measure per service, from 90 days of deploy logs and tickets, agreed by the team |
| 3. Pilot | Pilot team's tech lead | One service ships through an automated CI/CD pipeline with infrastructure as code, and lead time and change failure rate beat baseline for two consecutive quarters (an illustrative target, not a benchmark) |
| 4. Standardize | Platform engineering lead | The pilot path packaged as a golden path with templates, policy as code and SBOM generation, and two more teams adopt it without hands-on help from platform engineers |
| 5. Scale to self-service | CTO sponsor and platform product owner | A new service reaches production through the internal developer platform with no ticket, teams adopt it voluntarily, and DORA metrics are reported across the organization |
Choose the pilot team for its representativeness. A team with a typical stack, a real release cadence and a supportive manager gives you results other teams will believe. A greenfield team's results will be dismissed as a special case.
Where logs are incomplete, hand-sample the last 90 days of releases and treat the baseline as approximate. Organizations under roughly 50 engineers can often merge phases 4 and 5, since one platform engineer can cover both.
Where to start and which teams go first
Pick the service with the worst release pain, owned by a team that asked for the change, and scale only after its metrics beat baseline for two consecutive quarters. The easiest service proves nothing, because a small greenfield app would have shipped quickly with or without a new pipeline.
Three tests narrow the candidates:
- Real release pain. The value stream mapping exercise shows a long queue between merge and production, such as a manual approval or a weekly release window. The pilot exists to remove that wait.
- High change volume. The team merges often enough for a trend to show within a quarter. A service deployed twice a year produces no signal.
- A willing owner. One engineering manager agrees to change branching and review habits. Trunk-based development is usually the first of those changes, and it fails when imposed on a team that did not choose it.
We suggest the following scale trigger as a rule of thumb, not a benchmark. Move to the next teams when the pilot beats its own baseline on deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time for two consecutive quarters. A single good quarter can come from a seasonal lull or a one-off push.
The rule bends with size. With only four or five teams in the company, two quarters of waiting may cost more than it protects, so compare against baseline after one and widen the pilot to a second team.
DORA metrics for measuring DevOps transformation
DORA metrics measure a DevOps transformation through four delivery measures plus reliability, and each one misleads when read alone. Track them per service, against the baseline you set during assessment, and read them as pairs.
| Metric (older name) | Definition | Bad reading signals |
|---|---|---|
| Deployment frequency | How often a service ships to production | Frequency rises while change failure rate rises with it; config and docs deploys inflate the count |
| Lead time for changes | Time from first commit to running in production | Clock starts at merge, so review queues and waiting tickets stay invisible; the median falls while the slowest changes get slower |
| Change failure rate | Share of deployments that need a hotfix, rollback, or patch | Rate looks low because incidents are not tagged to a deploy, or because teams ship less often to protect it |
| Failed deployment recovery time (formerly time to restore service) | Time to recover from a failure a deployment caused | A mean skewed by one outlier; incidents closed in the tracker before users recover |
| Reliability | Attainment of service level objectives (SLOs) | SLOs that are never missed because targets are loose; an error budget that is never spent |
The State of DevOps report renamed time to restore service as failed deployment recovery time in 2023, narrowing it to failures a deployment caused. The 2024 report added rework rate next to change failure rate as a second stability measure.
Reliability entered the research in 2021 as an operational measure that sits beside the delivery metrics, and it is judged against your own service level objectives, so it needs a defined SLO per service before it tells you anything.
The pairing matters most: deployment frequency and lead time describe throughput, while change failure rate and recovery time describe stability. A transformation is working when throughput improves and stability holds or improves. If frequency climbs and change failure rate climbs too, the pipeline is moving faster than its tests and gates can verify.
We recommend against team leaderboards. Once a metric is a target, teams game it, so use the numbers to find the constraint your value stream map already pointed at.
What can impede the progress of a DevOps transformation
A DevOps transformation stalls when tools ship but delivery outcomes stay flat. Five failure modes are worth checking first, and each shows up early in DORA metrics or platform usage data. Fixes mostly come down to treating platform engineering as a product, with a golden path that teams choose because it is faster than their own pipeline.
Each failure mode with its early signal and fix:
| Failure mode | Early signal | Fix |
|---|---|---|
| Tool-first rollout | CI/CD pipelines exist, but lead time for changes and change failure rate match the pre-rollout baseline | Run value stream mapping on one service and automate the longest wait first |
| DevOps silo | Product teams file tickets to deploy or to change their own pipeline | Move pipeline ownership into product teams; the platform team supplies the golden path and enablement, not operations tickets |
| No baseline | Leadership reports tool adoption counts; nobody can state last quarter's deployment frequency | Measure all four DORA metrics per service from the last 90 days of deploy logs and tickets before changing anything |
| Legacy constraints | Quarterly release trains, manual change approvals, shared databases that block independent deploys | Start with the service that decouples most easily; replace manual approvals on low-risk changes with automated policy checks |
| Platform without product management | Teams keep their own pipelines (shadow pipelines); golden path adoption stays flat | Assign a platform product manager, interview internal users, and track adoption and time to first deploy |
The last row matters because DORA's 2024 State of DevOps report found that internal developer platforms raise individual productivity but can lower change stability and throughput. For a team building a platform without user research or a feedback loop, that makes the platform the most expensive form of tool-first rollout.
To restart a stalled program, take the baseline first, then match your signals to the table and fix one row at a time. Teams under roughly 50 engineers can usually skip the dedicated platform team and share a small set of templates instead.
Platform engineering: The end state of a DevOps transformation
Platform engineering is the end state of a DevOps transformation: a platform team runs an internal developer platform (IDP) that gives product teams self-service delivery through a golden path. The CNCF Platforms White Paper describes this platform as a product whose customers are the developers who use it.
Our build-vs-adopt rule uses three inputs: team count, existing tooling, and platform staffing. The thresholds are illustrative judgment, not benchmarks.
| Situation | Recommendation |
|---|---|
| Fewer than ~5 product teams, no dedicated platform staff | Adopt managed CI/CD templates and a hosted portal. Skip a custom IDP. |
| ~5-20 teams, CI/CD pipeline and infrastructure as code already standardized | Adopt a portal framework, build only the golden path templates. |
| 20+ teams, 4+ platform engineers and a product owner | Build custom layers on top of adopted components. |
Adopting does not mean free. Backstage, for example, is an open framework for building developer portals, so it still needs engineers to assemble, host, and maintain it. Where in-house capacity is thin, some organizations hand the platform build to a dedicated engineering team while internal staff stay on product work.
Measure the platform with adoption metrics, the way a product team would:
- Share of new services created from the golden path
- Time to first production deploy for a new service
- A quarterly developer satisfaction score
If adoption is mandated to hit the first number, the metric stops telling you anything. Low voluntary use means the path is slower than teams' own pipelines.
Tie the platform back to delivery outcomes as well: track change failure rate and lead time for the teams that consume it, because a platform shipped without product practice can make both worse.
How to build DevOps culture without slogans
DevOps culture comes from three mechanisms that change who carries the pager, how failures get reviewed, and which number development and operations answer to: shared on-call, blameless postmortems, and a shared service level objective (SLO) with an error budget.
- Shared on-call. Developers join the rotation for the services they ship, starting as secondary beside an operations or site reliability engineering (SRE) engineer. Give them runbooks and the authority to change alert thresholds. Pages that no one on the owning team can act on get routed back to that team.
- Blameless postmortems. Hold one for every incident that breaches the SLO. Use a fixed format: timeline, contributing factors, what detection missed, and action items with an owner and a due date. Google's SRE book frames blameless postmortems as assuming everyone involved acted in good faith on the information they had.
- A shared SLO and error budget. Product, development, and operations agree on one SLO per service. The error budget is the permitted unreliability, so an illustrative 99.9% monthly target leaves roughly 43 minutes of downtime. An error budget policy states what happens when the budget runs out, typically a pause on feature releases in favor of reliability work.
Review budget burn weekly next to change failure rate, so reliability and delivery speed sit on one agenda. The rotation needs enough people to be humane; with only a handful of engineers per service, pool related services into one rotation.
Where DevSecOps checks belong: Commit, build and deploy
DevSecOps checks belong at three points in the CI/CD pipeline: secrets detection and fast SAST at commit, SCA and SBOM generation at build, and policy as code at deploy. Each check goes where its runtime fits the wait a developer tolerates at that stage.
Where we recommend each check runs:
| Stage | Checks | Runtime budget (illustrative target, not a benchmark) | Gate |
|---|---|---|---|
| Commit and pull request | Secrets detection, diff-scoped SAST | Under 2 minutes | Blocking |
| Build | SCA, SBOM generation, image scan, build provenance | A few minutes, parallel to tests | Blocking on exploitable, high-severity findings |
| Deploy | Policy as code on manifests, enforced when the GitOps controller reconciles | Seconds | Blocking |
| Scheduled | Full-repository SAST, DAST, deep dependency analysis | Hours | Non-blocking, findings become tickets |
A full-repository SAST run on every pull request is the usual way lead time grows. Developers wait, then learn to rerun or bypass the gate. Scope the commit-stage scan to changed files and move the exhaustive run to a nightly job.
The build stage is where artifact evidence is cheapest to produce. NIST SP 800-218 (SSDF) names SBOMs as one way to keep provenance data for each release, and the SLSA specification defines what build provenance should record. Deploy-stage policy as code with OPA Gatekeeper or Kyverno then rejects non-compliant manifests before they reach the cluster.
This split assumes teams can ship without a pre-release audit. In regulated settings such as medical or financial products, a full scan may have to block release. Run it in parallel with integration tests so it stays off the serial path, and watch lead time for changes in your DORA metrics after each gate you add.
How to choose tooling by pipeline stage
Choose tooling for each CI/CD pipeline stage on three criteria: integration cost, ownership burden, and fit with your existing identity and deploy model. Feature depth comes after those three, because a capable tool that cannot authenticate through your SSO or deploy through your pipeline stalls in adoption.
- Integration cost: engineer-weeks to connect the tool to your identity provider, secrets store, and deploy path, plus the upkeep of that glue.
- Ownership burden: who patches it, upgrades it, and takes the page when it fails. A self-hosted runner fleet and a managed service differ most here.
- Fit: whether the tool supports workload identity (OIDC) and speaks your deploy model, whether that is a GitOps reconciler, Helm, or Terraform.
A worked example makes the cost visible. Assume 12 services and two feature flag candidates. Candidate A has its own user directory, no infrastructure as code provider, and no audit export. Candidate B supports OIDC and has a Terraform provider.
For A, assume 2 weeks for an SSO bridge, 3 weeks to script flag definitions so they stop drifting from the repository, and 1 week for audit export: 6 engineer-weeks, with the bridge yours to maintain afterwards. For B, assume 1 week. All of these are illustrative assumptions, not benchmarks.
A is worth the extra 5 weeks only if it covers a requirement B lacks, such as flag targeting your compliance team has mandated. In regulated environments where the tool is fixed in advance, apply the same three criteria to the glue around it.
Business outcomes, cost drivers and what to look for in a partner
A DevOps transformation pays back in delivery outcomes you can baseline: the DORA metrics of deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. For project managers who need to coordinate these practices across web delivery teams, DevOps project management offers a practical starting point.
The annual State of DevOps report from DORA ties these metrics to organizational performance. For the business case, that makes change failure rate the easiest number to price: every failed change costs rework, incident time, and delayed roadmap work.
Four factors drive cost and duration. The table shows how each one moves the estimate and what to ask about it.
| Cost driver | Effect on cost and duration | Question to ask |
|---|---|---|
| Legacy estate | Systems without automated tests or reproducible environments need remediation before any pipeline pays off | Which systems are excluded from phase one, and why? |
| Team count | Each team needs onboarding and pipeline migration; a golden path flattens this curve | How many teams migrate without custom work? |
| Platform build vs buy | Building an internal developer platform means a standing platform team; adopting one still costs integration | Who owns the platform after handover? |
| Skills | Missing IaC or SRE skills mean backfilling or training | What is hired in, and what is taught? |
We recommend testing a partner on three points:
- Baseline first: they measure your current DORA metrics and map the value stream before proposing tooling.
- Capability transfer: your engineers run the pipeline and platform by a named handover date.
- Outcome metrics: the contract reports against change failure rate and lead time, not tool installs.
A partner that cannot show a baseline in the first weeks is likely to start with tools, and our own DevOps services follow the same order.
These estimates shift with your compliance burden and how much of the estate is already containerized, so ask for ranges tied to assumptions, not a single figure.
DevOps transformation FAQ
What is DevOps transformation?
What is the main goal of a DevOps transformation?
What impedes DevOps transformation progress most?
How does DevOps accelerate digital transformation?
Who offers DevOps transformation consulting?
Will AI replace DevOps?
What are the top 5 DevOps skills?
Start with a baseline of your delivery performance
A DevOps transformation starts with a baseline of your DORA metrics: deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time, plus a reliability measure such as SLO attainment.
Pull them from data you already have: Git history, the CI/CD pipeline, and the incident tracker. We suggest the last 90 days for two or three candidate pilot services, with a value stream map of each to show where changes wait, and recording the numbers per service, since an org-wide average hides the slow ones.
If you want help reading the baseline or choosing the pilot, tell us about your delivery setup and we will go through it with you.
