How to keep teams shipping during a migration
An incremental migration only makes sense if the product keeps moving. That takes a clear split of capacity, simple rules about who may change what, and a few regular meetings.
The promise and the catch
The main reason to migrate incrementally is that feature work does not stop. The catch is that two streams of work now touch the same codebase. Without rules, a feature lands in a legacy screen the week it is being migrated, and someone builds it twice.
Three things keep both streams healthy: a deliberate capacity split, freeze rules per module and light coordination.
Splitting capacity
There are three workable models. Choose one on purpose and write it down.
| Model | How it works | Strength | Weakness |
|---|---|---|---|
| Dedicated migration group | A few people, internal or external, work only on the migration | Steady progress, consistent patterns | Knowledge can stay in the small group |
| Share per team | Every team reserves part of each sprint for migrating its own modules | Teams learn the new stack and own the result | The reserved share is the first thing cut under deadline pressure |
| Rotation | A core group stays, and developers from product teams join for a phase | Spreads knowledge, keeps momentum | Needs onboarding at every rotation |
Whatever the model, protect the allocation. A migration that receives only leftover time stops at the first busy quarter. Agree the split with the sponsor and review it at each checkpoint of the roadmap.
Freeze rules per module
A freeze should be narrow and short. Freezing the whole product defeats the purpose. Freezing one module for the weeks it takes to migrate is easy to live with.
Rule 1: New screens are built on the new stack. From the day the pilot is live, nobody adds a screen to the legacy code. This stops the legacy part from growing.
Rule 2: A module under migration is frozen for features. While a module is in the current phase, only critical fixes go into its legacy version. Feature requests for it wait until its screens are live on the new stack.
Rule 3: Critical fixes go to both versions. If a bug must be fixed during the freeze, the fix is applied to the legacy screen and to the migrated one. The person fixing it tells the migration lead the same day.
Rule 4: Modules outside the current phase are open. Feature work continues there as usual.
Rule 5: Freezes have dates. Announce the start and the planned end of each module freeze. If the end slips, say so early.
The expensive mistake is building a large feature in a legacy module shortly before that module is migrated. The feature is built once in the old framework and again in the new one. Plan the order so this does not happen.
Align the two roadmaps
- Migrate ahead of big features. If a module has a major feature planned next quarter, migrate it this quarter. The feature is then built once, on new code.
- Leave quiet modules for later. A module with no planned changes can wait without cost.
- Respect business calendars. Do not schedule a module's migration during its busiest period, such as month-end for billing.
Coordination rituals
- Weekly migration sync. Migration lead, technical lead and product owner. Which screens moved, which are next, which questions are open and which freezes start or end.
- Phase kickoff. Before each phase, a short session with the teams affected: scope, freeze dates and who answers questions about business rules.
- Phase demo. At the end of each phase, show the migrated screens to stakeholders. It keeps support for the program and surfaces missed behavior.
- A visible board. One page that shows each module as legacy, in migration or migrated, with freeze dates. Anyone planning work checks it first.
Handling urgent work
Urgent requests will arrive. Decide beforehand how they are handled:
- Production incidents take priority over migration work, always.
- Urgent features in an open module proceed normally.
- Urgent features in a frozen module go to the sponsor, who chooses between waiting for the migrated screen and pausing that module's migration. Both are acceptable. Doing both at once is the choice to avoid.
Signs that the balance is off
- The migration share of capacity has been skipped for two sprints in a row.
- Features are regularly implemented twice.
- The number of legacy screens is going up.
Track these together with the metrics in measuring migration progress. When one appears, raise it at the next checkpoint. The wider list of risks is in migration risks and how to reduce them.
More in this section
- Measuring migration progress
- 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?
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