Migrar tu MCP casero a una vía soportada
Del servidor en el portátil con usuario técnico a una arquitectura que aguante una revisión de seguridad. Cómo auditar lo que tienes, elegir destino, migrar por fases y responder a las preguntas que te van a hacer.
Si montaste tu propio servidor MCP contra SAP, enhorabuena: entendiste antes que la mayoría por dónde iban los tiros. El problema no es que esté mal hecho, es que está en el sitio equivocado. Vive en tu portátil, guarda credenciales ahí, entra con un usuario que probablemente compartes y no deja rastro que nadie pueda revisar. Esta guía va de mover esa pieza sin romper lo que ya funciona.
Antes de nada: no es un tirón de orejas
Los proyectos de comunidad abrieron esta categoría y demostraron que era posible y útil, mucho antes de que existiera producto oficial. Sin ellos, SAP probablemente no habría publicado su ABAP MCP Server. Lo que ha cambiado no es la calidad de tu montaje: es que ahora hay alternativas soportadas, y eso cambia la respuesta correcta.
El movimiento, en una línea
Todo lo que viene después es esto, contado despacio:
Hoy
Un servidor por portátil, credenciales locales, usuario compartido
Auditas
Qué tienes, quién lo usa, contra qué sistemas y con qué permisos
Eliges destino
Servidor oficial de SAP, pasarela central tipo ARC-1, o quedarte en sandbox
Migras por fases
Convives, verificas y solo entonces apagas lo viejo
Mañana
Un endpoint por sistema, identidad real, permisos acotados y auditoría
Las seis preguntas incómodas
Respóndelas tú antes de que las haga otro. Si alguna te da vergüenza, ya sabes por dónde empezar.
| Pregunta | Por qué importa |
|---|---|
| ¿Dónde está la contraseña de SAP? | Si está en un fichero de tu portátil, está también en tus copias de seguridad, en tu histórico y en cualquier sitio donde hayas sincronizado esa carpeta |
| ¿Con qué usuario entra el agente? | Si es un usuario técnico compartido, el log de SAP no puede decir quién hizo qué. Ese es el punto que más incomoda en una auditoría |
| ¿Quién más lo tiene montado? | Cada instalación es una copia de las credenciales y una configuración distinta. Nadie sabe cuántas hay hasta que se pregunta |
| ¿Contra qué sistemas apunta? | Desarrollo está bien. Si en algún momento alguien apuntó a calidad o a producción «solo para mirar», eso hay que saberlo hoy |
| ¿Puede escribir? ¿Puede lanzar SQL? | Muchos servidores permiten todo por defecto. Escribir código, activarlo y consultar la base de datos son las tres que dan respeto |
| ¿Queda registro de lo que ha hecho? | Si la respuesta es «en los logs de mi terminal», no hay registro |
El inventario, en una tarde
Sin proyecto ni comité. Una hoja de cálculo basta.
Lista de instalaciones y de quién es cada una
Pregunta en el equipo sin dramatizar. Lo que quieres es el número real, no el oficial.
Qué servidor MCP usa cada una y si sigue mantenido
Algunos de los proyectos populares llevan meses sin commits. Heredar deuda de un repo abandonado es un riesgo aparte.
Sistemas y mandantes a los que apunta cada instalación
Anota también los que se usaron alguna vez y ya no. Los accesos olvidados siguen existiendo.
Usuarios SAP empleados y sus autorizaciones
Sobre todo S_DEVELOP, autorizaciones de paquete y de transporte.
Qué operaciones tiene habilitadas
Lectura, escritura, vista previa de datos, SQL libre, transportes, git.
Para qué se usa de verdad
Esto es lo que define el destino. Analizar código y ejecutar procesos de negocio no son el mismo problema.
Elige destino según para qué lo usas
No hay una respuesta única. Depende de lo que hayas descubierto en el inventario.
Al ABAP MCP Server oficial de SAP
Empieza por aquíPara quién: Si lo tuyo es desarrollo ABAP puro: leer, analizar, escribir y activar código.
- Es la vía soportada y no hay que justificarla ante nadie
- Disponible en Eclipse y en VS Code
- Sigue funcionando con Claude Code, Copilot o Amazon Q
- Deja de depender de un proyecto de terceros
- La disponibilidad depende de tu release y de tu contrato
- El consumo se factura en AI Units al acabar el periodo gratuito
A una pasarela central tipo ARC-1
Para quién: Si sois un equipo, necesitáis identidad por usuario y alguien va a pedir trazabilidad.
- Una instancia por sistema en vez de una por portátil
- Solo lectura por defecto, permisos por escalones
- Principal Propagation: SAP ve al usuario real
- Audit log integrable con la plataforma
- Requiere BTP, XSUAA y trabajo de Basis
- Sigue siendo un proyecto de comunidad
- Principal Propagation lleva su tiempo de configuración
Quedarte donde estás, pero acotado
Para quién: Si el uso es puntual, personal y siempre contra un sandbox sin datos reales.
- Cero esfuerzo de migración
- Perfecto para seguir aprendiendo y probando
- No escala a un equipo
- No aguanta una revisión de seguridad
- Tienes que poder afirmar que nadie apunta a un sistema con datos reales
El plan de migración
Cinco fases. La regla que las atraviesa todas: no apagues lo viejo hasta que lo nuevo esté verificado.
Congela el crecimiento
Antes de migrar nada, deja de sumar. Que no se hagan instalaciones nuevas ni se apunte a sistemas nuevos mientras dure la migración. Es la medida más barata y la que más problemas evita.
Ojo: Basta un mensaje al equipo. No hace falta política formal ni prohibiciones: en general la gente colabora si le explicas por qué.
Levanta el destino en paralelo
Monta la vía nueva contra el mismo sistema de desarrollo, sin tocar lo que ya funciona. Convivir un tiempo es normal y sano: nadie se queda tirado si algo no va.
Ojo: Si vas a ARC-1 en BTP, empieza por Principal Propagation, no lo dejes para el final: es la parte que más tarda por los certificados y el mapeo de usuarios.
Migra primero lo de solo lectura
Analizar código, buscar objetos, where-used, ATC. Es el uso más común y el que menos riesgo tiene. Si eso funciona igual de bien en la vía nueva, ya has movido a la mayoría de la gente.
orden de aperturasolo lectura → escrituras en $TMP → paquetes concretos → transportesCambia el usuario técnico por identidad real
Este es el paso que de verdad cambia la conversación con seguridad. Cuando SAP ve al usuario que está detrás en vez de una cuenta compartida, la pregunta «quién hizo esto» pasa a tener respuesta.
Ojo: Si tu escenario es automatismo puro —chequeos programados, agentes de proceso— un usuario técnico sigue siendo razonable. Lo importante es que sea una decisión consciente y escrita, no lo que quedó por defecto.
Apaga lo viejo y limpia detrás
Solo cuando lo nuevo lleve semanas funcionando. Y limpiar significa limpiar de verdad, no solo dejar de usarlo.
- Desinstalar
- El servidor MCP local de cada portátil
- Borrar
- Ficheros de configuración con credenciales
- Cambiar
- La contraseña del usuario técnico que estuviste usando
- Revisar
- Si ese usuario sigue necesitando sus autorizaciones
- Documentar
- Qué había, qué hay ahora y por qué se cambió
Ojo: Cambiar la contraseña del usuario técnico es el paso que todo el mundo se salta. Esa credencial ha estado en varios portátiles: darla por perdida es lo prudente.
El error más común de estas migraciones
Apagar lo viejo antes de tiempo. La gente vuelve a instalárselo por su cuenta, esta vez sin avisar, y acabas peor que al principio: con las mismas instalaciones locales pero sin saber cuántas hay. Convive el tiempo que haga falta, y apaga cuando nadie eche de menos lo anterior.
Lo que te va a preguntar seguridad
Ten estas respuestas preparadas y la reunión dura quince minutos en vez de tres semanas.
| Te preguntarán | Puedes responder |
|---|---|
| ¿La IA puede hacer cosas que un usuario no puede? | No. El agente actúa con un usuario SAP y le aplican sus autorizaciones. Ninguna configuración de MCP se salta un objeto de autorización |
| ¿Dónde están las credenciales? | En el destino de BTP o en el servidor central, no en portátiles. Con Principal Propagation, ni siquiera hay contraseña que guardar |
| ¿Podemos saber quién hizo qué? | Sí: identidad propagada al backend y eventos de auditoría en la plataforma |
| ¿Puede escribir en producción? | No. Una instancia por sistema, con productivo en solo lectura por configuración del servidor, no por confianza |
| ¿Y si el modelo se equivoca? | Los cambios pasan por los mismos controles de siempre: chequeo de sintaxis, ATC, pruebas unitarias, transportes y revisión humana |
| ¿Esto cumple la política de SAP? | Es el canal de desarrollo, no las APIs de negocio. SAP publicó su propio servidor MCP sobre él en Sapphire 2026 |
Cómo saber que has terminado
Si puedes marcar las seis, la migración está cerrada de verdad.
No queda ningún servidor MCP local apuntando a un sistema con datos reales
Ninguna contraseña de SAP vive en el portátil de nadie
SAP registra al usuario real, no a una cuenta compartida
Los permisos están acotados por configuración, no por confianza
Hay un sitio donde consultar qué hizo el agente y cuándo
Existe un documento de una página que explica el montaje
Para la próxima persona que pregunte, que no serás tú.