¿Cuándo migrar una aplicación de vibe coding?

Migrar una aplicación generada antes del lanzamiento es más barato y ordenado. Hacerlo después de ganar tracción aporta mejores datos, pero deja mucho menos margen para equivocarse. El momento correcto depende menos de si el proyecto nació en Lovable, Bolt, v0 o Replit que de si puedes identificar y ensayar cada límite con estado que controla la plataforma actual.

Considero que el lanzamiento es el punto en que la identidad, los datos y el dominio público se convierten en promesas a los usuarios. Antes, una migración rota cuesta horas de desarrollo. Después, el mismo fallo puede bloquear clientes, perder escrituras, invalidar sesiones o enviar tráfico a dos versiones. La tracción muestra qué merece conservarse, pero convierte un traslado de código en un cambio operativo.

No decidas por el tamaño del árbol de archivos. Una aplicación pequeña con autenticación administrada y base de datos activa puede ser más difícil que un sitio estático grande. Decide por la propiedad: quién controla el repositorio, las identidades, la base de datos, los secretos, los archivos, las tareas programadas, el dominio, el despliegue y la vuelta atrás.

Migrar antes del lanzamiento conserva la libertad

Migrar antes del lanzamiento suele convenir cuando la plataforma actual no cumple un requisito conocido de propiedad, despliegue, ubicación de datos o mantenimiento. Todavía puedes cambiar esquemas, reemplazar la autenticación, renombrar variables y reiniciar datos de prueba sin negociar con usuarios.

Esta etapa es atractiva cuando solo hay cuentas sembradas y registros descartables. Exporta el código, compílalo en un entorno limpio, recrea la base desde migraciones y descubre qué aportaba de forma implícita el espacio original. Cada fallo revela una dependencia antes de que cargue datos de clientes.

El bajo coste no vuelve opcional el trabajo. Los proyectos generados suelen funcionar porque la plataforma inyecta configuración, proporciona la URL de base de datos, aloja funciones o entiende una convención de compilación. Exportar el código demuestra que tienes archivos, no que otro proveedor pueda construir y ejecutar el sistema.

Antes de lanzar exijo una prueba limpia. Una persona que no creó el proyecto recibe solo el repositorio, una lista de secretos con valores seguros de desarrollo y las instrucciones. Si no puede iniciar sesión, crear un registro y completar el recorrido principal, el proyecto aún no es portable.

También hay razones para esperar. Un prototipo temprano puede cambiar el modelo de datos a diario y desechar el trabajo con la siguiente decisión. Si la plataforma admite el lanzamiento previsto, exportación, despliegue, dominios propios y una vuelta atrás creíble, una versión pequeña puede enseñar más que pulir infraestructura para un producto sin demanda.

La decisión no es «¿podemos moverlo?», sino «¿el traslado elimina un riesgo conocido o estamos pagando por preservar suposiciones?». Migra por una restricción concreta, no porque la infraestructura convencional parezca más respetable.

La tracción trae pruebas y obligaciones

Migrar después de ganar tracción tiene sentido cuando el uso real revela necesidades que el sistema original no cubre, pero el plan debe preservar cada promesa ya utilizada. Ya conoces las rutas concurridas, el volumen real, las tareas que activan los usuarios y las integraciones importantes. Esa evidencia evita mudarse hacia una arquitectura imaginaria.

Las obligaciones son concretas. Las contraseñas deben seguir funcionando o debe existir un restablecimiento controlado. Los identificadores tienen que mantenerse si aparecen en URLs, facturas, webhooks o claves externas. Los archivos requieren traslado. Los enlaces de correo y retornos OAuth deben apuntar al dominio correcto. Las escrituras durante la copia deben llegar a la nueva base o pausarse deliberadamente.

La tracción no es un umbral único. Diez clientes que usan la aplicación para nóminas producen más riesgo que diez mil lectores de un catálogo estático. Cuenta estado y consecuencias, no cuentas. Pregunta cuánto cambia por minuto, qué cuesta duplicar una acción, cuán rápido soporte puede contactar a cada afectado y si el negocio tolera mantenimiento.

Aquí los equipos confunden demanda observada con permiso para reescribir. Más usuarios no justifican automáticamente otra arquitectura. Si la aplicación exportada se entiende y los servicios pueden separarse límite por límite, una migración gradual es más segura que reemplazar toda la pila.

Antes de aprobar el cambio quiero un mapa escrito:

• Repositorio y proceso de compilación
• Directorio de usuarios y sesiones activas
• Base principal, archivos y copias
• Secretos, tareas programadas y webhooks salientes
• Dominio, registros de correo, monitorización y autoridad para volver

Cualquier hueco bloquea el trabajo. No es un detalle para la noche del cambio. El nombre de la plataforma solo importa si modifica cómo exportar o configurar uno de estos activos.

Autenticar significa migrar identidades

Trata la autenticación como transferencia de identidades y reglas de confianza, no como una pantalla que se reconstruye luego. El formulario visible es sencillo. Los hashes, identificadores del proveedor, correos verificados, segundo factor, recuperación, sesiones y roles sostienen la continuidad.

Primero averigua si la aplicación posee una tabla de usuarios o delega la identidad. Si puedes exportar usuarios, revisa los campos y si el destino acepta los hashes. No son intercambiables porque ambos sistemas usen esa palabra. El destino debe admitir exactamente el algoritmo y sus parámetros o cada contraseña tendrá que restablecerse.

El inicio social añade otro límite. OAuth suele devolver un identificador estable específico del proveedor. Si la nueva implementación solo compara correos, puede unir personas equivocadas cuando cambian direcciones o aparecen alias. Conserva emisor, sujeto del proveedor e ID local. Registra los retornos antes del cambio y prueba tanto un alta como una cuenta existente.

La guía de gestión de sesiones de OWASP recomienda renovar el ID de sesión tras un cambio de privilegios. La migración no es tal cambio, pero la recomendación deja claro que la sesión es estado de seguridad. Serializar cookies opacas entre sistemas suele ser mal negocio. Mantén el verificador anterior solo si lo entiendes, o caduca las sesiones y pide entrar otra vez. No aceptes una cookie que el servicio nuevo no pueda validar.

El alcance de la cookie también rompe migraciones correctas. Comprueba nombre, dominio, ruta, Secure, HttpOnly y SameSite. MDN explica en Set-Cookie que Domain extiende la cookie al dominio y sus subdominios; sin él queda limitada al host emisor. Importa si web y API estaban en hosts distintos. Prueba con un perfil nuevo para que una cookie vieja no oculte el fallo.

La autorización requiere otra comparación. Un usuario puede entrar y perder pertenencia a una organización, rol administrativo, derecho de suscripción o política por fila. Exporta muestras con distintos roles y escribe pruebas de acceso esperado. Una pantalla de acceso correcto demuestra muy poco.

Antes de lanzar prefiero sustituir la identidad y borrar usuarios de prueba. Con tracción, elige una estrategia:

• Importar hashes compatibles y conservar IDs de proveedor.
• Mantener el servicio de identidad anterior mientras se mueve la app.
• Exigir restablecimiento con tokens únicos y caducables.
• Leer temporalmente de ambos con una sola autoridad de escritura.

No operes dos directorios escribibles. Los cambios de correo y solicitudes de borrado en conflicto convertirán esa comodidad en un incidente.

La base de datos debe conservar el significado

La migración solo funciona si preserva restricciones, identificadores, fechas, relaciones y toda escritura aceptada durante el traslado. Contar filas es insuficiente. Dos bases pueden tener el mismo número y discrepar en precisión monetaria, zonas horarias, unicidad, nulos o claves externas.

Antes del lanzamiento, reconstruye la base con migraciones versionadas, no copiando desarrollo. Carga solo registros necesarios. Así demuestras que el historial está completo y que la aplicación no depende de tablas creadas a mano en una consola.

Con tracción, separa el traslado del esquema del de datos vivos. Registra motor, versión, extensiones, ordenamientos, columnas generadas, disparadores, políticas por fila, secuencias y objetos grandes. Si cambia el motor, también migras la aplicación. La sintaxis SQL es la parte menor; las transacciones y los tipos causan sorpresas.

PostgreSQL describe pg_dump como una exportación coherente que no bloquea lectores ni escritores. Es útil, pero no cubre escrituras confirmadas después de empezar la instantánea. Aún necesitas captura de cambios, pausa final o mantenimiento para cerrar la brecha.

Guarda una consulta de conciliación junto al registro del cambio. Este fragmento comprueba conteos, límites de ID y últimas actualizaciones:

SELECT 'users' AS table_name, count(*) AS rows,
       min(id)::text AS min_id, max(id)::text AS max_id,
       max(updated_at) AS newest_update
FROM users
UNION ALL
SELECT 'projects', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM projects
UNION ALL
SELECT 'orders', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM orders;

Ejecútala en ambos lados e investiga diferencias. Después prueba reglas que los conteos no ven: ninguna orden sin usuario, saldos iguales al libro, un objeto por archivo y las mismas restricciones de unicidad.

Una copia necesita restauración probada. Que el archivo se genere solo prueba que terminó un comando. Restáuralo en un destino vacío, ejecuta la aplicación y mide el tiempo. Esa cifra dice si restaurar es una vuelta realista o solo tranquilizadora.

El almacenamiento suele esconderse tras filas. Una tabla uploads puede conservar nombres mientras los objetos siguen en un contenedor administrado. Copia bytes, sumas, tipos, reglas de acceso y propiedad; prueba descargas desde la aplicación. Regenera URLs firmadas o ligadas al host viejo. Incluye archivos en la misma ventana, sobre todo si el usuario puede reemplazarlos durante la copia.

Las variables revelan arquitectura oculta

Convierte la bolsa heredada de variables en un contrato por entorno. Las ausentes fallan de forma obvia. Son más peligrosos los valores plausibles pero erróneos: una clave de pago de prueba, un secreto de webhook antiguo o un origen que devuelve al host anterior.

Inventaría variables desde código, ajustes, compilación, funciones, tareas y despliegue. No copies todo el entorno. Clasifica cada valor por dueño, sensibilidad, alcance, rotación y momento de lectura.

Un manifiesto breve permite revisarlo:

DATABASE_URL          runtime   secret   owner=backend   rotate=yes
PUBLIC_APP_ORIGIN     build     public   owner=web       rotate=no
SESSION_SIGNING_KEY   runtime   secret   owner=security  rotate=yes
MAIL_SENDER           runtime   public   owner=ops       rotate=no
WEBHOOK_SECRET        runtime   secret   owner=backend   rotate=yes

Compilación y ejecución difieren en clientes tipo React. Un valor incrustado no cambia al editar ajustes de ejecución. Recompila e inspecciona el paquete público. Nunca pongas un secreto en una variable porque tenga el prefijo público del framework.

Rota secretos con una etapa de solapamiento. Para webhooks o sesiones, acepta brevemente el viejo y el nuevo pero emite solo el nuevo. Retira el anterior tras la ventana máxima. Si el proveedor admite uno, coordina el cambio final y documéntalo.

Antes de lanzar, elimina variables sin uso y falla al arrancar si faltan obligatorias. Con tracción, observa antes de limpiar para saber si una integración aparentemente vieja aún recibe llamadas. Adivinar por nombres desactiva ese trabajo mensual que finanzas necesita.

Compara valores por entorno sin pegar secretos en el documento. Anota nombres y versiones, guarda valores en el almacén del destino y concede a la identidad de la app solo lo necesario. Registra quién cambió una variable y qué versión la consumió. Así respondes «¿qué URL de base desplegamos realmente?».

Cambiar el dominio controla el tráfico

Diseña el cambio para que despliegue viejo y nuevo acepten tráfico durante la propagación DNS. DNS no cambia a la vez en todas partes, y bajar el TTL poco antes no afecta a resolutores que ya guardaron el valor anterior.

Baja el TTL varios días antes y confirma la respuesta autoritativa. Mantén sano el despliegue viejo durante el TTL previo más un margen. Aprovisiona el certificado antes de dirigir tráfico y verifica por separado raíz, www, subdominio API, redirecciones e IPv6.

El dominio es solo la puerta. Actualiza retornos de autenticación, orígenes, cookies, URLs canónicas, webhooks, enlaces de correo y enlaces móviles. Busca el host viejo en código y ajustes. Redirigir ayuda al navegador, pero no repara un retorno OAuth estricto ni una firma para otro endpoint.

Cero interrupción solo es posible si ambas versiones usan estado compatible. Si el esquema nuevo rompe el código viejo, el solapamiento DNS causa fallos. Amplía y contrae: añade primero, despliega código que entienda ambas formas, mueve datos y retira lo viejo cuando no quede tráfico.

Con poco volumen, una ventana breve puede ser más segura que replicación compleja. Anuncia la pausa, responde con mantenimiento, drena tareas, toma la copia final, concilia, cambia y reabre. La lectura puede seguir si no genera trabajo oculto.

La vuelta atrás necesita una regla de datos. Cambiar DNS es fácil antes de que el destino acepte escrituras. Cuando ambos lados escriben, puede perder o bifurcar datos. Define el último punto seguro; después avanza o concilia.

Observa desde fuera del proveedor nuevo. Resuelve con varios servicios, solicita la cadena del certificado, carga sin caché, envía una transacción reversible y confirma el trabajo posterior. Un panel puede verse sano mientras una región entrega DNS o compilación antiguos. Vigila el dominio público y un host de prueba hasta terminar el solapamiento.

Limpiar el código hace duradero el traslado

La limpieza debe quitar acoplamiento sin borrar estructura útil ni iniciar una reescritura ajena. El código generado puede ser repetitivo, pero el gusto no es requisito de migración. Cambia lo que impide compilación independiente, pruebas, revisión de seguridad u operación.

Empieza por la procedencia. Exporta el repositorio completo y conserva licencias, atribuciones, migraciones, archivos de bloqueo y configuración. Busca secretos en el historial Git. Quitarlos del último archivo no los revoca: rota credenciales y decide si reescribir el historial.

Busca importaciones específicas, proxies, clientes de datos, ayudantes de autenticación, adaptadores, archivos de despliegue y endpoints generados. Aíslalos tras interfaces estrechas cuando convenga. Buscar ayuda, pero ejecutar recorridos muestra qué referencias importan.

Limpia dependencias después de lograr una compilación independiente. Elimina paquetes de uno en uno, regenera el bloqueo con el gestor existente y prueba cada grupo. No actualices framework, estado, nombres y hosting en el mismo cambio. Cada fallo tendría demasiadas causas.

Revisa el servidor generado en límites de confianza. Sigue cada petición desde ruta a autorización y consulta. El servidor no debe confiar en visibilidad del cliente. Comprueba límites de subida, destinos salientes, errores y rutas administrativas. No hace falta reescribir cada manejador, sino confirmar que sigue aplicando acceso sin el middleware administrado.

El proyecto necesita archivos operativos: ejemplo de entorno falso, comandos de migración, instrucciones de compilación y arranque, salud y trabajadores. Deben poder ejecutarse. Un README que dice «configura la base» solo registra que existe.

Antes del lanzamiento puedes reiniciar esquemas y refactorizar porque no hay compatibilidad. Después, conserva APIs, IDs y conducta visible hasta estabilizar la infraestructura. Deja un periodo tranquilo antes de cambiar producto. Si migración y rediseño llegan juntos, soporte no sabrá explicar las quejas.

Ensayar convierte la caída en decisión

El ensayo debe reproducir producción con datos recientes saneados y producir tiempos, conciliación y un punto de aborto probado. Una lista ajena no dice cuánto tarda tu restauración ni qué tarea sigue escribiendo tras activar mantenimiento.

Una persona ejecuta y otra observa, anota tiempos y cuestiona saltos. En equipos pequeños puede ser el fundador, pero necesita contexto para reconocer resultados distintos. Quien escribe comandos no debe decidir solo si funcionaron.

El procedimiento tiene orden estricto:

1. Congela despliegues ajenos y registra versiones, DNS y versiones de secretos.
2. Pausa escrituras, drena colas, detén tareas y anota la última marca de origen.
3. Copia el resto, concilia tablas y reglas, prueba autenticación y recorrido principal.
4. Cambia tráfico, verifica certificados y retornos, observa errores y colas, reabre escrituras.
5. En el punto declarado, continúa o ejecuta la regla de vuelta documentada.

Antes de lanzar, ensaya destruyendo el destino y reconstruyéndolo desde el repositorio. Buscas reproducibilidad; una base vacía y un entorno fresco revelan más que una copia parecida a producción.

Con tracción, ensaya escala y concurrencia. Copia datos suficientes para exponer índices lentos, reproduce lecturas seguras, crea escrituras conocidas y verifica que las tareas toleren reintentos. Enviar dos correos no es inocuo porque la base siga coherente.

Mide la pausa de escritura aparte de toda la ventana. La copia grande puede hacerse con el origen activo y pausar solo para delta y validación. Si el delta no cabe, añade replicación o captura. No lo descubras con clientes esperando.

Conserva evidencia: versiones, tiempos, comprobaciones, pruebas, respuestas DNS, decisiones y hora de apagar servicios viejos. El registro acelera el diagnóstico y evita que el próximo plan dependa de la memoria.

Elige la etapa por su reversibilidad

La mejor etapa es aquella donde el fallo realista sigue siendo reversible. Antes del lanzamiento hay poca evidencia y mucha libertad. Después hay evidencia y estado que debe mantenerse coherente.

Uso seis pruebas:

• Migra antes si una restricción conocida de cumplimiento, propiedad, exportación, hosting o arquitectura bloquea el lanzamiento.
• Quédate y lanza si la plataforma cubre la necesidad y solo impulsa el miedo.
• Migra después si el uso medido revela un límite y puedes ensayar identidad, datos y tráfico.
• Retrasa si no puedes exportar una base restaurable, controlar dominio, enumerar secretos o definir quién escribe.
• Prefiere separación gradual si autenticación o datos pueden quedarse mientras mueves cómputo y hosting.

Lovable, Bolt, v0 y Replit pueden producir proyectos cuya portabilidad depende de servicios, plan y código concreto. Inspecciona el repositorio y los controles reales. La categoría del proveedor no dice si tus hashes, extensiones, archivos o ajustes pueden moverse.

Si eliges otro entorno por chat, planificación y vuelta atrás reducen el coste de separar el traslado en cambios revisables. Koder.ai admite exportación de código, despliegue, hosting, dominios propios, instantáneas y rollback, por lo que esos controles de propiedad caben en el plan sin depender de una plataforma.

Reserva un presupuesto de migración antes de lanzar aunque decidas quedarte. Controla el código, versiona el esquema, documenta el contrato y ensaya restauraciones. Cuesta menos cuando la app es pequeña y conserva la opción hasta que la tracción aporte un motivo, no una crisis.

Si el equipo no puede restaurarla hoy, la portabilidad sigue siendo una intención y no una propiedad de la aplicación.