.jpg)
Six months into the “modernization program,” the slide deck looks fantastic. The architecture diagrams are cleaner, the cloud bill is higher, and the team is now experimenting with microservices, Kubernetes, and AI-assisted coding. Yet outages feel more chaotic, releases still bunch up before quarter-end, and nobody can say with confidence whether delivery performance has actually improved.
This gap between activity and progress is where many transformations quietly stall. New tools and platforms create a sense of momentum, but the underlying delivery system barely moves. DORA metrics are designed to cut through that illusion. Instead of measuring busyness, they measure whether software delivery is getting faster, safer, and more reliable over time. When a modernization project is stuck, DORA makes it painfully obvious.
What Modernization Looks Like When It’s Actually Stuck
Stalled modernization rarely looks like failure on the surface. The team has adopted cloud services, CI pipelines exist, maybe there’s even a shiny new platform squad. Yet the experience of shipping software feels the same: long lead times, high stress around releases, and a growing list of “temporary” workarounds that never seem to go away.
One reason leaders miss the stall is that they track project outputs instead of flow. They count number of services migrated, tools adopted, or tickets closed. All of that can trend upward while real delivery performance is flat or declining. A 2023 survey showed that only 23% of respondents were tracking all four DORA metrics, with another 17% tracking three in their DevOps practice. That leaves a majority flying partially blind just as their systems become more complex.
Modernization without measurement leads to a familiar pattern. Teams do more work, but can’t prove outcomes. Engineers feel overloaded, but leadership sees investment and wonders why value isn’t obvious yet. DORA metrics break this stalemate by making the health of the delivery system visible in a way that both engineers and executives can understand.
What are DORA metrics?
For years, measuring engineering performance was an exercise in ambiguity. Leaders relied on "vanity metrics" like lines of code written, hours worked, or number of tickets closed—numbers that track activity but not value. Today, the industry standard for measuring software delivery performance is the DORA framework.
Developed by Google Cloud’s DevOps Research and Assessment team after analyzing years of data from thousands of organizations, DORA metrics move beyond individual output to measure the performance of the entire system. They answer two fundamental questions: How fast can we deliver value? and How stable is that value when it reaches customers?
The framework consists of four key metrics, split between velocity and stability:
Velocity Metrics (Speed)
- Deployment Frequency: How often does the organization successfully release to production? High performers deploy on-demand (multiple times per day), while low performers may deploy monthly or yearly. In a legacy context, moving from "quarterly releases" to "weekly releases" is a massive signal of reduced friction.
- Lead Time for Changes: How long does it take for a code commit to go from a developer's workstation to running successfully in production? This measures the efficiency of your CI/CD pipeline and approval processes. Long lead times usually indicate manual handoffs, brittle testing, or bureaucratic bottlenecks.
Stability Metrics (Quality)
- Change Failure Rate: What percentage of deployments cause a failure in production (e.g., service impairment, outage, or immediate rollback)? This metric reveals the quality of the testing and review process. A low failure rate means the team trusts their automation.
- Mean Time to Recovery (MTTR): When a service incident or defect occurs, how long does it take to restore service? This measures operational resilience and observability. Legacy systems often suffer from high MTTR because debugging requires sifting through obscure logs or waiting for specific experts to come online.
Why DORA Metrics Cut Through the Noise
DORA metrics focus on four core signals: how often teams deploy, how quickly they move changes from code to production, how often changes cause problems, and how fast they recover when things break. These signals are surprisingly powerful. They compress a huge amount of delivery complexity into a small, interpretable set of numbers that correlate with both engineering and business performance across many kinds of organizations.
Deployment Frequency
Deployment frequency is the heartbeat of a delivery system. High-performing teams deploy code on demand 208 times more frequently than low performers according to comparative DevOps research. That kind of gap doesn’t just mean “more releases.” It represents smaller batch sizes, more continuous learning, faster feedback, and less pressure on any single deployment event.
Lead Time for Changes
Lead time for changes measures how long it takes for a code change to reach production after it’s committed. When modernization is working, lead time tends to shrink: automation replaces manual gates, environments become easier to provision, and integration pain is reduced. When modernization is just renaming the old problems, lead time barely moves-or even lengthens-because new complexity is added without simplifying the underlying delivery path.
Change Failure Rate
Change failure rate tells you what percentage of production changes result in incidents, rollbacks, or hotfixes. Many teams assume that deploying more often will be riskier, but the opposite usually happens when practices improve. Smaller changes are easier to reason about and roll back. DORA data across environments and frameworks has shown that these metrics stay meaningful even when applied to very different software development life cycles, as demonstrated by a study of 304 popular open-source repositories that evaluated DORA-style indicators at scale.
Time to Restore Service
Time to restore service, sometimes called mean time to restore (MTTR), reflects how quickly the team can diagnose and fix an incident. Shorter recovery times usually come from good observability, clear on-call practices, and the ability to roll forward or roll back safely. Long recovery times often reveal brittle architectures, unclear ownership, or environments that are difficult to reproduce. MTTR is particularly revealing in modernization efforts because new platforms often promise resilience but initially introduce new classes of failure.
When these four metrics are tracked consistently, they form a kind of narrative. Deployment frequency and lead time show whether the team can move quickly. Change failure rate and time to restore show whether that speed is sustainable. A stalled modernization almost always leaves fingerprints across this narrative: gains in one metric offset by regressions in another, or no clear movement at all despite large investments.
Patterns That Signal a Stalled Modernization
DORA metrics don’t just provide numbers; they reveal patterns that tell a story about where modernization is stuck. One common pattern is “new stack, old cadence.” The team moves to containers, service meshes, and feature flags, but deployment frequency is unchanged. Releases are still scheduled as big events, only now they involve more moving parts. In this story, modernization has focused on platform technology, not delivery behavior.
Another pattern is “automation without acceleration.” CI/CD tools are in place, pipelines run on each commit, and dashboards show lots of green checks. Yet lead time for changes remains long because code still waits in queues for manual approvals, test environments are scarce, or cross-team dependencies delay integration. The pipeline exists, but the organization hasn’t redesigned its process to take advantage of it.
A third pattern is “speed at the expense of stability.” Deployment frequency and lead time improve, but change failure rate climbs and time to restore service stretches out. Often this happens when teams rush to ship on a new platform without investing in observability, release strategies, or error budgets. On paper, the modernization is delivering faster. In reality, customers experience more disruption, and engineers experience more burnout. DORA makes this tradeoff visible instead of letting it hide behind vanity metrics about velocity or story points.
Reading Your Own DORA Story: Practical Examples
Consider a team migrating a legacy monolith to a microservices architecture. Initially, deployment frequency drops, because every deployment feels high-risk and involves both old and new systems. That short-term dip can be expected. But if, months later, deployment frequency remains low and lead time for changes is increasing, the metrics are signaling that the new architecture has added complexity without delivering flexibility. Perhaps service boundaries are unclear, or teams own “components” instead of real business capabilities, leading to coordination bottlenecks.
In another scenario, an organization introduces trunk-based development and feature flags as part of its modernization. Lead time for changes shrinks and deployment frequency rises as small changes regularly hit production with flags turned off. However, change failure rate barely improves. DORA exposes that the team has focused on integration and release, but not on quality practices like meaningful automated tests, canary releases, or proper observability. Without those, incidents remain frequent even though the mechanics of delivery are better.
A third example involves a platform team building an internal developer platform. Adoption looks good-more services onboard every month-but engineers still complain that “nothing is actually faster.” DORA metrics validate that experience: lead time for changes is flat, and time to restore service has even worsened as teams learn unfamiliar tooling during incidents. That story suggests the platform is optimized for standardization or cost rather than developer flow and operability. It doesn’t mean the platform should be abandoned, but it does mean the modernization strategy needs to re-center on outcomes instead of infrastructure alone.
Using DORA Metrics to Restart a Stalled Transformation
Once a stall is visible in the metrics, the next step is to use them as a compass, not a scoreboard. The point is not to “hit a number” but to understand what is constraining flow and resilience. For many organizations, the fastest wins come from tightening the connection between version control and deployment automation. Research from the DORA program has shown that organizations combining version control with continuous delivery are 2.5 times more likely to achieve high software delivery performance compared with those that do not. That finding reinforces a simple idea: if code is hard to move from commit to production, modernization will always struggle.
Another powerful lever is culture. High-trust, low-blame environments consistently show better organizational performance in DORA’s longitudinal studies. From a metrics perspective, that kind of culture makes it safer to deploy more often, report incidents honestly, and experiment with new practices. When engineers fear punishment for outages, they naturally batch more changes, hide near misses, and resist experimentation-all behaviors that push DORA metrics in the wrong direction, no matter how modern the tooling stack appears.
Finally, DORA metrics become most valuable when they’re owned by teams, not just reported to leadership. Teams that regularly review their own deployment frequency, lead time, change failure rate, and time to restore can link them to very specific obstacles: a flaky test suite, a brittle shared library, a manual approval board that adds days of waiting. Each obstacle becomes a candidate for improvement work with a clear expected impact on at least one metric. Over time, that feedback loop turns modernization from a top-down program into a continuous, team-driven practice-and makes it much harder for a transformation to stall without anyone noticing.
Breaking the Stall: From Metrics to Momentum
DORA metrics are powerful because they reveal the truth: your modernization effort might be moving, but it isn’t improving. When the data shows high lead times and stagnant deployment frequency despite months of investment, the problem usually isn’t a lack of tools—it’s a lack of focused execution.
This is the specific gap addressed by Control. Instead of adding more dashboards or re-planning the roadmap, Control deploys a specialized, AI-native team to unstick the specific engineering bottleneck holding your metrics back. By fixing one critical blocker at a fixed price, you turn "stalled" into "shipped," proving that your delivery system can actually improve before you commit to the next phase of transformation.
