Rehacer o migrar una app existente: cómo decidir

Tenés una app que ya existe pero no está funcionando como esperabas: es lenta, cuesta agregarle cosas, quien la hizo ya no está o la tecnología quedó vieja. La duda es si conviene rehacer o migrar una app existente, o si alcanza con mejorarla. Esta guía te da criterios para decidir y explica qué conviene evaluar antes de tocar nada.

Tres caminos posibles

• Mejorar: corregir y ampliar la app actual, manteniendo su base.
• Migrar: mover la app a una tecnología o infraestructura nueva conservando funciones y datos; puede ser por etapas.
• Rehacer: reescribir desde cero, aprovechando lo aprendido pero no el código anterior.

Reescribir suele parecer atractivo («empezamos limpio»), pero es la opción más costosa y arriesgada, porque se vuelve a construir lo que ya funciona. Por eso hay que justificarla.

Señales para mejorar en lugar de reescribir

• La app hace lo que el negocio necesita, aunque tenga detalles por pulir.
• Los problemas se concentran en pocas pantallas o módulos.
• El código es entendible por otro desarrollador, aunque esté desordenado en partes.
• Las tecnologías base siguen recibiendo actualizaciones.
• Los usuarios están conformes con la lógica general y piden ajustes.

Señales de que puede convenir rehacer o migrar

• La tecnología base está discontinuada o ya no recibe soporte, y no admite las versiones actuales de Android o iOS.
• Cada cambio pequeño rompe otras partes, y los errores vuelven una y otra vez.
• Nadie del equipo actual entiende el código y no hay documentación.
• La arquitectura no permite lo que el negocio necesita ahora (por ejemplo, crecer en usuarios o integrarse con otros sistemas).
• Hay problemas serios de seguridad estructural.
• Mantenerla cuesta más, en tiempo y dinero, que construir una base ordenada.

Una sola señal rara vez alcanza. Lo prudente es una evaluación técnica previa, hecha por alguien ajeno a la decisión de vender el desarrollo nuevo, que compare las opciones con sus costos y riesgos.

Qué evaluar del código

1. Acceso: ¿tenés el código fuente completo y las cuentas (tiendas, servidores, servicios)? Sin eso, cualquier camino se complica; ver propiedad del código y contrato.
2. Estado de las dependencias: bibliotecas desactualizadas o abandonadas.
3. Estructura: si hay separación clara entre pantallas, lógica y datos.
4. Pruebas: si existen pruebas automáticas que permitan cambiar con seguridad; se relaciona con pruebas y calidad.
5. Documentación: si hay explicaciones de cómo se construye, se publica y se configura.
6. Rendimiento y errores: reportes de cierres inesperados y lentitud, para ver dónde duele de verdad.

Qué evaluar de los datos

Los datos suelen ser el activo más valioso. Antes de decidir, revisá:

• Dónde están y en qué formato, y si se pueden exportar.
• Su calidad: duplicados, campos incompletos, inconsistencias.
• Si hay copias de seguridad recientes y probadas.
• Qué datos personales contienen, con las obligaciones asociadas; ver datos personales en apps.
• Qué datos realmente hace falta conservar. Migrar es una oportunidad para limpiar.

Migración de usuarios

Un cambio de app impacta a las personas que ya la usan. Algunos puntos a planificar:

• Cuentas y contraseñas: si se cambia el sistema de acceso, quizá los usuarios tengan que restablecer su clave. Hay que comunicarlo con anticipación y simplificar el proceso.
• Misma ficha en la tienda: si es posible actualizar la app existente en lugar de publicar una nueva, se conservan instalaciones y reseñas. Depende de que tengas acceso a las cuentas originales y de que el identificador de la app se mantenga.
• Período de convivencia: a veces conviene que la versión vieja y la nueva funcionen en paralelo un tiempo, para pasar de forma gradual.
• Comunicación: explicar qué cambia, cuándo y qué tienen que hacer, sin tecnicismos.
• Plan de vuelta atrás: saber cómo reaccionar si algo sale mal el día del cambio.

Cómo suele ordenarse el trabajo

Etapa	Objetivo
Diagnóstico	Entender el estado real del código, los datos y el uso
Definición	Decidir entre mejorar, migrar o rehacer, y qué funciones mantener, cambiar o eliminar
Migración por partes	Mover módulos o datos en tramos acotados, con pruebas
Convivencia y cambio	Pasar a los usuarios con comunicación y respaldo
Cierre	Retirar lo antiguo y dejar la documentación al día

Hacerlo por partes reduce el riesgo frente a un cambio único y total, aunque lleva coordinación. Una vez terminado, el mantenimiento evita volver al mismo punto.

Siguiente paso

Si tenés una app heredada y querés saber qué opciones reales tiene, contanos la situación desde el formulario de contacto: revisamos qué se puede aprovechar antes de recomendarte un camino. Podés ver cómo organizamos el trabajo en el proceso.