What happens when a company finishes its big cloud replatforming project, holds the celebration, and then quietly discovers six months later that nobody can say whether it was worth it? That gap is not unusual. It is the default outcome when teams measure progress by counting applications moved instead of measuring what changed after they moved. Replatforming, sometimes called “lift, tinker, and shift,” is a middle path in cloud migration: you do not rewrite the application from scratch, but you do not simply copy it unchanged either. You swap out a few components, such as a self-managed database for a managed service, while keeping the core architecture intact. Because that change is partial, the metrics have to be chosen with unusual care. (How to read a cloud region announcement) (Cloud computing)
This article lays out which metrics actually answer the question “did replatforming work,” how to collect them without drowning in dashboards, and where measurement programs typically go wrong.
Start by defining replatforming, because the word is used loosely
Before any metric means anything, the team needs a shared definition. In some organizations, replatforming means moving to containers. In others, it means trading a self-managed message queue for a managed one. In others, it is shorthand for any modernization short of a full rewrite.
That ambiguity is dangerous for measurement. If half the program office counts a containerization effort as replatforming and the other half counts only managed-service swaps, the migration velocity numbers will describe two different things. Write down the definition, list the specific component changes in scope, and treat that list as the baseline against which every metric is compared. A structured inventory of what is moving, and what is being changed in the process, makes this far easier.
The metric categories that matter
A useful replatforming scorecard covers six areas. Each answers a different question, and skipping any one of them leaves a blind spot.
Migration velocity: are we actually moving?
Velocity metrics describe the program itself rather than the workloads. Track applications or services moved per sprint or per quarter, average elapsed time per migration wave, and the percentage of waves that finished on the planned date. Velocity is the easiest category to measure and the easiest to game: a team can hit its wave count by cherry-picking the easy workloads first. Pair raw velocity with a measure of workload complexity, such as dependency count, so the number stays honest. (9481.org)
Cost: run-rate, unit economics, and the overlap nobody budgets for
Cost is where replatforming programs most often lose credibility. A raw before-and-after run-rate comparison is misleading because it ignores the period when old and new environments run in parallel. That dual-running overlap can be substantial, and it belongs in any honest total cost figure.
The stronger signal is unit economics: cost per transaction, per tenant, per active user, or per thousand API calls. A monthly bill can rise while unit cost falls, and that is often a healthy outcome if the business is growing. Tracking cost per unit rather than cost in aggregate is the difference between a finance argument and an engineering one. For a practical approach to attributing transfer and egress charges, this guide to tracking cloud data transfer costs is a useful complement.
Reliability: did the move make things better or worse?
Replatforming changes failure modes. A managed database may remove patching toil but introduce new failover behavior. Track SLO attainment, error budget burn rate, incident volume per service, and mean time to recovery (MTTR), comparing a defined pre-migration window with a post-migration window of equal length. Be careful with the comparison window: the first month after cutover is rarely representative, because teams are still learning the new system’s quirks. (What is cloud migration?)
Performance: latency at the tail, not the average
Average latency hides the experiences that generate support tickets. Track p95 and p99 latency, throughput, and where relevant cold-start times for serverless components. A replatforming that improves the mean but worsens the tail has made the product feel less reliable to real users even if the dashboard looks greener.
Change safety: the four keys
The four key software delivery metrics popularized by the DORA research program, deployment frequency, lead time for changes, change failure rate, and time to restore service, are the best-validated set available for judging whether a platform change improved the team’s ability to ship safely. One caveat deserves emphasis: these metrics were validated for software delivery broadly, not specifically for replatforming programs. They are a strong proxy, not a purpose-built instrument.
Business outcomes: the reason anyone funded this
Finally, connect the technical work to something the business recognizes: time to market for new features, revenue per environment, customer churn, support ticket volume per thousand users, or the number of releases that required a maintenance window. If a replatforming program cannot show movement in at least one business-level measure, it is hard to defend as anything more than housekeeping.
A comparison table for choosing metrics
| Metric | What it answers | Collection difficulty | Common failure mode |
|---|---|---|---|
| Apps migrated per quarter | Is the program progressing? | Low | Rewards easy workloads first |
| Unit cost per transaction | Are we more efficient? | Medium | Ignoring parallel-run overlap |
| SLO attainment | Is the service healthier? | Medium | Comparing unequal time windows |
| p99 latency | Does it feel fast to users? | Medium | Reporting averages only |
| Change failure rate | Can we ship safely? | High | Needs consistent deployment data |
| Time to market | Did the business benefit? | High | Attributed loosely, no baseline |
Practical tips for building a scorecard that survives scrutiny
Set baselines before the first cutover. This sounds obvious and is skipped constantly. If nobody captured pre-migration incident volume, latency, and unit cost, the post-migration numbers have nothing to argue with. Capture at least one full quarter of baseline data, ideally covering a seasonal peak.
Choose a small number of metrics and defend them. A scorecard with twenty metrics gets looked at once. Five or six, each with a named owner, gets reviewed every month. The discipline of deciding what not to measure is part of the work.
Separate program metrics from product metrics. Velocity and wave completion belong to the migration program and should retire when it ends. SLOs, unit cost, and change failure rate belong to the running service and should persist indefinitely. Mixing them into one dashboard means the durable signals get archived along with the program.
Report distributions alongside medians. A replatforming that went smoothly for 80 percent of services and badly for 20 percent is not a success story with a rounding error. It is a story about 20 percent of services that need attention.
Watch for the post-migration trough. Teams commonly see incident volume and change failure rate rise for a few weeks after cutover as operators learn new tooling. Build that expectation into the reporting cadence so a predictable dip does not trigger a premature “the migration failed” narrative.
Where measurement programs typically go wrong
The most common mistake is measuring activity instead of outcome. Counting migrations is comfortable because the number always goes up. It says nothing about whether the business is better off.
The second is trusting vendor-published ROI figures as benchmarks. Vendor case studies are marketing artifacts, not research. They describe selected customers, use favorable baselines, and rarely disclose the parallel-run costs. Use them for ideas about what to measure, never as a target.
The third is letting finance and engineering measure different things. When finance tracks the invoice and engineering tracks unit cost, the two groups can reach opposite conclusions about the same program and spend months reconciling. Agree on a shared definition of unit cost early, and agree on how shared platform costs are allocated. A clearer way to track cloud data transfer costs shows how much of the disagreement usually comes down to allocation method rather than actual spend.
The fourth is no post-program review. Replatforming programs tend to dissolve once the last wave ships, and the lessons evaporate with them. Schedule a formal review ninety days after the final cutover, with the baseline data in hand, and write down what the numbers showed.
How to sequence the work
- Define replatforming for your organization and list the component changes in scope.
- Capture at least one quarter of baseline data across cost, reliability, performance, and delivery.
- Select five or six metrics, assign an owner to each, and agree on definitions with finance.
- Instrument the pipeline so delivery metrics are collected automatically rather than assembled by hand.
- Review monthly during the program, and hold a formal review ninety days after the final cutover.
Steps four and five are where most programs quietly fail. Manual metric collection survives about two reporting cycles before it becomes someone’s least favorite task. Automating collection, and treating the post-program review as a real calendar commitment, is what separates a scorecard that informs decisions from one that decorates a slide.
Conclusion
Cloud replatforming is a partial change by design, and partial changes are the hardest kind to evaluate. The invoice moves, the architecture shifts, and the team’s habits change all at once. A scorecard built on unit economics, tail latency, SLO attainment, change safety, and at least one business outcome will tell you what actually happened. A scorecard built on application counts will tell you what you already knew. The difference between the two is a quarter of baseline data, a shared definition, and the discipline to keep looking after the celebration ends.
Frequently asked questions
What is the difference between replatforming and refactoring?
Replatforming changes selected components, such as moving to a managed database or containerizing an application, while keeping the core architecture. Refactoring, sometimes called re-architecting, rebuilds the application around cloud-native patterns such as microservices or event-driven design. Replatforming is faster and cheaper but delivers smaller gains; refactoring delivers more but carries far higher cost and risk.
How many metrics should a replatforming scorecard include?
Five or six is a practical ceiling. A scorecard covering unit cost, SLO attainment, tail latency, change failure rate, and one business outcome gives coverage without overwhelming reviewers. More than that and the dashboard stops being read. The discipline of choosing what to exclude is part of the value.
How long after cutover should we measure results?
Measure continuously, but judge the program at ninety days after the final cutover. The first few weeks are distorted by learning curves, parallel running, and stabilization work. A ninety-day window captures a representative operating period while keeping the review close enough to the work that people still remember the context.
Are the DORA four keys valid for replatforming programs?
They are the best-validated set available for software delivery generally, but they were not validated specifically for replatforming. Treat them as a strong proxy and pair them with reliability and cost metrics that reflect the specific changes made. If your replatforming mainly swapped managed services, SLO attainment and unit cost may tell you more than deployment frequency.
Why do cloud costs sometimes rise after replatforming?
Managed services often carry higher per-unit list prices than self-managed equivalents, and parallel running adds temporary double spend. Costs can also rise because the new platform makes it easier to deploy, so teams deploy more. This is why unit economics matter more than the total bill: cost per transaction can fall even while total spend grows with usage.
What baseline data should be captured before the first cutover?
At minimum, one full quarter of incident volume, MTTR, p95 and p99 latency, deployment frequency, change failure rate, and unit cost per service. Ideally the window includes a seasonal peak. Without this, post-migration numbers have nothing to compare against, and the program’s results become a matter of opinion rather than evidence.
