SailPoint IIQ a ISC: lo que nadie te cuenta de la migración

SailPoint está empujando a todo el mundo hacia Identity Security Cloud (ISC, antes IdentityNow). El mensaje de ventas es claro: «deja de gestionar servidores, nosotros lo hacemos por ti, todo es más fácil». La realidad es más matizada. Este artículo cubre lo que los Sales Engineers no te cuentan en la demo.

He participado en tres migraciones de IIQ a ISC. Dos salieron bien. Una no. La diferencia no fue la tecnología — fue entender qué cambia realmente cuando pasas de una plataforma Java on-prem a un SaaS multi-tenant.

Lo que realmente se pierde en la migración

Voy a ser directo: esto no es un lift-and-shift. IIQ e ISC comparten una marca y un modelo conceptual. La implementación es fundamentalmente diferente.

Reglas Java personalizadas. IIQ te permite escribir Java y BeanShell arbitrario para provisioning, correlación, validación y certificaciones. ISC usa un motor de reglas mucho más limitado. Tu regla de provisioning de 500 líneas de Java no se migra. Se reescribe en BeanShell o se reemplaza con un workflow declarativo. Esa reescritura es el mayor coste único del presupuesto de migración.

Personalización de UI. En IIQ puedes modificar cualquier JSP, cualquier CSS. ISC tiene un framework de UI gestionado. Las personalizaciones pasan por el marketplace de extensiones de SailPoint. Olvídate de ese dashboard personalizado que construiste para el CISO.

Conectores. IIQ tenía conectores de primera clase para sistemas on-prem: JDBC, LDAP, PowerShell, conectores personalizados vía SDK. ISC usa conectores SaaS nativos más una Virtual Appliance (VA) para conectividad on-prem. El modelo de conectores es completamente diferente. Algunos conectores de IIQ no tienen equivalente en ISC.

Workflows. Los workflows de IIQ eran objetos Java con hooks de ciclo de vida. Los de ISC son declaraciones JSON/YAML. Menos potentes, más mantenibles, pero si tienes workflows complejos de provisioning multi-paso con manejo de errores, prepárate para rediseñar.

Reporting. El reporting ad-hoc de IIQ mediante BeanShell contra la base de datos ha desaparecido. ISC tiene un constructor de informes y APIs. Cubre el 80% de lo que la mayoría de organizaciones necesitan.

La Virtual Appliance: el SPOF que no esperas

ISC necesita una VA on-prem para conectar con Active Directory, LDAP, bases de datos y sistemas legacy. Es la parte del discurso «cloud» que pasan por alto.

La VA es un punto único de fallo a menos que la configures en HA. Configurar VA HA no es trivial — requiere balanceador, almacenamiento compartido y configuración de red cuidadosa. He visto más incidentes de ISC causados por fallos de VA que por el propio cloud de ISC.

Modos de fallo comunes:

• La VA pierde conectividad con ISC cloud. Los clusters de provisioning se quedan colgados. Sin errores, sin alertas — solo una cola de peticiones que nunca se completan.
• El disco de la VA se llena. Los logs y datos de auditoría se cachean localmente antes de enviarse al cloud.
• La rotación de certificados en la VA se olvida. El handshake TLS con ISC cloud falla silenciosamente.

«Cloud» no significa «cero mantenimiento». La VA sigue necesitando parches, monitorización, gestión de disco y resolución de problemas de red.

El coste de la personalización

En IIQ, si una funcionalidad no existía, la construías. Java, BeanShell, JSP, workflows personalizados. En ISC, estás limitado a lo que SailPoint proporciona más extensiones aprobadas.

Un ejemplo real: una validación de negocio compleja. Antes de conceder acceso, el sistema debía comprobar los registros de formación del usuario, la autoridad del manager y la utilización actual de licencias. En IIQ, tres horas de desarrollo Java. En ISC, el workflow builder no soporta esa profundidad. La solución fue un conector personalizado más un workflow mediado. Tres días en lugar de tres horas.

El modelo SaaS gana en mantenimiento, parches y disponibilidad. Pierde en flexibilidad. Presupéstalo.

El timeline real de una migración

SailPoint cotiza de 6 a 9 meses. La realidad para una organización con 50+ aplicaciones: 12 a 18 meses.

Descubrimiento y evaluación: 2–3 meses. Inventariar cada aplicación, regla, conector y workflow.

Reimplementación de lógica: 4–6 meses. El cuello de botella. Reescribir reglas, workflows y conectores.

Configuración de VA: 1–2 meses. Instalar, configurar y probar la Virtual Appliance.

Pruebas y UAT: 2–3 meses. Regresión de cada caso de uso. Ejecución paralela con IIQ.

Corte y estabilización: 1–2 meses. Migración por fases y correcciones post-migración.

Cuándo migrar y cuándo esperar

Migra ya: organización pequeña o mediana, menos de 30 conectores, poca lógica personalizada.

Espera o híbrido: organización grande con 100+ conectores, reglas Java complejas, workflows muy personalizados.

Híbrido: mantén IIQ para casos complejos mientras migras procesos simples a ISC.

---

ISC es el futuro de SailPoint. Es mejor plataforma para el 70% de las organizaciones. Pero la migración no es un lift-and-shift — es una reimplementación.