La decisión de reparar un backend de Supabase

Parece obvio hasta que una aplicación averiada en producción hace que cada defecto parezca un defecto de la plataforma. He visto equipos planear una migración de seis semanas porque un índice ausente ralentizaba un panel. También los he visto pasar meses puliendo políticas alrededor de un modelo de datos que nunca podría expresar los permisos prometidos a los clientes. La decisión necesita pruebas del sistema en funcionamiento, no la frustración del último incidente.

Usa cinco pruebas: complejidad de consultas, expansión de RLS, dependencia de funciones Edge, requisitos de cumplimiento y coste proyectado. Ninguna funciona por sí sola. Una consulta compleja puede estar perfectamente sana. Cincuenta políticas pueden inspirar más confianza que cinco imprecisas. Una factura de alojamiento baja puede ocultar una recuperación manual cara. La pregunta útil es si cada fuente de dificultad puede repararse en el sistema actual y si el sistema reparado seguirá sirviendo para los próximos dos años de uso previsto.

Repara los defectos cuando la arquitectura aún encaje

La reparación es la mejor opción cuando los límites previstos del backend todavía coinciden con el producto. Si PostgreSQL sigue siendo un sistema de registro sensato, el acceso directo del cliente aún sirve a la aplicación y Supabase Auth, Storage o Realtime cumplen los requisitos reales, cambiar de plataforma sustituye defectos conocidos por otros desconocidos.

Clasifica cada queja antes de hablar de un destino. Colócala en uno de cuatro grupos: defecto de implementación, falta de disciplina operativa, incompatibilidad arquitectónica o requisito externo. Una clave foránea ausente, un secreto de rol de servicio expuesto y un predicado de política sin índice son defectos de implementación. Los cambios de esquema hechos solo desde el panel de producción apuntan a falta de disciplina. Un flujo de trabajo que exige tareas largas e intensivas en CPU puede ser incompatible con las funciones Edge. Un contrato que exige una región de despliegue o un control de auditoría que el plan elegido no ofrece es un requisito externo.

Solo los dos últimos grupos hacen probable una migración. Los dos primeros suelen pedir una reparación. Esta clasificación evita un fallo conocido: un equipo migra las tablas y luego recrea en otro proveedor la misma autorización permisiva, la ausencia de migraciones y la monitorización débil.

La reparación también gana cuando el equipo no puede describir una arquitectura de destino verificada. «Un backend personalizado» no es un destino. Es la obligación de elegir un framework de API, un sistema de identidad, alojamiento de base de datos, estrategia de conexiones, almacenamiento de objetos, ejecutor de tareas en segundo plano, sistema de secretos, conjunto de registros, proceso de copias de seguridad y ruta de despliegue. Cada elección necesita un responsable. Si esas decisiones no se han tomado, la estimación de migración contiene sobre todo espacios en blanco.

Define el límite de la reparación antes de empezar. Por ejemplo: restaurar el historial de migraciones, impedir que el navegador acceda a credenciales privilegiadas, lograr que pasen las pruebas de autorización, situar los recorridos de usuario más lentos dentro de un presupuesto de latencia acordado y documentar ensayos de restauración. Si esa reparación acotada produce un backend que el equipo puede operar, la migración no tiene justificación comercial. Si el límite sigue creciendo porque cada arreglo descubre una suposición incompatible, esa prueba respalda el traslado.

La complejidad de las consultas necesita planes, no opiniones

Un SQL complejo no justifica por sí solo una migración. PostgreSQL ejecuta la base de datos que hay debajo de Supabase, así que mover el mismo esquema y las mismas consultas a otro servicio gestionado de PostgreSQL no hará desaparecer las uniones deficientes, los índices ausentes, las lecturas de filas anchas ni el acceso excesivamente conversador del cliente.

Empieza con pruebas de la carga. La documentación de Supabase recomienda pg_stat_statements para encontrar sentencias frecuentes y caras. Captura las llamadas, el tiempo total de ejecución, el tiempo medio, las filas y la consulta normalizada. No ordenes solo por tiempo medio. Una consulta que tarda 40 milisegundos y se ejecuta un millón de veces puede consumir más capacidad que un informe de dos segundos abierto dos veces al día.

Esta consulta ofrece un primer corte útil:

select
  queryid,
  calls,
  round(total_exec_time::numeric, 1) as total_ms,
  round(mean_exec_time::numeric, 1) as mean_ms,
  rows,
  left(query, 180) as sample
from pg_stat_statements
where calls >= 20
order by total_exec_time desc
limit 25;

Su salida tiene una fila por sentencia normalizada, con el identificador de consulta, el número de llamadas, el tiempo acumulado, el tiempo medio, las filas afectadas y una muestra abreviada. Guarda ese resultado durante un periodo representativo del negocio. Una base de datos de pruebas tranquila demuestra poco sobre el tráfico de producción.

Para las sentencias que dominan la latencia o el tiempo de base de datos, ejecuta EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) con datos representativos y seguros. ANALYZE ejecuta la sentencia, así que usa una transacción que puedas revertir para las escrituras y no lo ejecutes a ciegas en producción. Busca exploraciones secuenciales de relaciones grandes, diferencias graves entre filas estimadas y reales, bucles repetidos, lecturas de disco y ordenaciones que se desbordan. Esos hallazgos apuntan a índices, predicados reescritos, mejores estadísticas, selecciones más estrechas o un modelo de datos distinto.

Repara cuando un número reducido de planes identificables explique la mayor parte del problema y los cambios normales de PostgreSQL lo resuelvan. Considera migrar cuando la propia carga entre en conflicto con la forma del servicio elegido: análisis prolongados que interfieren con el tráfico transaccional, extensiones necesarias que no están disponibles, un comportamiento de conexiones que no satisface el modelo de concurrencia de la aplicación o datos que deben estar cerca de otro sistema y un tiempo de red medido que domina las solicitudes.

No confundas el número de solicitudes a la API con la complejidad de las consultas. Un frontend generado por IA suele obtener una lista y después pedir los datos relacionados una vez por fila. La base de datos puede ejecutar consultas sencillas mientras la página sufre por los viajes de ida y vuelta. Consolidar el acceso en una vista, una función RPC o un único endpoint del servidor es una reparación. Mover ese patrón intacto solo cambia el lugar al que llega la factura de latencia.

Prueba las reparaciones contra una carga, no contra una consulta escogida a mano. Captura un conjunto reproducible de operaciones de lectura y escritura para los recorridos de usuario más activos, elimina los datos personales de los accesorios de prueba y ejecútalo antes y después de cada cambio. Registra la mediana y el tiempo de las solicitudes lentas, la CPU de la base de datos, el número de conexiones, las filas leídas y la tasa de errores. Un índice nuevo que ayuda a un filtro puede ralentizar las escrituras o consumir suficiente almacenamiento para cambiar el cálculo de costes. Una vista materializada puede acelerar un informe e introducir a la vez un retraso de actualización que el producto no acepta.

La presión sobre las conexiones necesita el mismo diagnóstico. Los clientes del navegador, los procesos del servidor, los agrupadores de transacciones y las sesiones directas de base de datos se comportan de forma distinta. Cuenta las sesiones activas y en espera durante los picos y averigua qué componente las posee. Si una aplicación generada abre nuevas conexiones de servidor por solicitud, corrige la reutilización de conexiones antes de comprar más capacidad de cómputo. Muévete solo cuando los requisitos verificados de concurrencia y transacciones sigan siendo incompatibles después de corregir el cliente y la configuración del agrupador.

La expansión de RLS se mide por su comportamiento

La expansión de RLS se convierte en señal de migración cuando nadie puede predecir ni probar con fiabilidad quién puede leer y cambiar cada fila. El número de políticas por sí solo no dice casi nada. Un conjunto más grande de políticas estrechas puede ser más seguro que una política compacta llena de comprobaciones anidadas de pertenencia y claims JWT mutables.

Haz inventario de las políticas desde la base de datos en vez de confiar en un diagrama:

select
  schemaname,
  tablename,
  policyname,
  roles,
  cmd,
  permissive,
  qual,
  with_check
from pg_policies
order by schemaname, tablename, cmd, policyname;

Revisa la salida como una matriz de autorización. Para cada tabla y operación expuestas, indica los roles que actúan, la condición de fila, la comprobación de inserción o actualización y la denegación esperada. Marca las subconsultas de pertenencia duplicadas, las políticas que dependen de metadatos editables por el usuario, las condiciones amplias con true, las columnas de tenant incoherentes y las tablas expuestas por la API sin una política intencionada.

La guía de RLS de Supabase hace una distinción precisa que muchas aplicaciones generadas pasan por alto. Los usuarios pueden actualizar raw_user_meta_data, por lo que no es un lugar seguro para claims de autorización. raw_app_meta_data no puede modificarlo el usuario y puede contener datos de autorización, aunque el contenido del JWT puede quedar desactualizado hasta renovar el token. No es un detalle menor de nomenclatura. Pon un rol en el claim equivocado y un usuario podría concederse acceso.

Las correcciones de rendimiento deben llegar después de la corrección funcional. Indexa las columnas usadas en predicados de políticas. Cuando la semántica lo permita, envolver auth.uid() en una subconsulta escalar permite que el planificador cree un plan inicial y evite evaluar la función para cada fila. Mantén filtros explícitos en las consultas de la aplicación aunque una política ya aplique el mismo límite del tenant, porque el filtro ayuda al planificador a elegir una ruta más estrecha. Ninguno de esos cambios arregla un modelo de autorización que el equipo no puede describir.

Crea pruebas de denegación antes de cambiar las políticas. Ejecuta los mismos intentos de selección, inserción, actualización y borrado como usuario anónimo, miembro normal, miembro de otro tenant, administrador y cuenta suspendida si existe ese estado. Comprueba tanto las filas permitidas como las prohibidas. Las pruebas con el rol de servicio no sustituyen las pruebas de usuario porque el acceso privilegiado puede omitir RLS.

Repara RLS cuando el producto tenga un modelo de tenants estable y las políticas puedan reducirse a predicados reutilizables con nombre y una matriz de pruebas completa. Migra o añade una capa de autorización dedicada cuando los permisos dependan de relaciones que cambian deprisa, las decisiones necesiten contexto externo a PostgreSQL, los clientes exijan explicaciones de políticas que el modelo actual no puede producir o cada función nueva obligue a editar docenas de políticas sin relación. Incluso entonces, migrar no elimina la necesidad de proteger la base de datos. Cambia el lugar donde se toma la decisión principal.

Presta atención a la propiedad durante las escrituras. Una política de selección puede ocultar bien las filas de otro tenant mientras una condición with check incompleta permite que un usuario inserte una fila con el identificador de tenant de otra persona. Las actualizaciones necesitan una regla para decidir a qué filas existentes puede dirigirse el usuario y otra para definir qué puede contener la nueva fila. Prueba esas rutas por separado. Las aplicaciones generadas suelen ejercitar solo lecturas correctas, por lo que la escalada mediante escrituras sobrevive hasta producción.

Las funciones auxiliares centrales pueden reducir predicados repetidos, pero también pueden ocultar privilegios. Inspecciona el propietario, la ruta de búsqueda del esquema, el modo de ejecución y los permisos de cada función security definer mencionada por una política. Califica los nombres de las relaciones y mantén pequeña la superficie invocable. Si el equipo no puede explicar por qué una función auxiliar se ejecuta con permisos elevados, expandirla por todo el esquema aumenta el riesgo en lugar de simplificar el sistema.

La dependencia de funciones Edge define el tamaño del traslado

Las funciones Edge importan porque revelan qué parte del backend es algo más que una base de datos. Un proyecto con dos manejadores de webhooks supone una migración distinta de otro en el que cada escritura privilegiada, devolución de pago, tarea programada, acción de correo e integración externa pasa por funciones Deno.

Crea un registro de funciones con una fila por cada función desplegada. Anota quién la llama, el método de autenticación, los secretos, las operaciones de base de datos, los servicios externos, el comportamiento ante tiempos de espera, la política de reintentos, el mecanismo de idempotencia, el comando de despliegue y las invocaciones medias y máximas. Los archivos de código fuente no mostrarán un secreto del panel del proveedor ni un webhook externo configurado meses atrás.

Supabase documenta las funciones Edge como funciones TypeScript en un entorno compatible con Deno. Eso proporciona cierta portabilidad al código, pero el comportamiento que las rodea todavía exige trabajo: enrutamiento de la puerta de enlace, manejo de JWT, secretos de entorno, invocaciones programadas, envío de registros, despliegue y ejecución regional. Trata «el código es TypeScript» como un dato útil, no como un plan de migración.

Repara cuando las funciones sean adaptadores delgados. Una buena reparación extrae las reglas de negocio a módulos normales, valida las entradas en el límite, usa tiempos de espera explícitos para llamadas externas, hace idempotente el procesamiento de webhooks y mueve el trabajo largo a una cola o un worker adecuado para su duración. Los límites oficiales incluyen memoria, tiempo de CPU, tiempo total, tiempo de inactividad de las solicitudes, tamaño del paquete y número de secretos. Consulta los límites actuales del plan activo en vez de copiar una cifra en un documento de arquitectura que quedará obsoleto.

La migración resulta atractiva cuando el límite del entorno forma parte de la carga normal y no de un defecto ocasional. El procesamiento de imágenes, la conversión de documentos grandes, los trabajos largos de IA, las exportaciones pesadas de datos y los flujos duraderos suelen necesitar workers con concurrencia controlada, colas persistentes y un estado explícito de reintentos. Puedes conservar Supabase para PostgreSQL y Auth mientras mueves solo esos trabajos. Una migración parcial suele eliminar la restricción sin sustituir la base de datos.

Estima el traslado por dependencia, no por número de archivos. Un webhook de pagos de 80 líneas con un comportamiento de repetición sin documentar puede tener más riesgo que veinte endpoints de solo lectura. Para cada función, exige una prueba de contrato que envíe la misma solicitud a las implementaciones antigua y nueva, normalice los campos generados por el proveedor y compare el estado, el cuerpo, los efectos en la base de datos y las llamadas salientes. Sin ese arnés, los equipos descubren las diferencias semánticas por los informes de clientes.

El cumplimiento puede imponerse a la comodidad técnica

El cumplimiento solo justifica una migración cuando el servicio, el plan, la configuración y el proceso operativo disponibles no pueden satisfacer un requisito escrito. La ansiedad imprecisa por los datos regulados hace perder tiempo. Una cláusula firmada con el cliente, la declaración de control de un auditor o una restricción legal ofrecen algo comprobable.

Convierte el requisito en una matriz de controles. Indica los datos afectados, las regiones permitidas, las expectativas de cifrado, el periodo de conservación, el procedimiento de borrado, el objetivo de recuperación, las normas de acceso del personal, las pruebas de auditoría, las condiciones de notificación de incidentes, los subencargados y los documentos contractuales. Asigna cada fila a la plataforma o a tu equipo. El alojamiento gestionado nunca transfiere toda la responsabilidad al proveedor.

Comprueba en la documentación del plan y los documentos contractuales actuales de Supabase los controles necesarios. Funciones como registros de auditoría, conservación de logs, recuperación a un punto en el tiempo, inicio de sesión único, roles de proyecto, redes privadas, elección de regiones y compatibilidad con cargas reguladas pueden variar según el plan y el acuerdo. Un control ausente en el plan actual puede exigir una mejora de plan, no una migración. Compara la mejora con un destino realista que incluya las mismas obligaciones de pruebas y soporte.

Las copias de seguridad exigen un cuidado especial. La documentación de copias de Supabase dice que las copias de la base de datos no contienen los objetos guardados mediante la API de Storage, solo sus metadatos. Por tanto, restaurar la base de datos no restaura un objeto borrado. Si tu plan de recuperación supone que un botón rebobina ambos, el plan está equivocado. Repáralo con protección separada para los objetos y un ensayo de restauración, o elige una arquitectura cuyos controles de recuperación coincidan con el requisito.

La migración se justifica cuando el proveedor no puede firmar el acuerdo necesario, la región o el límite de red requeridos no están disponibles, la conservación de pruebas no puede cumplir el contrato o la organización debe controlar la infraestructura de una forma que el servicio alojado no permite. Anota el control fallido y la prueba del destino antes de moverte. El autoalojamiento puede dar control, pero también hace responsable al equipo de los parches, la monitorización, la integridad de las copias, las revisiones de acceso y las pruebas de incidentes.

No uses la migración para evitar comprender los flujos de datos. Necesitas el mismo inventario para migrar con seguridad: tablas, buckets de objetos, registros de autenticación, logs, secretos, réplicas, exportaciones analíticas y procesadores externos. El trabajo de cumplimiento suele sacar a la luz flujos sin documentar. Ese descubrimiento puede llevar a una reparación menor o confirmar que el diseño actual debe cambiar.

El coste proyectado incluye personas y riesgo de transición

El coste proyectado debe comparar el sistema reparado, el estado estable tras la migración y la propia transición con la misma previsión de demanda. Comparar la factura actual de Supabase con la línea de base de datos de otro proveedor produce una ficción.

Modela el coste por factor de carga. Usa usuarios activos mensuales cuando afecten a la autenticación, crecimiento del cómputo y almacenamiento de la base de datos, tráfico saliente por origen y destino, mensajes Realtime y conexiones máximas, volumen y operaciones de Storage, invocaciones de funciones Edge, volumen y conservación de logs, funciones de copia o recuperación, soporte y complementos obligatorios del plan. Obtén los precios unitarios actuales de ambos proveedores cuando se tome la decisión. Guarda cada precio y cuota incluida en una hoja de supuestos con fecha de captura, porque los precios cambian.

Usa tres casos de demanda en vez de una previsión falsamente precisa: esperado, alto y contracción. La fórmula puede ser sencilla:

monthly platform cost =
  base plans
  + database compute and storage
  + network egress
  + authentication usage
  + realtime usage
  + function usage
  + logs, backups, and support

monthly operating cost =
  engineering hours
  + incident response
  + security and compliance work
  + vendor management

Estima las horas de ingeniería a partir del trabajo real: despliegues fallidos, revisiones manuales de políticas, ajuste de la base de datos, depuración de funciones, pruebas de restauración y escaladas de soporte. No asignes cero al trabajo absorbido por un fundador. Sigue retrasando el trabajo de producto y ventas.

El coste de transición incluye entornos paralelos, copia de datos, copia de objetos, captura de cambios si hace falta, escrituras dobles si se eligen, pruebas de contrato, actualizaciones de clientes, observabilidad, revisión de seguridad, soporte durante el corte y capacidad de vuelta atrás. Añade como intervalo la exposición contractual o de ingresos por tiempo de inactividad y datos incoherentes, no como una cifra exacta inventada. Una migración que ahorra unos cientos al mes puede tardar años en amortizarse.

Calcula el mes de equilibrio:

break_even_month =
  transition_cost /
  (repaired_monthly_cost - migrated_monthly_cost)

Si el denominador es cero o negativo, el coste no respalda la migración. Si el resultado supera la vida útil probable de la arquitectura, el ahorro es teórico. Repite la fórmula con el caso de demanda alta, porque un destino podría salir más barato solo a partir de un umbral, y con la contracción, porque la infraestructura fija y la plantilla pueden penalizar un uso menor.

Repara cuando el ajuste, el cambio de tamaño, el archivado o el traslado de una carga modifiquen bastante la curva. Migra cuando persista un factor de coste estructural después de reparar, como el tráfico saliente inevitable, un plan premium exigido sobre todo por un control o el trabajo dedicado a compensar una incompatibilidad constante de la plataforma.

Una decisión puntuada deja al descubierto los supuestos débiles

Una tabla de puntuación solo ayuda cuando cada nota apunta a una prueba. No debe ocultar el criterio tras la aritmética. Úsala para mostrar qué supuestos cambian la recomendación y qué preguntas siguen abiertas.

Puntúa cada factor de 0 a 3 tanto para reparar como para migrar. Cero significa que la opción no satisface el requisito. Tres significa que lo satisface con pruebas demostradas. Trata el cumplimiento y la seguridad como puertas: si una opción no puede cumplir un control obligatorio, su puntuación total no la salva.

Usa estos factores:

1. Encaje de la carga de consultas, respaldado por estadísticas de sentencias y planes de ejecución.
2. Claridad de la autorización, respaldada por el inventario de políticas y las pruebas de denegación.
3. Encaje del entorno de ejecución, respaldado por el registro de funciones Edge y la duración de la carga.
4. Encaje de cumplimiento, respaldado por la matriz de controles y los documentos contractuales.
5. Coste durante el periodo previsto, incluida la transición y la mano de obra.

Añade operabilidad, habilidades del equipo, calidad de la vuelta atrás e interrupción de las entregas si pueden cambiar la elección. Registra un nivel de confianza junto a cada puntuación. Una nota de coste construida con un mes de datos de uso incompletos no debe parecer igual a una nota de cumplimiento confirmada en un acuerdo firmado.

Define reglas de decisión antes de puntuar. Una regla práctica consiste en reparar cuando se superan todas las puertas obligatorias, el alcance de la reparación está acotado y la amortización de la migración queda fuera del periodo previsto. Migra cuando falle una puerta obligatoria sin un plan creíble o cuando varias restricciones medidas sobrevivan a una reparación con plazo fijo. Elige un híbrido cuando un servicio, normalmente cómputo prolongado o análisis, cause la mayor parte de la incompatibilidad.

La tabla también frena los argumentos de coste hundido. El esfuerzo anterior no hace adecuado el backend actual, y el enfado no hace adecuada una alternativa. Las pruebas pueden cambiar durante la evaluación. Si añadir dos índices y corregir un predicado de tenant elimina el supuesto problema de escala, actualiza la puntuación sin defender la idea original de migrar.

FixMyMess usa un diagnóstico del código y verificación experta para separar los defectos reparables de las aplicaciones generadas por IA de la arquitectura que necesita reconstruirse, y su auditoría de código gratuita puede proporcionar ese primer inventario acotado. La decisión sigue en manos de los propietarios de la aplicación, sobre todo cuando están en juego contratos, tolerancia al riesgo y carga futura.

Haz el corte solo con una vuelta atrás probada

Una decisión de migración está incompleta hasta que el equipo puede describir el movimiento de datos, la validación, el corte y la vuelta atrás. «Exportar e importar PostgreSQL» cubre solo una parte de un backend de Supabase.

Haz inventario de esquemas de base de datos, extensiones, roles, políticas RLS, funciones, triggers, tareas programadas, usuarios de Auth y correspondencias de identidad, objetos y metadatos de Storage, suscripciones Realtime, funciones Edge, secretos, registros de webhooks, DNS y cada configuración de cliente. Decide qué se mueve, qué permanece y qué se retira. Conserva identificadores de usuario estables cuando sea posible o asígnalos de forma explícita, porque las filas de autorización y propiedad suelen depender de ellos.

Elige una migración con tiempo de inactividad para un producto pequeño cuando se admita una ventana de mantenimiento. Es más fácil razonar sobre ella que sobre las escrituras dobles. Para un traslado con poco tiempo de inactividad, establece una copia inicial, replica los cambios posteriores de la base de datos, copia los objetos con sumas de verificación, congela los cambios de esquema, valida el retraso y planea cómo cambiarán las escrituras finales. Escribir dos veces desde el código de la aplicación parece seguro, pero crea reglas de conflicto y combinaciones de fallos que muchos equipos pequeños no pueden probar.

Define las comprobaciones de aceptación antes de copiar datos. Compara el número de filas por tenant y tabla, sumas o hashes de campos estables elegidos, número de huérfanos, número y sumas de verificación de objetos, resultados de pruebas de políticas, pruebas de contratos API y una muestra de recorridos críticos de usuario. Los totales pueden coincidir mientras la propiedad es incorrecta, así que valida las relaciones y el acceso mediante roles de usuario reales.

Mantén el origen en modo de solo lectura o recuperable de otra forma durante un periodo acordado después del corte. Expresa el disparador de vuelta atrás con medidas: tasa de errores, registros ausentes, fallos de autenticación, discrepancias en devoluciones de pagos o retraso de replicación inaceptable. Indica quién puede ordenar la vuelta y cómo regresarán al sistema anterior las escrituras hechas después del corte. Un plan de vuelta atrás que pierde escrituras nuevas es un trueque de emergencia, no una vuelta completa.

Para una reparación, aplica la misma disciplina a menor escala. Toma una copia verificada, aplica migraciones mediante archivos versionados, ejecuta pruebas de políticas y contratos, vigila los errores de la base de datos y de la aplicación, y prepara un cambio reversible cuando PostgreSQL lo permita. La guía de migraciones de Supabase advierte que los cambios remotos desde el panel omiten el historial local de migraciones; extrae el estado remoto existente, reconcilia el historial y deja de hacer cambios de producción sin registrar.

La autenticación necesita su propio ensayo. Los hashes de contraseñas, vínculos de identidades sociales, inscripción multifactor, tokens de actualización, plantillas de correo, reglas de redirección y duración de las sesiones no se transfieren automáticamente con las tablas. Decide si los usuarios mantienen las sesiones activas, vuelven a iniciar sesión o restablecen sus credenciales. Prueba la invitación, recuperación de contraseña, vinculación de cuentas y borrado de cuentas en el destino. Una migración que conserva las filas de perfil pero bloquea a sus propietarios ha fallado.

Storage también necesita dos validaciones. Primero compara el inventario de objetos, tamaño en bytes, tipo de contenido y suma de verificación. Después prueba el acceso tal como lo hace la aplicación, incluido el acceso firmado, los objetos públicos, la sustitución y el borrado. Las filas de la base de datos pueden señalar objetos que nunca se copiaron, mientras los objetos copiados pueden hacerse públicos por una regla de bucket modificada. Conserva los registros de transferencia el tiempo suficiente para investigar el aviso de un cliente después del corte.

Haz un ensayo general con una copia reciente y desprovista de datos sensibles, y registra la duración de cada fase. El ensayo debe producir los comandos, responsables, puntos de control y condiciones de aborto que se usarán el día real. Si la sincronización final de datos tarda más que la ventana de mantenimiento o la validación no puede terminar antes de reabrir las escrituras, cambia el plan antes de producción en vez de esperar que los operadores trabajen más rápido bajo presión.

La elección está lista cuando una opción ha superado los controles obligatorios, ha resistido pruebas representativas y ha mostrado una carga total menor con previsiones creíbles. Si ninguna lo ha hecho, sigue investigando. Los datos de producción no premian una confianza que va por delante de las pruebas.