5 consejos para migrar desde 3scale

3scale deja de tener mantenimiento en junio de 2027. Te contamos cinco claves para migrar tu plataforma de APIs sin romper nada por el camino.

Red Hat ha fijado fecha para el final de 3scale API Management. El servicio gestionado (SaaS y Red Hat OpenShift API Management) se apaga el 30 de junio de 2027. En la versión autogestionada, el mantenimiento termina ese mismo día, con soporte extendido opcional hasta el 30 de junio de 2029.

SaaS y fin de mantenimiento 30 jun 2027

Soporte extendido (opcional) 30 jun 2029

Por tanto, si tu organización publica APIs sobre 3scale, la pregunta ya no es si migrar, sino cómo y cuándo. Red Hat propone Red Hat Connectivity Link o IBM API Connect como alternativas, aunque también hay partners y otras plataformas del mercado. Sea cual sea el destino, estos cinco consejos te ayudarán a planificar una migración ordenada.

5 consejos para migrar desde 3scale

 

1Haz inventario y exporta la configuración antes de decidir nada

Antes de elegir plataforma, necesitas saber qué tienes. Lista productos, backends, mapping rules, métricas, planes de aplicación y políticas de APIcast. Además, identifica qué APIs tienen tráfico real y cuáles se pueden retirar.

Para ello, el 3scale toolbox te permite exportar cada producto a YAML con 3scale product export. Ese export incluye backends, mapping rules, métricas, límites, pricing rules y políticas.

Ojo: las cuentas, aplicaciones y credenciales de los consumidores quedan fuera del export, así que tendrás que planificarlas aparte.

2Traduce conceptos, no copies configuración

Ninguna plataforma de destino replica el modelo de 3scale uno a uno. Por eso conviene traducir cada concepto a su equivalente. Por ejemplo, en Red Hat Connectivity Link, basado en Kuadrant, Gateway API y Envoy:

En 3scale	En Connectivity Link
Producto y mapping rules	Gateway y HTTPRoute
Autenticación de APIcast	AuthPolicy
Límites de los planes	RateLimitPolicy
Certificados y dominios	TLSPolicy y DNSPolicy

Además, revisa con lupa las políticas personalizadas en Lua. Normalmente hay que reescribirlas o sustituirlas por capacidades nativas del nuevo gateway.

3Planifica la migración de consumidores y credenciales

Para tus consumidores, la migración debería ser casi invisible. Decide qué harás con las API keys y los pares app_id y app_key:

• Migrarlas tal cual a la nueva plataforma.
• Regenerarlas y comunicarlas a cada consumidor.
• Pasar a OAuth 2.0 y OpenID Connect con tu proveedor de identidad.

También debes decidir dónde vivirá el portal de desarrolladores. Después, comunica fechas y cambios con antelación. Un calendario claro evita incidencias y llamadas de última hora.

4Migra por fases y con convivencia

Evita el big bang. Es más seguro hacer convivir ambas plataformas y mover el tráfico de forma progresiva, API por API. Empieza por APIs internas o de bajo riesgo y deja las críticas para el final.

En cada fase, define criterios de éxito y un plan de vuelta atrás. Del mismo modo, compara latencia, errores y consumo entre la plataforma antigua y la nueva antes de apagar nada. Los contract tests sobre tu especificación OpenAPI te ayudan a confirmar que el comportamiento no cambia.

5Aprovecha la migración para reforzar el gobierno de tus APIs

Una migración es el mejor momento para ordenar la casa. Asegura que cada API tiene una especificación OpenAPI actualizada y un propietario claro. Además, aplica reglas de diseño con linters y automatiza el despliegue de configuración desde Git.

Así, la nueva plataforma no hereda la deuda técnica de la anterior. Y la próxima migración, cuando llegue, será mucho más sencilla.