Cuando una empresa se plantea sacar su base de Oracle hacia la nube, la conversación arranca casi siempre por el volumen. Cuántos terabytes, cuántas tablas, cuántas filas. Es la pregunta natural y es la equivocada.
Nosotros migramos 11 TB desde Oracle hacia BigQuery para Servinformación: 11.360 millones de filas, con 100% de coincidencia verificada entre origen y destino. Y si algo aprendimos en ese proyecto es que el volumen es un problema de ingeniería resuelto. El problema real es otro.
La pregunta que decide si el proyecto termina
Al final de cualquier migración hay un momento incómodo. Los datos ya están del otro lado, los tableros funcionan, todo se ve bien. Y entonces alguien pregunta lo único que importa:
¿Está todo, y está igual?
Si no hay una respuesta demostrable a eso, nadie apaga el sistema viejo. Y una migración que no permite apagar el origen no es una migración: es una copia cara. La empresa termina pagando dos infraestructuras, dos licencias y dos equipos de soporte, con la promesa de que "el año que viene sí apagamos Oracle".
Hemos visto ese limbo durar años. No por incompetencia técnica, sino porque nadie construyó la evidencia mientras movía los datos.
Por qué a esta escala se rompe lo que funciona con una base mediana
Las estrategias que sirven para migrar unos cientos de gigas dejan de servir cuando hay miles de millones de filas.
- Una extracción completa no cabe en una ventana de mantenimiento ordinaria. Hay que pensar en sincronización incremental desde el primer día, no como parche final.
- Los tipos numéricos y de fecha de Oracle no tienen equivalente exacto en BigQuery. Una conversión descuidada pierde precisión en silencio: sin errores, sin avisos, con un `NUMBER` que se redondea y una fecha que cambia de zona horaria. El dato llega, pero ya no es el mismo.
- Verificar por muestreo da una probabilidad, no una garantía. Con once mil millones de filas, un muestreo excelente sigue dejando millones de registros que nadie miró.
Lo que hicimos distinto
Construimos el sistema de migración alrededor de la verificación, no del traslado. La comprobación de integridad entre origen y destino es parte del proceso, no una auditoría posterior que se hace si queda tiempo y presupuesto — que nunca queda.
El sistema es compatible con Oracle 11g, 12c, 18c, 19c y 21c y trabaja sobre SQL estándar, sin depender de características propietarias de una versión concreta. Eso importa más de lo que parece: muchas herramientas de migración asumen una versión reciente, y las bases que de verdad necesitan salir de Oracle suelen ser las viejas.
En un segundo alcance sobre los entornos de desarrollo, QA y producción —más de 7 TB— una ventana estimada en una semana se resolvió en 20 horas de sincronización, también con coincidencia total.
Qué preguntar antes de contratar una migración
Si está evaluando mover una base pesada, tres preguntas separan a quien lo ha hecho de quien lo va a intentar con usted:
- ¿Cómo van a demostrar que no falta nada? Y si la respuesta es "hacemos muestreo", pregunte qué porcentaje y qué pasa con el resto.
- ¿Qué van a hacer con los tipos de dato que no tienen equivalente? Debe haber una decisión explícita por cada uno, no un mapeo automático.
- ¿Cuándo podremos apagar el origen? Si no hay una fecha con criterio de aceptación detrás, no la habrá nunca.
No todo tiene que migrarse
Una cosa que rara vez se dice: en casi todas las bases que hemos revisado, buena parte de lo que vive en el motor licenciado es histórico y consulta, no operación. Esa parte se puede mover sin tocar la disponibilidad de nada, y el costo de licencia y soporte baja de forma permanente.
Antes de planear una migración completa, vale la pena saber qué proporción de sus datos está en esa categoría. Suele ser mayor de lo que la gente espera.