Un SAP Basis junior hoy está viendo algo real: las operaciones tradicionales on-prem siguen existiendo, pero el centro de gravedad se está moviendo hacia landscapes híbridos y cloud-managed. No es solo una moda; es una consecuencia directa de cómo SAP está empaquetando la transformación (RISE), cómo los clientes buscan reducir “operación pesada” y cómo los hyperscalers estandarizaron patrones para correr SAP con buenas prácticas.

La pregunta clave no es “¿Basis se acaba?”, sino: ¿qué tipo de Basis va a seguir siendo valioso? Spoiler: el que entiende plataforma, seguridad, automatización y operación en cloud.

1) Qué cambió de verdad: de “administrar servidores” a “operar una plataforma”

Históricamente, el Basis era sinónimo de:

• instalación/patching,
• administración de sistema (usuarios, jobs, spool, transportes),
• tuning,
• HA/DR en datacenter propio,
• coordinación con redes/almacenamiento/virtualización.

En cloud, muchas organizaciones están buscando:

• estandarizar arquitectura (landing zones, redes, IAM, logging),
• reducir tareas manuales (infra como código, automatización),
• operar con métricas (SRE/observabilidad),
• y consumir servicios administrados cuando conviene.

Esto se acelera con el enfoque de SAP hacia journeys como RISE with SAP (para modernizar desde on-prem hacia “Business Suite”/S/4HANA cloud bajo un paquete de servicios).

Y una cosa importante: incluso con servicios gestionados, no desaparece la operación. Cambia la naturaleza del trabajo: menos “apagar incendios en fierros”, más gobernar y asegurar la plataforma.

2) RISE / Cloud no significa “SAP se encarga de todo”: el modelo de responsabilidad compartida

Uno de los errores más comunes en perfiles que migran a cloud es creer que “como es cloud, ya no hay nada que hacer”. En realidad, el cloud moderno funciona con responsabilidad compartida: el proveedor (y/o SAP en escenarios gestionados) cubre capas, pero el cliente sigue siendo responsable de otras (identidades, integraciones, configuración, gobierno, endpoints, etc.).

SAP mismo aborda este enfoque en materiales de shared responsibility para SAP S/4HANA Cloud/escenarios cloud, destacando la distribución de responsabilidades entre SAP y el cliente.

Traducción a “vida real Basis”: tu valor sube cuando puedes responder con claridad:

• qué queda en manos de SAP,
• qué queda en manos del cliente,
• qué queda en manos del hyperscaler,
• y cómo se audita/monitorea todo eso.

3) “Más allá de BTP”: qué está demandando el mercado (y por qué)

Sí, SAP BTP es relevante porque es la plataforma para integrar, automatizar, extender y construir capacidades alrededor del core SAP.

Pero el mercado no está pidiendo “BTP” como sticker; está pidiendo capacidad de operar landscapes modernos. Y eso, para un Basis, se traduce en 5 bloques:

(A) Fundamentos reales de Cloud (hyperscaler-first)

No necesitas ser arquitecto cloud senior para empezar, pero sí debes dominar:

• IAM (identidades, roles, mínimo privilegio),
• redes (VPC/VNet, subredes, routing, VPN/ExpressRoute/Interconnect),
• cómputo/almacenamiento (VMs, discos, snapshots, performance),
• logging/monitoring (centralización, alertas, retención, auditoría).

Los hyperscalers incluso publican guías y marcos de “buenas prácticas” para SAP:

• AWS SAP Lens (diseño bien-arquitectado para workloads SAP).
• Microsoft “SAP on Azure landing zone accelerator” (base recomendada para operar SAP en Azure).
• Google Cloud SAP guidance y Workload Manager para evaluar SAP contra buenas prácticas.

Si quieres ser empleable, elige 1 cloud (AWS o Azure suelen ser los más comunes en proyectos SAP) y llévalo a un nivel “operacional”: conectar redes, controlar accesos, monitorear, hardening básico y costos.

(B) Operación moderna: observabilidad, SRE, resiliencia

En cloud no basta con “que levante el sistema”. Se espera:

• métricas y SLAs,
• detección temprana de degradaciones,
• automatización de respuesta,
• post-mortems, análisis de causa raíz.

El foco se mueve a operar con datos y patrones: alta disponibilidad, DR, backups, pruebas regulares, capacidad, y eficiencia de costos (FinOps básico).

(C) Automatización e Infraestructura como Código (IaC)

Aquí ocurre un salto fuerte de perfil:

• scripting (bash/powershell),
• pipelines (conceptos CI/CD),
• IaC (Terraform/ARM/Bicep, al menos comprensión y lectura),
• automatización de tareas repetibles.

El “Basis que automatiza” se vuelve escaso y, por lo mismo, más valioso.

(D) ALM está cambiando: de SolMan a Cloud ALM

Este punto es mega concreto y con fecha.

SAP ha indicado que SAP Solution Manager 7.2 tiene mainstream maintenance hasta el 31 de diciembre de 2027 y recomienda transicionar a SAP Cloud ALM antes de esa fecha.

Para Basis, esto impacta en:

• monitoreo y operación,
• gestión de cambios,
• testing,
• trazabilidad,
• configuración de herramientas y procesos.

Tu “diferencial” es entender cómo se opera y gobierna el landscape con las herramientas nuevas, no solo con las viejas.

(E) “Clean Core”: extensibilidad sin romper upgrades

Cada vez más proyectos exigen mantener el core lo más estándar posible (“clean core”) y mover extensiones/integraciones a mecanismos soportados (por ejemplo BTP e integraciones estándares). SAP viene empujando esta estrategia como parte de su visión de modernización.

Para Basis esto no es “tema de desarrolladores” solamente: afecta

• cómo se gobiernan transportes,
• cómo se controlan integraciones,
• cómo se asegura compatibilidad,
• cómo se planifican upgrades (y su impacto operacional).

4) Entonces… ¿qué recomiendo a un Basis junior que quiere ir a Cloud?

1) Elige una ruta “T-shaped”

• Base fuerte en SAP Basis core (la T vertical)
• Apertura en cloud + automatización + seguridad + operación (la T horizontal)

2) Elige un hyperscaler y construye proyectos “demostrables”

Ejemplos de mini-proyectos (para CV y entrevistas):

• diseñar una landing zone simple (red + IAM + logging),
• montar monitoreo/alertas y un runbook,
• automatizar un task repetitivo (backup snapshot, rotación de logs, health checks),
• documentar un “shared responsibility” y controles de seguridad.

3) BTP sí, pero con foco correcto (lo que paga)

BTP se vuelve potente cuando lo conectas a:

• integración (suite de integraciones),
• identidad y trust,
• conectividad on-prem ↔ cloud,
• gobierno y operaciones.

Si lo abordas así, BTP te multiplica. Si lo abordas como “curso y badge”, te deja igual.

5) Certificaciones: cómo pensarlas sin caer en “coleccionar diplomas”

Las certificaciones son útiles si validan lo que ya practicas. Por ejemplo, AWS tiene un examen específico para SAP en AWS (PAS-C01) con guía oficial que apunta a diseñar/implementar/migrar/operar SAP en AWS con el enfoque Well-Architected. Y SAP Training tiene cursos como “SAP on AWS – Fundamentals”.

Regla práctica:

70% práctica (lab/proyectos)

30% certificación (validación)

6) Conclusión: el futuro de Basis no es “BTP o nada”; es “plataforma + operación”

El mercado está premiando a quien puede unir estos mundos:

• SAP core (lo que siempre importó),
• cloud fundamentals (lo que ahora es inevitable),
• operación moderna (observabilidad, resiliencia, automatización),
• ALM nuevo (Cloud ALM y transición antes de 2028),
• clean core + integraciones (para no romper upgrades).

Eso no te convierte en “menos Basis”. Te convierte en el Basis que el mercado realmente necesita: un perfil que puede operar SAP como una plataforma moderna.

Espero haberte ayudado a entender el panorama SAP Basis para el 2026. Agradezco al suscriptor @roony842 que en mi canal de Youtube me consultó acerca de este tema e impulsó la publicación de este artículo. Saludos y Feliz 2026 para todos! JSG