Measuring migration progress
"We are about halfway" is a feeling. Leadership needs a number that comes from the code and a trend that predicts the end. These are the measures that work and the report that carries them.
What a good progress measure looks like
A useful measure has three properties. It is counted from the code or from production, so nobody has to estimate it. It only moves when something is truly finished. And it reaches a clear end value: zero legacy, or all screens.
Percentages given from memory, story points and lines of code written fail at least one of these tests.
The four core measures
1. Screens migrated
This is the headline number. Define it strictly:
- The screen is live for all users on the new stack.
- The legacy version is deleted.
- The feature flag is removed.
A screen that is "done but not released" counts as not migrated. Take the denominator from the inventory made in the assessment, and record changes to it openly: screens deleted as unused, and screens added by new features.
How to collect it. Keep the inventory as a simple table with one row per screen and a status. Update it when the pull request that deletes the legacy code is merged.
2. Legacy footprint
This measure shows the old framework leaving the product. It is hard to argue with. Useful forms:
- The size of the legacy bundle, taken from the build output.
- The number of legacy registrations in the code: controllers, directives, components and services. A short script that searches the source gives this in seconds.
Pick one or two and plot them over time. The line should go down every phase and end at zero.
3. Defects
Leadership wants to know whether the migration is hurting users.
- Regressions found in migrated screens after release, per phase.
- Rollbacks: how often a flag was turned off.
- Open regressions of high severity. The target is none at each phase review.
How to collect it. Add one label in the issue tracker for bugs caused by the migration. Agree who applies it. Without the label, every bug in the product gets blamed on the migration or none does.
4. Release frequency
One purpose of modernizing is to deliver more easily. Track how often the frontend is released and how long a change takes from merge to production. During the migration these numbers show that delivery has not stopped. Afterwards they show whether the investment improved it. Record the values before the migration starts, so you have a baseline of your own.
Supporting measures
| Measure | What it tells you | Source |
|---|---|---|
| Open migration flags | Whether old versions are being deleted | Flag configuration |
| Critical flows covered by end-to-end tests | How safe each release is | Test suite |
| Screens completed per sprint | The rate used for forecasting | The inventory table |
From measures to a forecast
Divide the remaining screens by the recent rate of completed screens. Present the result as a range and update it at the end of every phase. A forecast built on finished work earns trust, because leadership can watch it converge. The reasoning is covered in how long an AngularJS migration takes.
The monthly report
One page is enough. Keep the same layout every month so readers can compare.
- Headline. Screens migrated out of the total, and the change since last month.
- Burn-down chart. Legacy screens remaining over time, with the forecast range.
- Legacy footprint. The bundle or registration count, as a line.
- Quality. Regressions and rollbacks this month. Open high-severity items.
- Delivered. The modules or screens that went live, in business terms.
- Next. What the next month will deliver.
- Risks and decisions. Items that need the sponsor, each with a recommendation.
Write the report for someone who has five minutes and no technical background. "The invoicing module now runs on the new platform, and two of seven modules remain" is a sentence a board member can repeat.
What to avoid
- Percent complete by judgment. It stays at "almost done" for months.
- Counting screens that are built but not released. Unreleased work has delivered nothing and still carries risk.
- Hiding denominator changes. If the inventory grew, show it. Unexplained changes destroy trust faster than slow progress.
- Only good news. A report with no risks is not believed.
An audience that is easy to forget
Auditors and customers also read this report. The same burn-down chart that informs the sponsor is the evidence an auditor asks for, as described in the security and compliance guide.
Set it up early
Create the inventory table, the tracker label and the footprint script during the pilot. The phase structure they report against is in the roadmap template. Measures added halfway through have no baseline, and the first months of progress become invisible.
More in this section
- After the migration: keeping the frontend current
- AngularJS migration cost: what drives it and how to estimate it
- How long does an AngularJS migration take?
- AngularJS security and compliance risk
Planning a migration or a micro-frontend platform?
In a 20-minute call you describe your situation and I tell you how I'd approach it. If it isn't worth doing yet, I'll say so.
Message me on LinkedIn