The Product Roadmap vs. the Migration: How to Freeze Scope Without Losing the Business

Most migration scope fights happen because there is exactly one backlog and everything competes inside it. The trick that buys you peace is to declare three explicit lanes, each with its own capacity, intake rules, and exit criteria:

The exact numbers do not matter as much as the act of naming the buffer. Without it, every incident eats migration capacity invisibly, the burndown stalls, and product assumes engineering is "slow on Vue 3." Pair this with a migration cost estimate so each lane has a financial frame.

Most product/engineering scope fights are not really fights—they are missing structure. Here is the script we hand to engineering managers who keep losing the same argument:

PM: "We need feature X this quarter."

EM: "Got it. Today the migration lane has 8 weeks of work
     remaining and we are at 40% capacity there. Adding X
     means one of three things:

     (a) X ships on the new (Vue 3) shell behind a flag —
         no Vue 2 surface to throw away later. ETA +1 sprint
         vs. doing it on legacy.

     (b) We pause the migration burndown for 2 sprints to
         ship X on Vue 2. The EOL date moves by ~2 sprints.

     (c) We swap X for one of the must-ship items already
         in this quarter's plan. Which one?"

PM: "Why can't we just ship X on Vue 2 quickly and not
     pause the migration?"

EM: "Because the engineers who can ship X on Vue 2 are the
     same engineers porting checkout. There is no second
     team waiting in the wings."

Notice what the script does and does not do. It never says "no." It always offers options with named costs. Product can pick (a), (b), or (c)—any answer is acceptable, because the trade is explicit. The conversation that fails is the one where engineering says "we can't" and product hears "we won't."

The 80/20 rule that nobody enforces

"We'll spend 80% on migration and 20% on features." Two sprints later, an exec asks for a launch, and the ratio becomes 0/100 silently. Without an explicit no-go list and a buffer lane, percentages do not survive contact with the calendar.

Hidden migration tax in feature stories

Engineers smuggle migration work into feature stories ("while I was here, I ported the component"). It feels productive, but the burndown does not move and the feature looks slow. Make migration work visible in its own lane even if the code lives in the same PR.

"Migration is technical debt"

When migration is filed under "tech debt", it competes with refactors and quietly loses every prioritization meeting. Vue 2 EOL is a deadline, not a debt. See contractual supported-software clauses for why this distinction matters.

Building new features on the doomed stack

Every Vue 2 component shipped during the freeze is a component you will rewrite. New work belongs on the new shell behind a flag, even if it costs a sprint extra. The strangler fig pattern exists exactly for this.

Write the freeze down. One page, signed by engineering and product leadership. Suggested headings:

• Window: start date, expected end date, review cadence (every 2 sprints).
• In scope for migration: bundle list, route list, store list, owner per item.
• No-go list: features and refactors explicitly deferred ("no new admin tables in Vue 2 until June").
• Exceptions: who can approve a scope change (single named person), and the cost the change carries (e.g., burndown delay).
• Burndown unit: routes ported, bundles on Vue 3, or stores released — one unit, agreed up front.
• Off-ramp: what triggers ending the freeze early (and ending it late).

The charter is not bureaucracy. It is a forcing function so the next CEO email asking for "just one more thing" runs into a written page rather than a tired engineering manager. Pair it with the executive case you used to fund the program.

How long should the freeze last?

Long enough to make a dent on the burndown, short enough to fit the business cycle. Most teams we work with use rolling 6–8 week freezes inside a 4–6 month migration. See realistic timelines.

What if Sales has a contractual feature commitment?

It goes in the must-ship lane and trades against another must-ship item. The migration lane stays untouched. If everything is must-ship, the program is unfunded—escalate before it starts.

Can a small team really run two lanes?

Yes, with smaller numbers. A 4-person team can do 60/40 split if you accept slower KPIs that quarter. The mistake is pretending the split is 80/20 when reality is 95/5.

What burndown unit do you recommend?

For most apps: routes ported. It maps to user value, is easy to count, and translates to product language. Bundles work for micro-frontends; stores work for Quasar-style multi-target apps.