El Modelo de Cubo Cloud como guía estratégica para migrar servicios IT a la nube

Cuando una organización evalúa mover sus operaciones tecnológicas desde una infraestructura on‑premise hacia la nube, el reto no consiste únicamente en seleccionar un proveedor o calcular costos. El verdadero desafío está en decidir qué servicios migrar, bajo qué condiciones, con qué nivel de control y con qué enfoque de seguridad. Fue precisamente para responder a estas preguntas que el Jericho Forum desarrolló el Cloud Cube Model, un marco conceptual diseñado para ayudar a las organizaciones a tomar decisiones informadas y seguras sobre el uso de la nube.

El Modelo de Cubo surge a partir de una premisa clara del Jericho Forum: no todas las funciones del negocio son adecuadas para ejecutarse en la nube, y aquellas que lo son no deben hacerlo necesariamente de la misma forma. En lugar de promover una adopción indiscriminada del cloud, el modelo propone analizar distintas “formaciones de nube” y evaluar sus riesgos, beneficios y niveles de control antes de adoptar una decisión.

Desde su concepción original, el Cloud Cube Model se plantea como un framework estratégico, no técnico. Su propósito no es definir arquitecturas específicas ni imponer tecnologías, sino ofrecer un lenguaje común entre negocio, seguridad y TI que permita clasificar datos, aplicaciones y servicios según características críticas como ubicación, control, dependencia tecnológica y enfoque de seguridad.

El Modelo de Cubo Cloud

El modelo se representa como un “cubo” conceptual compuesto por cuatro dimensiones, cada una de las cuales describe un aspecto relevante de cómo un servicio puede operar en la nube.

Ubicación física

La primera dimensión analiza la ubicación física de los datos y servicios, distinguiendo entre entornos internos —dentro del control organizacional— y externos, ubicados fuera del perímetro tradicional. Esta dimensión desafía la creencia de que lo interno es siempre más seguro, y obliga a evaluar riesgos reales en función de contexto y controles.

Esta dimensión responde a la pregunta ¿El servicio o dato debe permanecer dentro del perímetro organizacional o puede residir fuera?

• Interno: cargas que deben permanecer on‑premise (por latencia, legado, regulación)
• Externo: cargas candidatas a nube pública o gestionada

Al realizar una migración, los datos sensibles o sistemas críticos suelen quedar inicialmente “internos”. Sistemas no críticos, web, analíticas o soluciones de colaboración suelen migrarse a “externo” primero.

Control operativo

La segunda dimensión se enfoca en el sourcing del servicio, es decir, si las capacidades tecnológicas son gestionadas internamente (insourced) o delegadas a un tercero (outsourced). Desde la perspectiva del Jericho Forum, externalizar no implica necesariamente perder control, sino redefinir responsabilidades, contratos y mecanismos de supervisión.

Esta dimensión evalúa ¿Quién opera y administra el servicio?

• Insourced: el equipo IT mantiene control (ej. IaaS en nube privada o híbrida)
• Outsourced: el proveedor gestiona la plataforma (PaaS, SaaS)

Al realizar migración de servicios, las operaciones maduras pero costosas podrían seguir un proceso de Outsourcing progresivo. Sistemas core del negocio podrían gestionarse Insourced o híbridos inicialmente.

Interoperabilidad y estándares

La tercera dimensión analiza la propiedad y apertura tecnológica, diferenciando entre soluciones propietarias y abiertas. Aquí el foco está en la interoperabilidad, la portabilidad de los datos y el riesgo de dependencia excesiva de un proveedor. Esta dimensión cobra especial relevancia en migraciones cloud, donde el vendor lock‑in (dependencia de un solo proveedor) puede convertirse en un problema estratégico.

Esta dimensión analiza ¿Qué tan dependiente será la organización del proveedor?

• Propietario: alto lock‑in, servicios cerrados.
• Abierto: estándares abiertos, portabilidad.

Al adoptar modelo cloud, los datos estratégicos preferiblemente se gestionan mediante arquitecturas abiertas. Para el caso de servicios tácticos es posible aceptar mayor dependencia por velocidad o costo.

Enfoque de seguridad

Finalmente, el modelo introduce una dimensión clave para la seguridad moderna: el paso de arquitecturas perimetrizadas —basadas en firewalls y redes internas— a enfoques des‑perimetrizados, donde la seguridad se construye alrededor de identidad, cifrado, políticas y control contextual. El Jericho Forum fue uno de los primeros en reconocer que la nube exige abandonar la idea de un perímetro rígido.

Recordar que esta dimensión plantea romper la visión clásica de firewall, por tanto la pregunta debe ser: ¿La seguridad se basa en perímetros o en identidad y contexto?

• Perimetrizado: VPN, firewall, DMZ tradicionales.
• Des‑perimetrizado: zero trust, identidad, cifrado, contexto.

Este punto es crítico en migraciones ya que la nube exige mover la seguridad al dato y la identidad, no a la red.

El modelo como marco de referencia para migrar productos y servicios IT

Generalidades del proceso

Aplicar el modelo de cubo en un proyecto de migración comienza con un inventario detallado de los servicios y operaciones que actualmente residen on‑premise. Aplicaciones, datos, dependencias técnicas y requisitos regulatorios deben analizarse individualmente antes de considerar cualquier movimiento hacia la nube. Cada uno de estos elementos puede ubicarse conceptualmente dentro del cubo, lo que permite visualizar su nivel de preparación para el cloud.

Una vez clasificados, el modelo ayuda a responder las preguntas clave de cada dimensión:

• ¿Este servicio puede operar fuera del perímetro organizacional?
• ¿Debe ser gestionado por terceros o mantenerse bajo control interno?
• ¿Qué nivel de dependencia tecnológica es aceptable?
• ¿Está preparado para un modelo de seguridad basado en identidad?

Según las respuestas, algunos servicios aparecerán como candidatos claros para migración, otros requerirán ajustes o rediseños, y algunos deberán permanecer on‑premise, al menos temporalmente.

Este enfoque convierte al modelo de cubo en una herramienta de priorización. En lugar de migrar “todo” de una sola vez, las organizaciones pueden definir fases de adopción, comenzando por servicios de bajo riesgo y menor criticidad, y avanzando progresivamente hacia componentes más sensibles. Así, el cubo actúa como una brújula que reduce riesgos técnicos, operativos y de seguridad.

Además, el modelo facilita la alineación entre estrategia de negocio y arquitectura cloud. Al no estar atado a un proveedor ni a una tecnología específica, permite evaluar nubes públicas, privadas o híbridas con el mismo criterio conceptual, asegurando que la decisión de migrar responda a necesidades reales y no únicamente a tendencias del mercado.

Metodología básica de aplicación

Es necesario tener claro que el Modelo de Cubo es un framework conceptual que clasifica las “formaciones de nube” usando las cuatro dimensiones mencionadas. Su propósito principal no es técnico, sino estratégico y de seguridad, ayudando a decidir qué partes del negocio sí son aptas para operar en la nube y cuáles no. El modelo parte de una premisa clave:

No todo debe migrarse a la nube, y no todo debe migrarse de la misma forma.

Paso 1: Inventariar servicios y datos on‑premise

Antes de “migrar”, el modelo de cubo obliga a clasificar:

• Aplicaciones
• Datos
• Procesos
• Dependencias técnicas
• Requisitos regulatorios

Este inventario es el insumo base para posicionar cada elemento dentro del cubo.

Paso 2: Responder preguntas clave dentro de cada dimensión para cada servicio y dato

Para cada ítem del inventario se debe responder a las siguientes preguntas:

• ¿El servicio o dato debe permanecer dentro del perímetro organizacional o puede residir fuera?
• ¿Quién opera y administra el servicio?
• ¿Qué tan dependiente será la organización del proveedor?
• ¿La seguridad se basa en perímetros o en identidad y contexto?

Paso 3: Posicionar cada servicio dentro del cubo

Una vez evaluadas las cuatro dimensiones, cada aplicación o servicio queda posicionado en el cubo, lo que permite responder para cada uno si el mismo puede ser:

• Migrable ahora
• Migrable con cambios / refactorizar
• No migrable (por ahora)

Este ejercicio evita errores clásicos como “lift & shift indiscriminado” (rehosting masivo).

Paso 4: Determinar el modelo de despliegue adecuado

Con el levantamiento de los pasos anteriores es fácil cruzar los resultados dentro del cubo con los modelos de:

• Nube privada
• Nube pública
• Nube comunitaria
• Nube híbrida

Por ejemplo:

1. Sí el análisis del Core financiero arrojó los siguientes resultados: Interno + Insourced + Propietario; por tanto, su despliegue debería orientarse a una Nube Privada y/o Híbrida.
2. Sí el análisis del Portal web arrojó los siguientes resultados: Externo + Outsourced + Abierto; por tanto, su despliegue puede llevarse a cabo en una Nube Pública.

Paso 5: Usar el modelo para definir la estrategia de fases

El objetivo de los pasos anteriores aplicando el modelo consiste en no empujar una migración masiva, inmediata y desbocada, sino una ejecución bajo fases controladas, comumente de acuerdo al siguiente proceso lógico:

• Servicios de bajo riesgo
• Datos con menor sensibilidad
• Procesos de soporte
• Core del negocio (si aplica)

Esto minimiza impacto operativo y riesgo de la operación.

Paso 6: Alinear seguridad, costos y cumplimiento

Finalmente, la aplicación de este modelo ayuda a:

• Alinear la gobernanza IT
• Definir controles de seguridad por tipo de carga
• Evitar migraciones motivadas solo por costo

El modelo fuerza a responder una pregunta incómoda pero clave: ¿Este servicio está realmente listo para la nube y bajo qué condiciones?

Conclusión

El Modelo de Cubo Cloud del Jericho Forum sigue siendo una referencia valiosa para proyectos de migración desde infraestructura on‑premise hacia la nube. Más que un instrumento técnico, es un marco de pensamiento estratégico que obliga a cuestionar supuestos, evaluar riesgos y diseñar una adopción de cloud consciente, gradual y alineada con los objetivos del negocio. En un contexto donde la nube es cada vez más omnipresente, el cubo recuerda una verdad fundamental: migrar bien es más importante que migrar rápido.