Migrar de SQL Server a PostgreSQL sin frenar el negocio

Migrar el motor de base de datos de un sistema en producción es una de esas decisiones que suenan simples en un slide y se vuelven complejas apenas tocás el primer stored procedure con lógica de negocio escondida adentro.

El problema real

No era solo “cambiar de motor”. Era:

• Sostener SLAs de disponibilidad mientras migrábamos.
• Convivir con integraciones de terceros que asumían comportamientos específicos de T-SQL.
• Mantener al equipo shippeando features nuevas en paralelo.

Estrategia

Trabajamos en fases, no en un big-bang:

1. Inventario de dependencias: todo lo que tocaba la base — stored procedures, jobs, reportes, integraciones.
2. Capa de abstracción de datos: introdujimos un patrón de acceso a datos que nos permitía apuntar a ambos motores durante la transición.
3. Migración incremental por dominio: empezamos por los módulos con menor acoplamiento y menor criticidad de negocio.
4. Dual-write con verificación: durante la ventana de transición, escribíamos en ambos motores y comparábamos resultados antes de cortar el corte final.

Lo que aprendimos

El costo real de una migración de este tipo no está en el ALTER TABLE. Está en la lógica que asumías implícita en el motor viejo — comportamientos de locking, tipos de datos, funciones propietarias — y que hay que hacer explícita antes de poder moverla.

Si estás por encarar algo similar: invertí tiempo en el inventario antes de tocar código. Es la parte menos glamorosa y la que evita las sorpresas caras.