Caso de uso — Distribuidora con Power9 cerca de EOSL

Contexto

Industria: distribuidora regional de bebidas, ~20 sucursales mayoristas + flota propia. Plataforma: IBM Power S922 (Power9) con IBM i 7.3 (sin Service Extension contratada). Una LPAR productiva. Aplicativo crítico: ERP comercial heredado en RPG IV + DB2 for i, ~1.5 TB.

Situación inicial

El gerente de IT recibe dos noticias el mismo trimestre:

•IBM publicó EOSL para Power9 en enero de 2026 (fuente: IBM Power announcements). Su Power S922 quedará sin soporte de hardware.
•Su versión de IBM i (7.3) está en Service Extension Offering (paga), vigente hasta el 30 de septiembre de 2026. Si no migran, quedan sin soporte oficial. (Fuente: IBM i Support Roadmap)

Empieza a recibir llamados de proveedores. La conversación con nosotros empieza con: "Tengo que renovar todo. ¿Por dónde empiezo?".

Discovery

Preguntas aplicadas

| Pregunta | Respuesta | |---|---| | ¿Modelo de Power y serial? | Power S922 (Power9) ~5 años de antigüedad. | | ¿Versión de IBM i + TR? | 7.3 con TRs viejos, sin Service Extension formal. | | ¿Cuántas LPARs IBM i? | Una sola productiva. | | ¿Tienen HA? | No. | | ¿Qué backup hacen? | BRMS + cinta, 1 backup nocturno. Funciona. | | ¿Hay sitio secundario? | No. Hay una sucursal con espacio físico para infraestructura. | | ¿Qué presupuesto manejan? | "Entendemos que esto es CAPEX nuevo. Tenemos margen." | | ¿Quieren modernizar el aplicativo? | Mediano plazo sí. No ahora. Quieren preservar inversión RPG. | | ¿Hay deseo de cloud? | "Lo escuchamos, pero queremos mantener control on-prem." |

Hallazgos críticos

•Doble frontera: hardware EOSL + OS en service extension.
•Sin HA → si fallaba el Power9 viejo, el negocio se detenía.
•Modernización del aplicativo está fuera del scope inmediato — replatforming es proyecto de años.
•Inversión IBM Power se quiere preservar, pero hay disposición a CAPEX para upgrade.

Solución propuesta

Arquitectura objetivo

•Producción nueva: Power11 scale-out (modelo a confirmar según sizing — referencia: IBM Power10/11 Scale-Out (Redbook REDP-5675)).
•OS: IBM i 7.5 (versión activa con soporte estándar).
•HA local: una segunda LPAR sobre el mismo Power, o un Power S1014 más chico en sitio secundario (la sucursal). Decisión según presupuesto.
•Quick EDD entre productivo y target HA/DR.

Productos en scope

•Hardware nuevo Power11 (vía partner IBM).
•Upgrade IBM i 7.3 → 7.5.
•Assure Quick EDD sobre los dos sistemas.
•(BRMS sigue, sin cambios de licencia.)

Diseño

•Power nuevo en sitio principal + target en sucursal (sitio secundario), con Quick EDD para HA/DR.
•Carga inicial desde el Power9 viejo al Power11 nuevo: SAVE/RST + journaling como puente; Quick EDD recogiendo desde el cutover.
•Cutover ventana mínima: usar Quick EDD para que el Power9 viejo siga corriendo hasta el último momento, y voltear a producción nueva con role-swap controlado.

Plan de implementación (alto nivel)

•
Fase 0 — Procurement (4-6 semanas)
- •Compra y arribo del nuevo hardware Power11 + Power S1014 secundario.
•
Fase 1 — Setup del nuevo entorno (3 semanas)
- •Instalación IBM i 7.5 en ambos.
- •Migración inicial de aplicativo (SAVE/RST).
- •Validación funcional en lab.
•
Fase 2 — Quick EDD entre Power9 viejo y Power11 nuevo (3 semanas)
- •Configuración como par "viejo → nuevo" para sincronizar mientras producción sigue en el Power9.
- •Validación de sincronía.
•
Fase 3 — Cutover (ventana coordinada)
- •Drill de role-swap entre viejo y nuevo.
- •Switch real con downtime acotado (<1 hora).
- •Validación end-to-end con usuarios.
•
Fase 4 — Reconfiguración HA/DR (2 semanas)
- •Power9 viejo se retira.
- •Quick EDD se reconfigura: nuevo Power11 (productivo) → Power S1014 (sucursal/DR).
•
Fase 5 — Operación + capacitación (2 semanas)
- •Tracks de soporte L1 + senior.
- •Drills periódicos.

Tiempo total estimado: 14-16 semanas (incluyendo procurement).

Riesgos y mitigaciones

| Riesgo | Mitigación | |---|---| | RPG legacy con dependencias de versiones específicas | Validación funcional exhaustiva en lab antes del cutover | | Aplicación con IPs hardcodeadas | Relevar y proponer abstracción antes del cutover | | Procurement se demora | Comenzar fase 1 en lab apenas llegue el primer Power; usar el Power9 viejo más tiempo si es necesario | | Equipo del cliente sin experiencia HA | Capacitación obligatoria + drill antes de pase a prod | | Cambios regulatorios / PTFs durante el proyecto | Plan de PTF coordinado con IBM Support |

Resultado al cierre del proyecto

•Hardware en soporte estándar (Power11) por años.
•IBM i 7.5 con soporte estándar y mejoras (RPG opcodes nuevos DATA-GEN, etc., disponibles para la modernización futura).
•HA real con Quick EDD, drill validado.
•Plan de continuidad operativa formalmente documentado.
•Power9 viejo retirado limpiamente, sin pérdida de datos.

Lecciones para preventa

•EOSL del hardware es un evento: hay una urgencia natural que se aprovecha si la conversación arranca con tiempo.
•Combinar siempre con upgrade del OS — no tiene sentido renovar hardware y dejar el OS viejo.
•Vender HA junto con el upgrade: el cliente está aceptando CAPEX, es el momento de incorporar Quick EDD. Después es venta separada y mucho más difícil.
•Quick EDD como puente migratorio — vale por sí solo: replicar Power9 → Power11 durante la migración da un cutover de minutos, no horas. Es discurso de "minimal downtime upgrade".
•No empujar cloud si el cliente no lo pide. Pero sembrar PowerVS como "futuro DR" — es venta del trimestre siguiente.

Productos relacionados

•Quick EDD — central.
•Flash For i — secundaria, para el SAVE21 sin afectar producción una vez que esté Power11 + IBM i 7.5.
•Connect CDC — eventual cuando aparezca el deseo de modernizar reportería con cloud.