Leading a Frontend Team Through a Platform Migration

What actually mattered as frontend tech lead on a Vue 2 to Next.js rebuild: architecture decisions, agile delivery, code quality, and keeping a small team aligned while the old app still had to ship.

Table of Contents

1. Lead the Migration, Not Just the Stack
2. Decisions That Unblock Others
3. Delivery While Two Stacks Exist
4. Quality Without a Police State
5. Documentation People Read
6. Pairing and Shared Standards

Lead the Migration, Not Just the Stack {#lead}

I led a three-person frontend team through an end-to-end rearchitecture: Vue 2 to Next.js/React, plus performance, SEO, testing, and a new component library. The technical work is documented elsewhere. This piece is the operating system around it.

A migration fails when the lead only reviews pull requests. It works when the lead sequences work so the business never has to choose between "new stack" and "this quarter's launch."

Decisions That Unblock Others {#decisions}

We wrote architecture decisions down before they became folklore.

Examples that paid off:

• Next.js App Router for catalog/content, client islands for cart
• Tailwind + shared primitives instead of porting every Vue SFC style 1:1
• Jest/Vitest for units, Playwright for money paths
• Route-based splitting, lazy hydration, image priority rules

If a decision was reversible in a week, we picked and moved. If it was a two-month trap (state library, CSS strategy, hosting), we spiked for two days and then locked it.

The job is not to win debates. It is to make the next three sprints obvious.

Delivery While Two Stacks Exist {#delivery}

Feature freeze is a fantasy. We ran dual-track:

• Vue: only revenue-critical fixes
• React: net-new pages and migrated templates behind feature flags

Sprint goals were user-visible, not "migrate 12 components."

Sprint goal: Shoppers can complete search → PDP on Next.js with parity on price and stock.
Non-goal: Pixel-match the old mega-menu animation.

Jira stayed boring on purpose: one ticket, one acceptance check, API contract linked in Confluence. Backend and frontend agreed on the payload before UI polish.

Quality Without a Police State {#quality}

ESLint, Prettier, and CI were the floor. Reviews focused on:

• Does this leak work to the client that belongs on the server?
• Is this a one-off UI or a library candidate?
• Is checkout covered by a test?
• Will this blow the JS budget?

I did not nitpick import order in review if the bot already did. Human attention went to architecture and product risk.

We tracked production issues and frontend error rate (Sentry) as team metrics, not as blame.

Documentation People Read {#docs}

Long wiki pages do not survive contact with a sprint. We kept:

1. A one-page "how we render a product page"
2. A component checklist (a11y, variants, story)
3. A migration map: Vue route → Next route → owner → flag
4. ADRs for the handful of irreversible choices

If it was not linked from the PR template, it did not exist.

Pairing and Shared Standards {#pairing}

With three people, pairing was cheaper than a backlog of "please fix after merge."

• First week on a new pattern: pair
• Checkout and auth: two sets of eyes
• After the pattern existed: async review

Shared learning was concrete: a 30-minute walkthrough of hydration, not a generic React talk. The team got faster when everyone could explain why a component was a client component.

Tech lead work on a migration is mostly sequencing, standards, and attention. The stack is the easy part to name. Keeping a small team shipping on two codebases without burning out is the actual job.