Por qué seguimos eligiendo Informix y Multibase en 2026 (y cómo lo modernizamos sin reescribirlo)

• Lo que la pregunta está asumiendo
• Lo que sí limita
• Por qué Informix y Multibase siguen siendo defendibles
  • 1. Estabilidad demostrada
  • 2. Modelo de datos consolidado
  • 3. ODBC sigue funcionando perfectamente
  • 4. Razón organizativa
• Lo que sí hay que hacer
• Un ejemplo de código
• Cuándo sí migrar
• En resumen

Cada cierto tiempo, en una empresa que lleva años con CGestion sobre Informix o Multibase, aparece la conversación: “¿no deberíamos migrar a algo más moderno?”. La pregunta es legítima, y la respuesta no es siempre la misma. Pero en una mayoría de casos que vemos, la respuesta correcta es: no, ahora no, y probablemente nunca de la forma que te están proponiendo.

Este artículo explica por qué, y qué hacer en su lugar.

Lo que la pregunta está asumiendo

La frase “tenemos que migrar a algo más moderno” esconde tres premisas sin verificar:

1. Que el sistema actual está limitando al negocio.
2. Que la alternativa propuesta hará lo mismo, pero mejor.
3. Que el coste de la migración es asumible y previsible.

Casi nunca son las tres ciertas a la vez. La primera, en concreto, suele ser una proyección emocional: el sistema parece viejo (terminales, cortesía visual de los noventa, sintaxis SQL-89), pero rara vez se han documentado las limitaciones reales que impone al negocio.

Lo que sí limita

Cuando hacemos auditoría sobre instalaciones que llevan 15 o 20 años con Informix/Multibase, lo que encontramos no es que el motor sea lento o poco fiable — habitualmente es que:

• No hay capa de integración: cualquier intento de conectar el ERP con algo nuevo (web B2B, app móvil, marketplace) fuerza al desarrollador a hablar SQL-89 directamente desde un framework moderno, con todos los problemas de seguridad, caché y rate-limit que eso implica.
• No hay versionado documentado de los procedimientos (forms 4GL, reports), por lo que cualquier cambio se hace con cierta tensión.
• No hay separación clara entre lógica de negocio y modelo de datos; hay reglas escondidas en triggers y procedimientos que llevan ahí desde los noventa.
• El equipo original ya no está, y la documentación, si existe, vive en un cajón.

Ninguno de estos cuatro problemas se resuelve cambiando de motor. Todos se resuelven trabajando.

Por qué Informix y Multibase siguen siendo defendibles

Tres razones técnicas y una organizativa:

1. Estabilidad demostrada

Informix lleva varias décadas funcionando en cargas críticas. Multibase también. La fiabilidad bajo carga real, con su modelo transaccional y su gestión de bloqueos, es difícil de igualar para una empresa pequeña que intente reproducir todo en PostgreSQL o MySQL sin invertir tiempo en tuning.

2. Modelo de datos consolidado

Si llevas años usando CGestion, tu modelo de datos no es solo “tablas”: es años de convenciones, de campos calculados, de reglas de integridad implícitas. Migrar a otro motor implica reproducir todo eso — y, cada vez que reproduces algo, introduces el riesgo de que la copia no sea exactamente fiel.

3. ODBC sigue funcionando perfectamente

El cliente ODBC oficial de Informix (y los puentes para Multibase) permiten conectar desde PHP 8.3, Python 3.12, Node 22, .NET 9 sin problemas. La idea de que el motor “no habla con lo moderno” es simplemente falsa.

4. Razón organizativa

Una migración de ERP no es solo técnica: es operativa. Implica formación de usuarios, paralelismo de sistemas durante meses, adaptación de procesos, riesgos de continuidad de negocio. En empresas pequeñas, esto se traduce en meses de productividad reducida — un coste que rara vez se cuenta en el presupuesto inicial.

Lo que sí hay que hacer

Si no migramos, ¿qué hacemos? La respuesta — y es lo que llevamos años practicando — es construir una capa REST alrededor del ERP.

┌──────────────────────────────────────┐
│   Consumidores modernos              │
│   (Web, Móvil, B2B, BI, AEAT)        │
└─────────────┬────────────────────────┘
              │ HTTPS · OAuth2 · JSON
              ▼
┌──────────────────────────────────────┐
│   Capa REST (Laravel · PHP 8.3)      │
│   Cache · Rate-limit · Auditoría     │
└─────────────┬────────────────────────┘
              │ ODBC · SQL-89
              ▼
┌──────────────────────────────────────┐
│   CGestion (Informix · Multibase)   │
└──────────────────────────────────────┘

Esta capa hace tres cosas que el ERP solo nunca podrá:

• Hablar JSON moderno con cualquier consumidor sin obligarles a conocer Informix.
• Cachear lo cacheable (catálogos, tarifas, stock que no cambia cada segundo) liberando al ERP de carga innecesaria.
• Auditar cada operación: quién pidió qué, cuándo, qué se devolvió, qué se modificó.

El esfuerzo de construirla es una fracción del coste de migrar el ERP completo. Y, además, cuando algún día una versión futura de CGestion se mueva a otro motor (cosa que el propio fabricante puede hacer), nuestra capa REST sigue siendo el mismo contrato: simplemente cambiamos el adaptador interno.

Un ejemplo de código

Una consulta de stock por lote, expuesta como endpoint REST:

Route::get('/v1/stock/{articulo}', function (string $articulo) {
    return Cache::remember(
        "stock.{$articulo}",
        ttl: now()->addMinutes(2),
        callback: fn () => DB::connection('informix')
            ->table('almstock')
            ->where('articulo', $articulo)
            ->select('lote', 'cantidad', 'ubicacion')
            ->get(),
    );
});

Doce líneas. Todo el sistema externo consume GET /v1/stock/AB-001 y recibe JSON. Si tres mil clientes B2B preguntan por el mismo artículo en un minuto, dos llamadas llegan a Informix. Las otras 2 998 las contesta Redis (o database driver, según infraestructura).

Cuándo sí migrar

No queremos pintar un mundo en el que la respuesta es siempre “no toques el motor”. Hay tres escenarios donde sí tiene sentido planteárselo seriamente:

• Fin de soporte oficial. Si IBM o el fabricante anuncian fin de soporte y no hay alternativa de extensión.
• Cambio drástico de modelo de negocio. Si la empresa va a operar de un modo radicalmente distinto al que diseñó el modelo de datos inicial.
• Coste de licencias desproporcionado. Si la empresa pequeña paga una licencia pensada para corporativa y eso pesa en la cuenta de resultados año tras año.

En esos casos no recomendamos migrar el ERP: recomendamos reformular el proyecto entero, con una transición planificada, paralelismo controlado y, sobre todo, con honestidad sobre el coste real.

En resumen

La frase “Informix es un sistema viejo” es una valoración estética, no técnica. El motor sigue siendo perfectamente válido en 2026. Lo que se queda atrás no es el motor: son las integraciones. Y eso se arregla construyendo una capa moderna a su lado, no tirando todo y empezando desde cero.

Si tienes CGestion y estás recibiendo presión para migrar, ya conoces nuestra postura. Si quieres oírla con tu caso concreto delante, escríbenos.