How do you plan a migration from manual to automated testing, or from one framework to another?
60-second answer
I plan it as a product, with phases and measurable outcomes. First, assess the current state: test inventory, what's valuable, what's redundant, and the team's skills. Then set the target architecture and conventions, and build the foundation with a vertical slice in CI. Migrate by value, critical journeys first, running old and new in parallel until confidence is there, and retire old tests deliberately rather than migrating everything. Invest in enablement: training, pairing and templates. Track progress with coverage of critical flows, run time and flaky rate, and stop when the business goals are met, not when every old test is ported.
Explanation
Pitfalls:
- Porting 2,000 tests one-to-one, including the useless ones.
- Big-bang switch with no parallel run.
- Framework built by one person that nobody else can maintain.
- No time budget for manual testers to learn.
Phases: assess → pilot (4–6 weeks) → scale by team → retire legacy → continuous improvement.
Example
Migrating from a 1,800-test Selenium Java suite to Playwright TypeScript: analysis showed 600 tests were duplicates or obsolete; 300 moved to API level; 400 UI journeys were re-implemented over four months with 3× faster runs.
Sample code
Phase 0 (2 wks): inventory, value scoring, target architecture ADR
Phase 1 (6 wks): pilot team, 30 critical journeys, CI + reporting, conventions doc
Phase 2 (3 mo) : all teams onboard, 80% of critical journeys, old suite still runs
Phase 3 (1 mo) : retire old suite, redirect budget to API/contract tests
Metrics : critical journey coverage, PR suite time, flaky rate, escaped defects