Muchas empresas terminan con una app de la que nadie se ocupa activamente. El desarrollador o la agencia original ya no está, las versiones nuevas dejaron de publicarse, la tienda de aplicaciones advierte sobre SDK obsoletos y nadie se siente seguro al modificar el código. El instinto suele ser seguir aplicando parches o empezar de cero. Ninguna de las dos opciones debería decidirse por instinto. Esta guía de rescate de apps explica cómo evaluar una app abandonada y elegir entre refactorizar lo existente o reconstruirlo, a partir de evidencia y no de la frustración.
Lo que es
El rescate de una app comienza por entender qué tiene realmente. Eso implica recuperar el acceso al código fuente, la configuración de compilación, las claves de firma, las cuentas de hosting, las fichas en tiendas de aplicaciones y los servicios de terceros; luego revisar la estructura del código, las dependencias, la cobertura de pruebas y los defectos conocidos; y después comprobar si la app todavía se compila y funciona en las versiones actuales de los sistemas operativos. Refactorizar significa mejorar el código existente sin reemplazarlo: actualizar dependencias, corregir defectos, reestructurar las áreas problemáticas y añadir pruebas, manteniendo la app en funcionamiento. Reconstruir significa escribir un código nuevo, normalmente reutilizando diseños, datos y servicios de backend cuando sea posible, y migrar a los usuarios. Refactorizar preserva la inversión realizada y evita un largo periodo sin nuevas versiones. Reconstruir puede ser la opción más adecuada cuando el código no es mantenible, se basa en un framework obsoleto o no se ajusta en lo fundamental a lo que el producto necesita ahora. A menudo la respuesta es una combinación: estabilizar ahora y reemplazar partes de forma progresiva.
Para quién es
Esta guía es útil para:
- Empresas cuyo desarrollador o agencia de la app ya no está disponible
- Product owners con una app que no compila, falla en dispositivos nuevos o enfrenta el rechazo de la tienda de aplicaciones
- Fundadores que heredaron una app a medio terminar de un equipo anterior
- Equipos que deciden si seguir invirtiendo en un código existente
Qué ayuda a aclarar
Una evaluación estructurada ayuda a aclarar:
- Si usted tiene la titularidad y el acceso completos al código, las claves, las cuentas y los datos
- Qué parte del código existente es sólida, cuánta es riesgosa y cuánta falta
- Si el framework y las dependencias siguen teniendo soporte
- Qué camino, refactorizar, reconstruir o un reemplazo por etapas, se ajusta a sus plazos y a su tolerancia al riesgo
Qué se incluye
- Recupere el acceso: repositorios de código fuente, archivos de compilación, certificados de firma y keystores, cuentas cloud y de hosting, cuentas de tiendas de aplicaciones y claves de API de terceros
- Confirme la titularidad legal del código y de cualquier licencia, con sus propios asesores si es necesario
- Compruebe si la app se compila desde el código fuente y funciona en las versiones actuales del sistema operativo
- Revise las dependencias en busca de bibliotecas obsoletas, sin soporte o vulnerables
- Evalúe la estructura del código, la cobertura de pruebas y la documentación
- Enumere los defectos conocidos, los informes de fallos, las quejas de usuarios y las advertencias de la tienda de aplicaciones
- Mapee el backend, las API y los datos de los que depende la app
- Puntúe las opciones, refactorizar, reconstruir o reemplazo por etapas, según esfuerzo, riesgo y tiempo sin nuevas versiones
- Acuerde un plan de estabilización para los problemas urgentes antes de iniciar trabajos de mayor envergadura
Qué no se incluye
- Afirmar que se encontrarán o resolverán todos los problemas heredados
- Desarrollo de nuevas funcionalidades más allá del alcance de recuperación confirmado
- Evaluación formal de seguridad o pruebas de penetración, salvo que se definan por separado
- Asesoramiento legal sobre la titularidad del código o disputas con proveedores anteriores
Cuándo elegirlo
Actúe cuando la app ya no pueda publicarse de forma segura, cuando los requisitos de la plataforma estén a punto de dejarla fuera de las normas de la tienda o cuando cada cambio pequeño introduzca nuevos problemas. No espere a que la app sea retirada de una tienda o a que un servicio crítico deje de funcionar. Si no puede acceder al código fuente o a las claves de firma, resuelva eso primero; sin ellos, reconstruir puede ser la única opción, independientemente de la calidad del código.
Nuestro enfoque
Comience por el acceso y la evidencia, no por las opiniones. Muchas apps abandonadas resultan mejores de lo que parecen una vez que vuelven a compilar; otras parecen estar bien, pero se apoyan en frameworks que ya no son viables. Tome la decisión a partir de una evaluación por escrito que abarque el código, las dependencias, la infraestructura y las necesidades del producto. Nuestro servicio App Rescue & Rebuild abarca la evaluación y la recuperación: volver a tener una compilación funcional, estabilizar los problemas críticos y recomendar y ejecutar el camino de recuperación confirmado, con un registro de recuperación con alcance definido y materiales de traspaso. Cuando el problema se extiende a una plataforma más amplia, a un backend o a un sistema heredado, el servicio Platform Rescue & Modernisation proporciona un mapa del estado actual, un plan de estabilización y una hoja de ruta de modernización. Después de la recuperación, planifique el mantenimiento continuo para que la app no vuelva a caer en el mismo estado: actualizaciones programadas de dependencias, una rutina de publicación y una titularidad clara de las cuentas y las claves.
Preguntas frecuentes
Artículos relacionados
Empezar
¿Tiene una app que nadie puede mantener?
Cuéntenos a qué tiene acceso, qué está fallando y qué necesita hacer la app a continuación. Le propondremos por escrito un alcance de evaluación y recuperación.
Solicitar un alcance por escrito