Reparar migraciones de base de datos rotas en apps generadas por IA de forma segura

Por qué las apps generadas por IA acaban con migraciones rotas

Una migración de base de datos es un pequeño script que cambia tu base de datos de forma controlada. Piénsalo como un “paso de receta” para tus tablas: crear una columna, renombrar un campo, añadir un índice. Las migraciones deben ejecutarse en orden para que cada entorno termine con el mismo esquema.

Las apps generadas por IA suelen romper esta cadena porque el código se produce rápido, sin los hábitos que los humanos usan para mantener el historial limpio. Las herramientas pueden generar migraciones automáticamente, regenerarlas tras un prompt o copiar patrones de otro proyecto. Eso puede crear archivos que parecen válidos pero que no concuerdan entre sí.

Causas comunes incluyen:

• Dos migraciones que intentan cambiar la misma tabla de maneras distintas
• Un archivo de migración editado después de que ya se ejecutó en algún entorno
• Nombres o timestamps duplicados que se ordenan distinto en distintas máquinas
• Migraciones generadas contra una base local que no coincide con staging o prod

“El código funciona en mi máquina” ocurre cuando la base de datos del portátil tiene cambios manuales extra, pasos faltantes o un orden de migraciones distinto. El código de la app coincide con tu esquema local, así que todo parece bien, hasta que producción ejecuta la cadena real de migraciones y encuentra una tabla faltante, una columna duplicada o una clave foránea que no se puede crear.

Este problema suele aparecer en el peor momento: el primer deploy, cuando un nuevo compañero hace setup desde cero, o cuando CI levanta una base limpia y aplica las migraciones en un orden estricto.

Si heredaste un prototipo generado por IA de herramientas como Lovable, Bolt, v0, Cursor o Replit, esto es una de las primeras cosas que FixMyMess revisa en un diagnóstico, porque los problemas de migraciones pueden ocultarse hasta el día del lanzamiento.

Síntomas y riesgos a vigilar antes de tocar nada

Las migraciones rotas suelen aparecer justo cuando intentas desplegar, pero el problema real a menudo empezó antes. Las apps generadas por IA pueden crear migraciones rápido y luego seguir editando modelos y esquema de formas que no coinciden con lo que ya se ejecutó en otros entornos.

Las señales obvias son difíciles de ignorar: los despliegues fallan con “tabla no encontrada” o “columna ya existe”, las páginas se caen porque una consulta espera un campo que no está, o ves tablas faltantes que el código asume que existen. Otro patrón común son columnas duplicadas (como user_id y userid) o índices creados dos veces con nombres distintos.

Las señales más peligrosas son silenciosas. Tu app puede seguir funcionando, pero local, staging y producción ya no coinciden. Un entorno puede tener un tipo de columna más nuevo, un valor por defecto diferente o una restricción (como NOT NULL) que los demás no tienen. Eso crea bugs “funciona en mi máquina”: una característica pasa tests localmente pero falla en producción, o peor, escribe datos incorrectos que sólo se notan después.

Antes de intentar arreglar migraciones rotas, vigila estos riesgos:

• Pérdida de datos por ejecutar migraciones destructivas sobre el esquema equivocado
• Downtime prolongado si una migración bloquea tablas grandes o dispara backfills lentos
• Rollbacks parciales donde el código revierte pero la base de datos no puede deshacer cambios limpiamente
• Bugs ocultos cuando el código asume un esquema que solo existe en un entorno

Una buena regla: si no puedes responder claramente “¿qué migraciones se ejecutaron en prod y en qué orden?”, detente. No ejecutes más migraciones a ciegas para “ver si funciona”. Eso a menudo amplía la brecha entre entornos y dificulta la recuperación. Si heredaste un prototipo generado por IA y los errores se acumulan, equipos como FixMyMess suelen empezar con una auditoría en modo lectura para mapear qué es seguro ejecutar y qué necesita una reconstrucción controlada.

Empieza con un inventario rápido: qué existe y dónde

Antes de intentar arreglar migraciones rotas, hazte una imagen clara de lo que realmente tienes. La mayoría de los desastres de migraciones ocurren porque la gente asume que local, staging y producción son iguales cuando no lo son.

Primero, nombra cada entorno que exista hoy. Normalmente incluye al menos local (tu portátil), staging (un servidor de pruebas) y producción (usuarios reales). Si tienes apps de preview, bases de datos de staging antiguas o una segunda región de producción, inclúyelas también.

A continuación, captura el esquema actual en cada entorno tal como está ahora, no como quisieras que estuviera. Usa lo que soporte tu stack: un volcado de esquema, un comando de introspección o una exportación de solo lectura de tablas, columnas, índices y restricciones. Guarda estos resultados con marcas de tiempo para poder compararlos después.

Luego recopila las fuentes de migraciones y el estado de migraciones:

• La carpeta completa de migraciones del repo (incluyendo archivos antiguos)
• La tabla de tracking de migraciones en la base de datos (por ejemplo, la tabla que registra qué migraciones se ejecutaron)
• Cualquier nota manual o scripts que se usaron para cambiar la base de datos fuera de las migraciones
• El comando exacto usado cuando falla (y quién lo ejecutó)
• El texto completo del error, además de cuándo ocurre (instalación nueva vs después de hacer pull)

Finalmente, escribe la historia del fallo en palabras simples. Ejemplo: “Local funciona, staging falla en la migración 0042, producción tiene una columna extra añadida manualmente.” Esta breve narración evita conjeturas y acelera los siguientes pasos, especialmente si traes ayuda como FixMyMess para una auditoría.

Audita el historial de migraciones en busca de conflictos y ediciones

Antes de arreglar migraciones rotas, aclara si tu cadena de migraciones es fiable. Las apps generadas por IA suelen crear migraciones rápido y luego sobrescribir archivos o generar nuevas sin respetar lo que ya se ejecutó en producción.

Empieza leyendo la lista de migraciones de la más antigua a la más nueva y comprobando si el orden está limpio. Los huecos no siempre son fatales, pero son una señal de que archivos fueron renombrados, borrados o regenerados. También vigila IDs o timestamps duplicados que podrían hacer que dos migraciones reclamen el mismo “slot” en la historia.

Luego, busca ediciones en migraciones antiguas. Si una migración se aplicó en cualquier sitio (staging o prod) y luego su archivo cambió, ahora tienes dos verdades: la base de datos tiene una versión y tu repo otra. Una comprobación rápida es comparar fechas de modificación de archivos, el historial de commits o simplemente buscar comentarios como “fix” añadidos a una migración vieja.

Los merges de ramas son otra fuente común de conflicto. Dos ramas pueden añadir cada una la “siguiente migración”, así que al mergear acabas con migraciones en competencia que ambas asumen que son la próxima. Esto suele aparecer como dos archivos nuevos creados en minutos pero con contenidos distintos.

Finalmente, asume que algunos cambios se hicieron manualmente en al menos un entorno. Si alguien añadió un índice en producción, parcheó el tipo de columna o ejecutó un snippet SQL, tus migraciones no lo reflejarán.

Lista rápida de auditoría:

• Confirma que los IDs de migración son únicos y estrictamente crecientes
• Señala cualquier archivo de migración antiguo que fue editado tras su creación
• Identifica migraciones “paralelas” creadas en ramas separadas
• Anota cualquier cambio de esquema que exista en la BD pero no en las migraciones
• Escribe qué entornos probablemente difieren (local, staging, prod)

Si esto se ve desordenado, es normal en prototipos de herramientas como Cursor o Replit. Equipos como FixMyMess suelen empezar con esta misma auditoría antes de decidir si reparar o reconstruir la cadena.

Detecta drift entre entornos sin adivinar

El drift de migraciones ocurre cuando dos entornos (local, staging, prod) tienen esquemas distintos aunque se supone que son iguales. En apps generadas por IA, esto suele pasar tras “arreglos rápidos” hechos directamente en la base de datos, o después de editar y volver a ejecutar migraciones.

Comienza comparando el esquema en sí, no los archivos de migración. Quieres un diff claro y escrito de lo que existe en cada entorno: tablas, columnas, tipos de datos, índices y restricciones (especialmente claves foráneas y unicidad). Estas son las diferencias que suelen explicar por qué un endpoint funciona localmente pero falla en prod.

Una forma práctica y rápida es exportar una instantánea de esquema de cada entorno (un volcado solo de esquema o la salida de introspección de tu ORM) y compararlas lado a lado. Al revisar el diff, céntrate en objetos que cambian el comportamiento:

• Columnas faltantes o extra que el código lee/escribe
• Diferente nullability o valores por defecto
• Restricciones de unicidad faltantes (de pronto se permiten duplicados)
• Claves foráneas faltantes (o reglas de cascade distintas)
• Diferencias de índices que causan timeouts con tráfico real

Separa “diferencias esperadas” del drift real. Datos de seed, usuarios de prueba admin y flags de desarrollo pueden diferir sin problema. Las diferencias de esquema rara vez son “esperadas”. Si el esquema difiere, asume que algo terminará rompiéndose.

Luego elige una fuente de la verdad. Esto es una decisión, no una suposición. Usualmente producción debería ganar si sirve usuarios reales, pero a veces prod es la más desordenada (por ejemplo, columnas hotfixed añadidas manualmente en una crisis). Si vas a arreglar migraciones rotas, elige el entorno con el esquema más correcto y completo y documenta por qué.

Ejemplo: un prototipo en Replit funciona localmente, pero el signup falla en prod. El diff muestra que prod carece de un índice único en users.email, así que se crearon cuentas duplicadas y la autenticación se volvió inconsistente. Ese solo drift explica los bugs aleatorios de login y te dice exactamente qué reparar primero.

Paso a paso: un plan de recuperación seguro que puedes seguir

Las migraciones rotas se sienten urgentes, pero apurarse convierte un problema de esquema en pérdida de datos. El plan más seguro es deliberadamente aburrido: pausar cambios, crear un punto de restauración fiable y ensayar la solución antes de tocar producción.

Primero, congela los despliegues. Para auto-deploys, jobs de background que aplican migraciones al arrancar y cualquier release de “solo pushear”. Si la app atiende clientes, elige una ventana de mantenimiento y comunica qué está bloqueado: esquema de BD, modelos del ORM y cualquier código que escriba en las tablas afectadas.

Luego, haz una copia de seguridad que realmente hayas probado. No te conformes con logs que digan “backup succeeded”. Restaura a una base separada, ejecuta una consulta simple para confirmar tablas clave y filas recientes, y verifica que la app puede conectar. Si no puedes restaurar, no tienes un backup utilizable.

Ahora reproduce la falla en un lugar seguro usando una copia de los datos de producción (o una instantánea anonimizada). Ejecuta el comando completo de migraciones exactamente como lo hace producción. Captura el primer error y el nombre del archivo de migración, porque el primer fallo suele ser la pista real.

Después elige tu enfoque de recuperación. Si el problema es pequeño (una columna faltante, una migración editada o una ejecución parcial), reconcilia: escribe una migración correctiva que mueva el esquema del estado actual al esperado. Si el historial está enredado (ediciones en conflicto, IDs duplicados, drift entre entornos), reconstruye: crea una baseline limpia desde el esquema actual y reinicia la cadena.

Antes de desplegar, haz una ejecución completa de extremo a extremo: parte de una base de datos vacía, aplica todas las migraciones, seed minimal y ejecuta una prueba rápida. Aquí es donde detectas el drift de “funciona en mi laptop”.

Si intentas arreglar migraciones en una codebase generada por IA (Lovable, Bolt, v0, Cursor, Replit), equipos como FixMyMess suelen empezar con este flujo de ensayo para que el cambio en producción sea predecible, no heroico.

Reconstruir una cadena de migraciones limpia (baseline, squash y reset)

Una cadena de migraciones limpia es lo que hace que los despliegues vuelvan a ser aburridos. Si necesitas arreglar migraciones rotas, no empieces borrando archivos. Decide si vas a estabilizar lo que existe o crear una nueva baseline bien documentada.

Baseline: cuándo crearla (y cuándo no)

Crea una nueva migración baseline cuando el esquema en producción sea correcto, pero el historial de migraciones esté desordenado, editado o fuera de orden. El objetivo es capturar el esquema actual como el nuevo punto de partida.

No crees una baseline si producción no es confiable (cambios manuales desconocidos, tablas faltantes o problemas de datos). En ese caso, primero repara el esquema y luego baselinea.

Squash y reset: mantener la historia segura

Si las migraciones ya están aplicadas en producción, evita reescribir la historia en su lugar. En su lugar, trata la cadena antigua como “legacy” y añade un punto de corte claro.

Un patrón seguro es:

• Congelar el estado actual: hacer backup de datos y registrar la versión de esquema en cada entorno.
• Generar una única migración “squashed” que coincida exactamente con el esquema actual.
• Marcarla como la nueva baseline (por ejemplo, con una nota en el repo y en la documentación de despliegue).
• Mantener las migraciones antiguas en una carpeta separada o sección claramente etiquetada, pero dejar de aplicarlas.
• Para nuevos entornos, ejecutar baseline + nuevas migraciones en adelante.

Imagina un prototipo donde local tiene 42 migraciones, staging 39 y prod tablas hotfixed añadidas a mano. Hacer squash desde local a ciegas no igualará prod. Lo correcto es baselinear desde el esquema que eliges como fuente de la verdad (usualmente prod) y luego aplicar cambios hacia adelante como nuevas migraciones.

Documenta la baseline en palabras sencillas: la fecha, el entorno fuente, la instantánea exacta del esquema y la regla para nuevos setups. Equipos como FixMyMess suelen añadir esta documentación como parte de la remediación de apps generadas por IA, porque los despliegues futuros dependen de ello.

Probar y desplegar la solución sin arriesgar datos reales

Trata tu arreglo de migraciones como un release, no como un parche rápido. El lugar más seguro para probarlo es un entorno de staging que coincida con producción: mismo motor y versión de BD, extensiones similares, mismas variables de entorno y una copia del esquema de producción (idealmente una porción anonimizada de datos).

Antes de probar nada, toma un backup reciente que puedas restaurar. Los planes de rollback suelen fallar porque asumen que las down-migrations desharán los cambios perfectamente. En incidentes reales, el rollback más realista es restaurar una snapshot.

Asegúrate de que las migraciones sean repetibles

Una migración que “funciona una vez” puede seguir siendo peligrosa. Ejecuta la cadena completa en staging, luego resetea esa base de staging y ejecútala otra vez. Quieres el mismo resultado ambas veces.

Atento a señales de alarma como timestamps usados como valores por defecto, backfills no deterministas o migraciones que dependen del contenido actual de tablas.

Valida la app, no solo el esquema

Después de las migraciones, arranca la app y prueba los flujos que importan: signup/login, crear y editar registros clave, búsqueda/filtrado y cualquier pantalla de administración. Luego dispara jobs y tareas programadas, porque a menudo tocan columnas que fueron renombradas o hechas non-null.

Mantén el despliegue pequeño y controlado:

• Anuncia una ventana de mantenimiento corta (aunque esperes cero downtime)
• Aplica las migraciones primero y luego despliega el código que espera el nuevo esquema
• Monitoriza errores y consultas lentas justo después del lanzamiento
• Estate listo para restaurar la base de datos si algo sale mal

Si la app es generada por IA, revisa dos veces por suposiciones ocultas de esquema en el código. FixMyMess ve a menudo prototipos donde la UI funciona localmente pero producción falla por migraciones faltantes, archivos editados o secretos que cambian el comportamiento entre entornos.

Errores comunes que empeoran los problemas de migraciones

La forma más rápida de convertir un lío de migraciones en una caída real es “parchar hasta que funcione” sin saber qué se ejecutó dónde. Cuando intentas arreglar migraciones rotas, el objetivo no es solo lograr que la app arranque. Es que todos los entornos vuelvan a una historia explicable y coherente.

Una trampa común es editar una migración antigua que ya se ejecutó en producción. Tu código ahora dice una cosa, pero prod ya hizo otra. Un compañero arranca setup nuevo, staging ejecuta una cadena distinta y creas dos líneas temporales que ya no coincidirán.

Otro error es “arreglar el drift” cambiando la base de datos manualmente primero. Por ejemplo, alguien añade una columna faltante directamente en prod para detener errores, pero los archivos de migración siguen sin coincidir. La app parece bien por un día, luego el próximo deploy intenta añadir la columna otra vez, falla y bloquea todas las migraciones futuras.

Aquí errores que se repiten en apps generadas por IA:

• Tratar a las down-migrations como red de seguridad, aunque nadie probó rollback con datos reales
• Omitir constraints e índices porque la app “funciona” sin ellos y luego sufrir consultas lentas y datos malos
• Aplicar parches rápidos como borrar una fila de la tabla de migraciones para silenciar errores
• Renombrar tablas o columnas fuera de migraciones y luego sorprenderse por el drift del ORM
• Mezclar cambios de esquema y backfills de datos en una sola migración, lo que complica la recuperación

Los arreglos rápidos suelen ocultar el síntoma pero mantienen el drift. Puedes pasar la falla inmediata, pero el siguiente entorno (o el siguiente desarrollador) se romperá de otra forma.

Si heredaste un prototipo de Lovable, Bolt o Replit, asume que las migraciones se generaron con prisa. Equipos como FixMyMess suelen empezar confirmando qué se ejecutó en producción y luego reconstruyendo un camino limpio hacia adelante sin reescribir la historia en su lugar.

Checklist rápido antes de pulsar deploy

Si tus migraciones fueron generadas por una herramienta de IA, asume que hay huecos. Un checklist tranquilo te ayuda a evitar el error que más duele: enterarte en producción.

Antes de tocar producción

Haz un backup y prueba que funcione. “Backup hecho” no es lo mismo que “restore probado.” Restaura a una base nueva, abre la app y confirma que las tablas clave y registros recientes aparecen.

Después, haz un diff de esquema entre todos los entornos que importan (local, staging, producción). Debes saber qué es diferente antes de ejecutar nada. Si producción tiene una columna extra o falta un índice, apúntalo.

Elige una sola fuente de la verdad y sé explícito. Decide si la referencia es el esquema de producción, una rama de migraciones específica o un entorno conocido bueno. Pon esa elección en tus notas para que nadie “arregle” el lado equivocado a mitad del deploy.

Demuestra que la cadena de migraciones es segura

Ejecuta la secuencia completa en una copia parecida a producción. Eso implica una copia de datos de prod (o datos sanitizados con la misma forma), la misma versión del motor de BD y el mismo comando de migraciones que usarás en deploy. Vigila locks largos, constraints que fallan y diferencias “funciona en mi máquina”.

Antes de desplegar, asegúrate de que tu plan incluya validación y rollback:

• Validación: login básico, algunas lecturas/escrituras clave y comprobación rápida de tablas/contadores críticos
• Rollback: pasos claros para revertir la versión de la app y restaurar la base de datos si es necesario

Ejemplo: si staging está “adelantado” a prod porque una herramienta de IA creó una migración extra localmente, pausa y reconcilia esa diferencia primero. Enviar con ese drift suele acabar en un deploy fallido o, peor, en inconsistencias silenciosas de datos.

Si heredaste una codebase AI-generada, FixMyMess suele comenzar aquí: una auditoría gratuita que confirma la fuente de la verdad, mapea el drift y verifica el plan de recuperación antes de hacer cualquier cambio en vivo.

Ejemplo: recuperar un prototipo que driftó entre local y prod

Un fundador envía un prototipo generado por IA que funciona en su laptop. Luego el deploy a producción falla en la migración 012 con un error “columna ya existe”. La app no arranca y cada re-deploy repite la falla.

Tras una rápida revisión, el problema no es “un archivo malo”. Dos ramas introdujeron cambios ligeramente distintos en la misma tabla (por ejemplo, ambas añadieron un campo status a users, pero una lo dejó nullable y la otra puso un default). Localmente, el desarrollador aplicó las migraciones de una rama. En producción, un deploy anterior aplicó las de la otra. Ahora el historial de migraciones y el esquema real difieren.

La salida más segura es tratar a producción como la fuente de la verdad, baselinear desde el esquema de producción y avanzar solo hacia adelante.

Así es en la práctica:

• Congelar despliegues y tomar un backup completo (y confirmar que puedes restaurarlo).
• Inspeccionar el esquema de producción y la tabla de migraciones para ver qué se ejecutó realmente.
• Crear una migración baseline que coincida con producción tal como está hoy (sin cambios, solo alineamiento).
• Escribir una nueva cadena limpia hacia adelante que aplique los cambios faltantes en pasos pequeños y explícitos.

Luego validas la app usando flujos reales, no solo “las migraciones se ejecutaron”. En este ejemplo probarías login (sesiones, reset de contraseña), facturación (webhooks, facturas) y los dashboards que dependen de la tabla cambiada.

Este es un patrón común cuando necesitas arreglar migraciones rotas en apps generadas por IA: no intentes forzar que producción coincida con un historial local desordenado. Haz que la historia coincida con producción y luego añade migraciones seguras y hacia adelante. Si no sabes qué esquema es correcto, FixMyMess puede auditar primero la codebase y el rastro de migraciones para que no aprendas por las malas en producción.

Próximos pasos: mantener las migraciones estables y saber cuándo pedir ayuda

Después de que las migraciones vuelvan a funcionar, la meta es consistencia aburrida. Empieza por decidir si necesitas un arreglo pequeño (una migración mala, un archivo faltante, un orden equivocado) o una reconstrucción completa (historial editado, entornos en desacuerdo y no puedes confiar en lo que “latest” significa). Si sigues viendo sorpresas tras una ejecución limpia en una base nueva, inclínate por reconstruir.

Una forma simple de prevenir problemas repetidos es escribir un breve “contrato de esquema” que todos sigan. Guárdalo en tu repo como una nota. No tiene que ser sofisticado, pero sí claro.

• Crear solo nuevas migraciones; nunca editar migraciones antiguas después de enviarlas
• Cada migración debe ser reversible (o explicar por qué no lo es)
• Una persona se encarga del merge final cuando varias ramas tocan la base de datos
• Los cambios en el esquema de producción ocurren solo vía migraciones, no por ediciones manuales en consola
• Una instalación desde cero (BD vacía -> última) debe funcionar en CI antes de desplegar

Si tu app fue generada por herramientas como Lovable, Bolt, v0, Cursor o Replit, espera más drift oculto de lo habitual. El código puede crear tablas al arrancar, seedear datos en lugares inesperados o divergir entre SQLite local y Postgres en producción. Trata la base de datos como una parte de primera clase de la app, no como algo secundario.

Sabe cuándo traer una segunda opinión. Si tienes datos de clientes reales, múltiples entornos en desacuerdo o dudas sobre si un “arreglo” podría eliminar columnas o reescribir restricciones, pausa. FixMyMess puede realizar una auditoría gratuita del código para localizar problemas de migraciones y proponer arreglos seguros antes de cualquier compromiso, lo que suele ser más rápido que adivinar bajo presión.