Migra de Oracle o SQL Server a PostgreSQL sin reescribir la app

No, y ese es justamente el punto del proyecto. Los datos se migran con validación de integridad (conteos, checksums, llaves foráneas) y no se dan por buenos hasta que cuadran fila por fila contra el origen. La funcionalidad se preserva convirtiendo la lógica almacenada (PL/SQL, T-SQL) a PL/pgSQL y demostrando paridad con una suite de pruebas antes de apagar el motor viejo. Las pocas cosas que PostgreSQL resuelve distinto —algún tipo propietario o una función analítica particular— las mapeamos a su equivalente y te lo documentamos; no las dejamos caer en silencio.

No. El objetivo de esta migración es cambiar solo el motor de la base de datos, no el sistema. En la mayoría de los casos el cambio en la app se reduce al driver de conexión y a un puñado de diferencias de dialecto SQL; para aplicaciones sobre SQL Server, Babelfish for PostgreSQL habla el mismo protocolo y reduce todavía más lo que hay que tocar. Si de todos modos tu aplicación ya está en un lenguaje o framework obsoleto y quieres modernizarla, eso es un proyecto distinto y complementario: nuestra Modernización de legacy (también en la fábrica de software), que se puede hacer en la misma etapa o después de la migración de motor.

Se cotiza por esfuerzo, con nuestra tarifa base de fábrica de $600 MXN por hora, que baja según el volumen de horas comprometidas. El costo real depende del tamaño del esquema, de cuánta lógica almacenada (procedimientos, triggers, packages) haya que convertir y de las diferencias de dialecto — por eso empezamos con un Assessment de migración de BD de alcance acotado: te entrega el reporte de compatibilidad, el mapa de riesgos y un estimado de esfuerzo por objeto, y es tuyo aunque decidas no seguir con nosotros. Sin paquetes cerrados inventados: primero medimos, luego cotizamos.

PostgreSQL es open source: no paga licencia de motor ni soporte por core como Oracle o SQL Server, así que ese renglón desaparece de tu factura. Cuánto representa eso en tu caso depende de tu contrato actual, tu edición y el modelo de licenciamiento que tengas; no te vamos a inventar un porcentaje. Lo honesto es esto: eliminas el costo de licencia del motor, y contra eso ponemos el costo único de la migración y el de operar PostgreSQL (equipo o servicio administrado). En el assessment te ayudamos a armar ese comparativo de TCO con TUS números, no con un caso de folleto.

Es una combinación muy común y tiene todo el sentido: un PostgreSQL administrado como Amazon Aurora o Azure Database for PostgreSQL suele costar una fracción de la licencia propietaria, y el cambio de motor es el momento natural para hacerlo. Aun así son dos intenciones distintas: cambiar el MOTOR (lo que hacemos aquí) y mover la INFRAESTRUCTURA a la nube. Cuando el proyecto incluye lo segundo lo coordinamos con nuestra Migración a la nube (Azure/AWS) del mini-sitio de Cloud & DevOps, que aporta la landing zone, la red y el modelo 6R. Puedes hacer solo el cambio de motor on-premise, o las dos cosas en una sola ola.

Sí. PostgreSQL corre cargas OLTP y analíticas de alto volumen con particionamiento, índices avanzados, concurrencia MVCC, réplicas de lectura y extensiones para casos especiales. Parte del proyecto es precisamente demostrarlo antes del cutover: en la prueba de concepto medimos el rendimiento real de tus consultas más pesadas en PostgreSQL y, si algo no rinde, lo afinamos (índices, planes, parámetros) hasta igualar o superar el motor que dejas. No migramos con fe: migramos con métricas de paridad y de desempeño sobre la mesa. Si de esos datos quieres además explotar analítica y tableros, eso ya es Data engineering y BI, otra capacidad de la fábrica.