Cómo elegir un partner para migrar tu frontend

Un partner de migración trabaja dentro de tu producto durante meses. Elegir bien importa más que elegir barato. Estas son las preguntas, las señales de alerta y los contenidos de propuesta que debes buscar.

Una nota sobre mi sesgo

Yo vivo de este trabajo, así que lee esta guía con eso en mente. Los criterios de abajo aplican a mí tanto como a cualquier otra persona con la que hables. Úsalos con cada candidato, incluido un equipo interno que ofrezca hacer la migración por su cuenta.

Define primero qué necesitas

Hay tres modelos comunes:

• Solo equipo interno. Funciona cuando tus desarrolladores conocen bien el framework de destino y pueden salir del trabajo de funcionalidades.
• El partner entrega y el equipo revisa. Es el inicio más rápido. Es riesgoso si nadie adentro aprende el código nuevo.
• Equipo mixto. El partner define el enfoque y los patrones, y tus desarrolladores migran a su lado. Es más lento al principio, y el conocimiento se queda contigo.

Ten claro cuál quieres antes de pedir propuestas. Eso cambia cómo se ve una buena propuesta.

Preguntas que debes hacer

Sobre el enfoque

1. ¿Cómo decides entre reescritura, migración incremental y microfrontends? Pide el razonamiento para tu caso.
2. ¿Qué haces antes de entregar una estimación?
3. ¿Cómo siguen trabajando los usuarios mientras se mueven las pantallas?
4. ¿Cómo reviertes una pantalla migrada que falla?
5. ¿Qué pasa con nuestro roadmap de funcionalidades durante la migración?

Sobre la experiencia

1. ¿Qué migraciones de este tipo hiciste, y cuál fue tu rol en ellas?
2. ¿Qué salió mal en alguna, y qué cambiaste después?
3. ¿Puedo hablar con una persona técnica de un cliente anterior?
4. ¿Quién va a escribir el código exactamente? ¿Voy a conocer a esas personas antes de firmar?

Sobre el servicio

1. ¿Cómo se divide el trabajo en fases, y podemos detenernos después de cualquiera?
2. ¿Qué necesitas de nuestro equipo, en horas por semana y en roles?
3. ¿Cómo reportas el avance, y qué cuenta como terminado?
4. ¿Cómo van a aprender nuestros desarrolladores el código nuevo?
5. ¿De quién son el código y las herramientas que traes?

Un candidato que responde la segunda pregunta de experiencia con una historia real suele ser más confiable que uno que dice que nunca le salió nada mal.

Señales de alerta

Qué contiene una buena propuesta

Si la propuesta se salta el diagnóstico y va directo a un total, pregunta por qué. Las razones están en la guía de costos de migración.

Cómo comparar candidatos

• Compara los diagnósticos. Un diagnóstico pagado a dos candidatos cuesta poco frente a la migración y muestra cómo piensa cada uno.
• Verifica las referencias con preguntas concretas. Pregunta qué se entregó tarde, cómo se comunicaron las sorpresas y si el equipo pudo mantener el resultado.
• Lee una muestra de su código. Una pantalla migrada en el piloto dice más que cualquier presentación.
• Mira cómo manejan el "no". Un partner que te dice que una parte de la app conviene dejarla como está, o que no lo necesitas para cierta parte del trabajo, está mostrando criterio.

Protégete de la dependencia

El objetivo de una migración es un código que tu propio equipo pueda operar. Pide trabajo en pareja desde la primera fase, exige revisión de código por parte de tus desarrolladores y requiere que los patrones queden escritos. La lista de riesgos de migración incluye la dependencia de personas clave, y un partner externo puede convertirse justo en eso.

Si quieres ver cómo estructuro yo este trabajo, la página del servicio de migración de AngularJS lo describe. Aplícale las mismas preguntas.

Más en esta sección

• Riesgos de una migración de frontend y cómo reducirlos
• El patrón strangler fig aplicado a frontends
• Feature flags y cambios de ruta en una migración incremental
• Salir de AngularJS: ¿Angular o React?