Anypoint Code Builder: la guía de migración desde Cloud IDE (2026)

El 31 de agosto de 2026 MuleSoft retiró oficialmente Anypoint Studio Cloud IDE. Si todavía tenías proyectos abiertos ahí, ya no hay vuelta atrás: el camino oficial hacia adelante es Anypoint Code Builder, la extensión de VS Code que Salesforce/MuleSoft lleva empujando como sucesor desde 2024.

Si te certificaste hace un par de años con Cloud IDE, esto no es un simple cambio de interfaz. Cambia el flujo de trabajo, el sistema de proyectos y, en buena parte, cómo se diseñan las APIs desde el principio.

Por qué importa este cambio

Anypoint Code Builder no es «Cloud IDE con otro logo». Es una extensión nativa de VS Code (también hay versión de escritorio) que:

• Usa el Language Server Protocol para autocompletado de DataWeave y flujos, en vez del motor propio de Studio.
• Integra el diseño de API directamente con OAS 3.0 como formato preferente (RAML sigue soportado, pero deja de ser el camino recomendado — más sobre esto en nuestra guía de OAS 3.0 en MuleSoft).
• Se apoya en Git desde el primer minuto: cada proyecto nuevo espera un repositorio, no una carpeta suelta.
• Corre en local o en la nube (Anypoint Code Builder Cloud), a diferencia de Cloud IDE que era 100% navegador.

Paso 1: instalar la extensión

1. Instala Visual Studio Code (si no lo tienes).
2. Ve al Marketplace de extensiones y busca «Anypoint Code Builder».
3. Inicia sesión con tu cuenta de Anypoint Platform desde el panel lateral que añade la extensión.
4. Verifica la versión de Java: Code Builder exige JDK 17 como mínimo para los runtimes 4.6+.

Paso 2: migrar un proyecto existente de Studio/Cloud IDE

No existe un botón mágico de «importar y listo». El proceso real es:

1. Exporta el proyecto desde tu Studio de escritorio (si lo tenías) o descarga el .zip desde Cloud IDE antes de que desaparezca del todo (si aún tienes acceso a un export histórico).
2. Abre la carpeta del proyecto directamente en VS Code — Code Builder detecta automáticamente la estructura Mule (src/main/mule, pom.xml).
3. Revisa el pom.xml: los proyectos antiguos apuntan a versiones de mule-maven-plugin que Code Builder puede marcar como obsoletas. Actualízalas a la última compatible con tu runtime.
4. Si tu API estaba definida en RAML, puedes dejarla así — Code Builder la sigue soportando — pero cualquier API nueva que crees desde el editor visual se genera directamente en OAS 3.0.

Paso 3: diferencias de flujo que te van a sorprender

• Depuración: el debugger de Code Builder se apoya en breakpoints de VS Code, no en la vista de Studio. Si estabas acostumbrado a inspeccionar el payload en cada paso desde la interfaz visual, la lógica es la misma pero los paneles están reorganizados.
• DataWeave Playground: sigue existiendo, pero ahora vive como panel lateral con recarga en caliente — es más rápido que el de Cloud IDE para probar transformaciones sueltas.
• Despliegue: Code Builder despliega directamente a CloudHub 2.0 desde el propio editor; ya no hace falta exportar el .jar y subirlo a mano si no quieres.

Qué NO cambia

La lógica de los conectores, los flujos, DataWeave como lenguaje de transformación y los conceptos de API-led connectivity siguen exactamente igual. Si te certificaste como MCD-L1 con Cloud IDE, tus conocimientos siguen siendo 100% válidos — lo que cambia es la herramienta, no la arquitectura.

Checklist rápido de migración

• [ ] VS Code + extensión Anypoint Code Builder instalados
• [ ] JDK 17+ configurado
• [ ] Proyecto exportado desde Studio/Cloud IDE antes del cierre
• [ ] pom.xml revisado y actualizado
• [ ] Primer despliegue de prueba a un entorno Sandbox desde el nuevo editor

Si estás preparando la certificación MuleSoft ahora mismo, en nuestro curso de certificación MuleSoft Developer I ya trabajamos íntegramente con Anypoint Code Builder y OAS 3.0 desde el módulo 1, así que no tienes que hacer esta migración por tu cuenta: partes directamente con las herramientas actuales.