Replatforming: qué es y cuándo hacerlo

Replatforming significa mover una aplicación existente a una nueva plataforma, como un nuevo runtime, framework, base de datos, entorno de hosting o sistema de e-commerce, conservando sus funcionalidades y la mayor parte de su lógica de negocio. Cambias los cimientos, no el producto.

Está entre un simple lift-and-shift y una reescritura completa. Lideré una migración así en avanzzada, en una plataforma que postula automáticamente a vacantes de empleo por sus usuarios. La lección principal: el cambio en sí rara vez es la parte difícil. Lo difícil es mantener el producto funcionando mientras lo haces.

¿Qué significa replatforming?

La palabra se usa de dos maneras un poco distintas, y conviene saber a cuál se refiere cada persona.

En trabajo de nube e infraestructura, suele venir de las estrategias de migración popularizadas por los proveedores de nube (a menudo descrita como “lift, tinker and shift”). Mueves una app a un nuevo entorno y haces algunos cambios puntuales para aprovecharlo, por ejemplo reemplazar una base de datos autoadministrada por una administrada, sin rediseñar la aplicación.

En e-commerce y producto, a menudo significa pasar a otra plataforma por completo: otro motor de e-commerce, CMS o stack de aplicación. Los datos y la experiencia de usuario se trasladan; el motor de abajo cambia.

Ambos sentidos comparten una idea: el producto sigue siendo reconociblemente el mismo para los usuarios, mientras cambian los cimientos. Si los usuarios notan grandes cambios de funcionalidad, probablemente estás haciendo algo más parecido a un rediseño o a una reescritura.

¿En qué se diferencia el replatforming del rehosting y la refactorización?

Estos términos se confunden todo el tiempo. Esta es la distinción práctica que uso. Es una regla práctica, no un estándar formal.

El rehosting suele ser lo más barato y lo más rápido, pero no arregla un stack que nadie quiere mantener. La refactorización mejora el código, pero te deja en la misma plataforma. El replatforming es el camino intermedio: arreglas los cimientos sin tirar la lógica que ya codifica años de decisiones de negocio.

En la práctica, los límites se difuminan. Un replatforming casi siempre incluye algo de refactorización, porque el código escrito para el framework viejo rara vez encaja sin cambios en el nuevo. La disciplina está en limitar esa refactorización a lo que el cambio exige.

¿Cuándo es el replatforming la decisión correcta para una app legada?

Haz replatforming cuando lo que te frena es la plataforma, no el producto. Señales que busco:

• Dependencias al final de su vida útil. La versión del lenguaje, el framework o la base de datos ya no reciben parches de seguridad.
• Dificultad para contratar. Pocos ingenieros quieren trabajar con el stack, y por eso el onboarding tarda mucho más.
• Límites de escala o de costo. La arquitectura no soporta la carga sin soluciones improvisadas y caras.
• Integraciones bloqueadas. Proveedores de pago, sistemas de autenticación o APIs que necesitas ya no son compatibles con tu stack.
• Entrega lenta por culpa de la plataforma. Los cambios pequeños tardan días por las herramientas, no por el problema.

Igual de importante es saber cuándo no hacerlo. Si el problema real es código desordenado sobre una plataforma que por lo demás está sana, refactorizar suele ser más barato. Si el producto está fracasando en el mercado, unos cimientos nuevos no van a ayudar. Y si nadie entiende qué hace realmente la app, necesitas una auditoría antes de comprometerte con cualquier migración. Esa auditoría es lo primero que pido antes de recomendar mover cualquier cosa.

Un punto sobre costos: una reescritura completa suele costar más y tardar más que una migración incremental, porque el sistema viejo tiene que seguir funcionando en paralelo todo el tiempo. Esa es una gran razón por la que el replatforming por etapas tiende a ganar en productos en vivo con usuarios que pagan.

¿Qué falla con más frecuencia durante un replatforming?

En mi experiencia, el código nuevo rara vez es lo que falla. Las sorpresas vienen de comportamientos que nadie dejó por escrito.

Jobs en segundo plano y tareas programadas

Los cron jobs, los workers de colas y los scripts nocturnos a menudo viven fuera de la base de código principal, o dentro de ella sin documentación. Envían emails, expiran sesiones, concilian pagos. Si no los encuentras, simplemente dejan de ejecutarse en la nueva plataforma, y nadie lo nota hasta que un cliente se queja.

Flujos de dinero

El checkout, la facturación, los reembolsos y la emisión de facturas tienen casos límite acumulados durante años: descuentos que se combinan de formas raras, reglas de redondeo, reintentos después de timeouts del proveedor. Aquí es donde paso más tiempo probando y acepto el rollout más lento.

Rarezas de los datos

Las bases de datos viejas guardan nulls donde el código asume valores, registros duplicados, codificaciones inconsistentes y filas creadas por funcionalidades eliminadas hace mucho. El nuevo esquema es más limpio que la realidad, y la primera importación de datos reales lo demuestra.

Integraciones y webhooks

Los terceros suelen tener tus URLs viejas, allowlists de IP o credenciales escritas directamente en su código. Un webhook que apunta al sistema viejo sigue entregándole eventos después del corte.

Sesiones, autenticación y URLs

Usuarios que pierden la sesión de forma inesperada, hashes de contraseñas rotos, URLs cambiadas que arruinan el posicionamiento en buscadores o los enlaces guardados. Técnicamente son cosas pequeñas, pero cuestan caro en confianza.

Diferencias de rendimiento

Una consulta que era rápida en el motor de base de datos viejo puede ser lenta en el nuevo. El comportamiento bajo carga cambia con la plataforma, así que prueba con volúmenes de datos realistas.

¿Cómo hacer replatforming sin dejar el producto fuera de línea?

Evita el corte big-bang, en el que construyes todo y cambias en un fin de semana. Concentra todo el riesgo en un solo momento, sin un camino fácil de regreso. El enfoque en el que confío es incremental: el sistema viejo sigue atendiendo a los usuarios mientras el nuevo toma el control pieza por pieza.

En avanzzada, lideré la migración completa de toda la arquitectura de la plataforma de un stack legado a uno nuevo mientras la gente la seguía usando todos los días. El orden del trabajo importó más que la tecnología. La secuencia de abajo empieza con el mismo orden que uso cada vez que heredo una base de código: primero los accesos, luego el build, luego los flujos de dinero, luego los riesgos.

1. Consigue acceso y un build que funcione. Repositorios, hosting, bases de datos, cuentas de terceros, secretos y la capacidad de compilar y desplegar el sistema actual. No puedes migrar lo que no puedes ejecutar.
2. Mapea los flujos de dinero y el comportamiento oculto. Enumera jobs, integraciones, pagos y todo lo que toque ingresos o datos de usuarios. Eso se convierte en tu checklist.
3. Pon un punto de desvío delante de todo. Antes de escribir código nuevo, agrega una capa de enrutamiento o feature flags para poder enviar el tráfico al sistema viejo o al nuevo, por ruta o por grupo de usuarios.
4. Mueve una porción a la vez. Empieza por las partes de bajo riesgo y bajo tráfico. Cada porción tiene sus propias pruebas de comparación con el comportamiento viejo.
5. Libera de forma gradual. Envía una pequeña parte de los usuarios al nuevo camino, observa los errores y las métricas de negocio, y luego amplía. Si algo se ve mal, regresa el desvío.
6. Migra los datos con cuidado. Mantén los dos almacenes de datos sincronizados durante la transición y decide cuál es la fuente de verdad de cada tabla en cada etapa.
7. Retira la pieza vieja. Elimina una porción solo después de que haya funcionado sin problemas durante un tiempo. Dejar código viejo corriendo para siempre anula el propósito.

Esto arranca más lento que una reescritura, porque primero inviertes tiempo en el punto de desvío y en las pruebas. Vale la pena porque cada paso es reversible y los usuarios no quedan expuestos a un único día de lanzamiento de alto riesgo. No puedo prometer que ninguna migración tenga incidentes, pero esta estructura tiende a mantenerlos pequeños y recuperables.

¿Quieres una segunda opinión sobre tu migración?

Si estás evaluando un replatforming para tu propia app, escribe a me@filipeeduardo.dev con una breve descripción del stack y de lo que está fallando. Con gusto comparo notas contigo y te digo qué revisaría primero. Si quieres ayuda externa, mira primero cómo evaluar servicios de modernización de sistemas legados.