Migrar de Oracle a BigQuery: lo que cuesta

Casi siempre la conversación empieza por la licencia. Una organización mira lo que paga por Oracle, mira lo que costaría el mismo dato en BigQuery, y la diferencia parece justificar el proyecto sola.

La diferencia es real. Pero el ahorro de licencia es la parte del costo que se puede calcular en una hoja de cálculo, y por eso es la que menos sorpresas da. Las sorpresas están en el resto.

Lo que no equivale

Oracle y BigQuery no son la misma cosa con otro nombre. Son modelos distintos, y las diferencias cuestan trabajo:

• Los tipos no son iguales. NUMBER sin precisión declarada admite cosas que NUMERIC no. Las fechas de Oracle llevan hora; las de BigQuery distinguen DATE de DATETIME de TIMESTAMP, y elegir mal corre los datos una zona horaria entera.
• No hay claves foráneas que obliguen. BigQuery las admite como declaración informativa, no las hace cumplir. La integridad que el motor viejo garantizaba pasa a ser responsabilidad del proceso de carga.
• Los índices no existen como tales. Lo que en Oracle se resolvía creando un índice, aquí se resuelve particionando y agrupando. Es otra forma de pensar el mismo problema.
• PL/SQL no se traduce. Procedimientos, funciones y disparadores hay que reescribirlos o sacarlos del motor y ponerlos en otra capa. Si el negocio vive dentro de la base, esa es la mayor parte del proyecto.

El costo que aparece después

BigQuery cobra por dato procesado. Una consulta que en Oracle costaba lo mismo se ejecutara una vez o mil, aquí cuesta cada vez.

Eso cambia el diseño. Una tabla sin particionar obliga a leerla entera en cada consulta, y un tablero que se refresca cada cinco minutos sobre esa tabla se convierte en una factura mensual desagradable. Es la misma clase de sorpresa que describimos en los errores que triplican la factura de la nube.

Particionar por fecha y agrupar por las columnas con las que de verdad se filtra no es una optimización posterior: es parte del diseño de la migración, y hacerlo después significa recargar.

Dónde se van las horas

Por si sirve de referencia, en un proyecto de este tipo el reparto suele parecerse a esto:

• Inventario y decisiones. Qué se lleva, qué se archiva y qué se deja morir. Es la conversación más barata y la que más ahorra: mover diez años de datos que nadie va a consultar cuesta lo mismo que mover los que sí.
• Modelo de destino. Cómo se particiona, cómo se agrupa, qué se desnormaliza. Aquí se decide la factura de los próximos años.
• Extracción y carga. La parte que todo el mundo imagina cuando dice «migración», y casi nunca la más cara.
• Reescritura de lógica. Lo que vivía en PL/SQL. Proporcional a cuánto negocio se metió dentro de la base.
• Verificación. Demostrar que lo movido coincide. Con volúmenes grandes esto no es un trámite final: es una fase con su propio diseño, y la tratamos aparte en cómo verificar que una migración no perdió datos.
• Convivencia. El tiempo en que los dos sistemas están vivos y hay que mantenerlos sincronizados.

Un dato concreto

En el caso de Servinformación fueron 11 TB y 11.360 millones de filas, con coincidencia verificada al 100%, y una ventana estimada en una semana que se resolvió en 20 horas de sincronización.

Ese número —20 horas frente a una semana— no salió de correr más rápido. Salió de haber decidido antes qué se movía, en qué orden y cómo se iba a comprobar. La velocidad de la ventana es consecuencia del trabajo previo, no de la infraestructura.

Cuándo no hacerlo

Migrar a BigQuery tiene sentido cuando el problema es analítico: consultas sobre históricos grandes, tableros, agregaciones. No lo tiene cuando el sistema es transaccional y lo que duele es otra cosa.

Si el motor está bien y el problema es la aplicación que hay encima, la migración de base de datos es un rodeo caro. Esa decisión la tratamos en modernizar o rehacer desde cero.