Strangler Metrics: Proving the Old Path Is Really Dying
A strangler migration needs evidence, not optimism. Track traffic shifted, features live on the new path, and the blockers that keep the legacy system alive.
Definition
Strangler metrics are the indicators that show how much of a legacy system has been replaced, such as the share of production traffic served by the new implementation, the number of features still legacy-only, and the dependencies that keep the old system alive.
Context and scope
Strangler migrations are easy to start and hard to finish; without explicit metrics, the legacy path survives indefinitely as a shadow system with its own cost.
Common misconceptions
- Migration is done when the new service ships — it is done when the old path is deleted
- Traffic percentage is the only metric — data stores and batch jobs often outlive the API
- Metrics replace the cutover — they tell you when cutover is safe, not how to do it
Anti-patterns
- Declaring success at fifty percent traffic and stopping
- Leaving dual writes in place permanently
- Removing the legacy path before verifying rollback is possible
Related concepts
Authoritative source
What “done” actually means
A strangler migration has one honest definition of done: the old path no longer runs in production, and nothing depends on it. Shipping the new service is the halfway point, not the finish. Between those states sits a period where both systems operate, costs double, and bugs must be fixed twice. Metrics exist to make that period finite.
Four metrics that matter
Track traffic share, feature parity, dependency count, and cost. Traffic share is the percentage of production requests served by the new implementation. Feature parity counts capabilities available only on the legacy path. Dependency count tracks jobs, reports, and clients still reading the old store. Cost compares the run rate of both systems, including licences and on-call attention.
For example, a migration at ninety percent traffic with twelve nightly jobs still reading the legacy database is not ninety percent complete; it is blocked by a dependency nobody scheduled.
Instrumenting the cutover
Measure at the boundary, not inside each service: gateway logs, proxy telemetry, or database connection counts by client. Record the metric before each cutover step so you can attribute a regression. Keep a dashboard that shows the old path trending toward zero, because a flat line is the earliest signal that the migration has stalled.
The eighty percent plateau
Most migrations slow down near the end. The remaining traffic comes from forgotten clients, batch jobs, and integrations that are expensive to move. Plan for the plateau: assign an owner to each blocker, set an end date for dual writes, and put the legacy system’s cost on a team’s budget. Without pressure, the last twenty percent can outlive the migration team.
Compared to a feature checklist
A checklist tracks what has been built; these metrics track what is actually being used. Completed features with no traffic mean the cutover failed. Measure consumption, then retire on evidence.