How to choose a frontend migration partner
A migration partner works inside your product for months. Choosing well matters more than choosing cheap. These are the questions, warning signs and proposal contents to look for.
A note on bias
I do this work for a living, so read this guide with that in mind. The criteria below apply to me as much as to anyone else you talk to. Use them on every candidate, including an internal team that offers to do the migration alone.
Decide first what you need
Three models are common:
- Internal team only. Works when your developers know the target framework well and can be taken off feature work.
- Partner delivers, team reviews. Fastest start. Risky if nobody inside learns the new code.
- Mixed team. The partner sets up the approach and the patterns, and your developers migrate alongside. Slower at first, and the knowledge stays with you.
Know which one you want before you ask for proposals. It changes what a good proposal looks like.
Questions to ask
About the approach
- How do you decide between a rewrite, an incremental migration and micro-frontends? Ask for the reasoning in your case.
- What do you do before giving an estimate?
- How will users keep working while screens move?
- How do you roll back a migrated screen that misbehaves?
- What happens to our feature roadmap during the migration?
About experience
- Which migrations of this kind have you done, and what was your role in them?
- What went wrong in one of them, and what did you change afterwards?
- Can I speak with a technical person from a previous client?
- Who exactly will write the code? Will I meet them before signing?
About the engagement
- How is the work split into phases, and can we stop after any of them?
- What do you need from our team, in hours per week and in roles?
- How do you report progress, and what counts as done?
- How will our developers learn the new codebase?
- Who owns the code and the tooling you bring?
A candidate who answers the second experience question with a real story is usually more trustworthy than one who says nothing ever went wrong.
Red flags
- A fixed price for the whole migration before reading the code. The price contains a large margin or a future dispute.
- A rewrite proposed by default. It is easy to sell and hard to deliver for anything beyond a small app.
- A redesign bundled into the migration. It doubles the scope and hides the migration progress.
- No plan to delete the legacy code. You end with two frameworks for years.
- Senior people in the sales calls and unknown people in the delivery.
- An automatic conversion tool presented as the whole solution. Tools help with mechanical parts. Business rules, widgets and tests still need people.
- No questions about your tests, your release process or your team. These decide the outcome more than the framework does.
What a good proposal contains
| Section | What to look for |
|---|---|
| Understanding of the app | Evidence that someone looked at the code or asked detailed questions |
| Approach | The chosen path and why the alternatives were set aside |
| Assessment | A short first step with a defined output and its own price |
| Phases | Scope, output and exit criteria for each phase |
| Estimate | A price or range per phase, with the assumptions written down |
| Your team's part | Roles and hours expected from you |
| Risk handling | Rollback method, testing approach, known unknowns |
| Knowledge transfer | Pairing, documentation and code review with your developers |
| Exit | What you keep if you stop after any phase |
If the proposal skips the assessment and jumps to a total, ask why. The reasons are explained in the migration cost guide.
How to compare candidates
- Compare the assessments. A paid assessment from two candidates costs little next to the migration, and it shows how each one thinks.
- Check references on specifics. Ask the reference what was delivered late, how surprises were communicated and whether their team could maintain the result.
- Read a sample of their code. A migrated screen from the pilot tells you more than any slide.
- Look at how they handle "no". A partner who tells you that part of the app should be left alone, or that you do not need them for a piece of the work, is showing judgment.
Protect yourself from dependency
The goal of a migration is a codebase your own team can run. Ask for pairing from the first phase, insist on code review by your developers and require that the patterns are written down. The list of migration risks includes key-person dependency, and an external partner can become exactly that.
If you want to see how I structure this work, the AngularJS migration service page describes it. Apply the same questions to it.
More in this section
- Frontend migration risks and how to reduce them
- The strangler fig pattern applied to frontends
- Feature flags and route switches in an incremental migration
- Leaving AngularJS: Angular or React?
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