5 tips to migrate from 3scale

3scale maintenance ends in June 2027. Here are five keys to migrating your API platform without breaking anything along the way.

Red Hat has set an end date for 3scale API Management. The managed service (SaaS and Red Hat OpenShift API Management) will sunset on June 30, 2027. For the self-managed version, maintenance ends on the same day, with optional extended support until June 30, 2029.

SaaS sunset and end of maintenance June 30, 2027

Extended support (optional) June 30, 2029

So, if your organization publishes APIs on 3scale, the question is no longer whether to migrate, but how and when. Red Hat suggests Red Hat Connectivity Link or IBM API Connect as alternatives, although partners and other market platforms are also available. Whatever your destination, these five tips will help you plan an orderly migration.

5 tips to migrate from 3scale

 

1Take inventory and export your configuration before deciding anything

Before choosing a platform, you need to know what you have. List products, backends, mapping rules, metrics, application plans and APIcast policies. In addition, identify which APIs carry real traffic and which ones you can retire.

The 3scale toolbox lets you export each product to YAML with 3scale product export. That export includes backends, mapping rules, metrics, limits, pricing rules and policies.

Note: consumer accounts, applications and credentials are left out of the export, so you will need to plan them separately.

2Translate concepts, don’t copy configuration

No target platform replicates the 3scale model one to one. That is why you should translate each concept to its equivalent. For example, in Red Hat Connectivity Link, built on Kuadrant, Gateway API and Envoy:

In 3scale	In Connectivity Link
Product and mapping rules	Gateway and HTTPRoute
APIcast authentication	AuthPolicy
Plan limits	RateLimitPolicy
Certificates and domains	TLSPolicy and DNSPolicy

Also, review custom Lua policies carefully. They usually need to be rewritten or replaced with native capabilities of the new gateway.

3Plan the migration of consumers and credentials

For your consumers, the migration should be almost invisible. Decide what you will do with API keys and app_id and app_key pairs:

• Migrate them as they are to the new platform.
• Regenerate them and share them with each consumer.
• Move to OAuth 2.0 and OpenID Connect with your identity provider.

You also need to decide where the developer portal will live. Then, communicate dates and changes well in advance. A clear timeline prevents incidents and last-minute calls.

4Migrate in phases, with both platforms running side by side

Avoid a big bang. It is safer to run both platforms in parallel and shift traffic progressively, API by API. Start with internal or low-risk APIs and leave critical ones for last.

For each phase, define success criteria and a rollback plan. Likewise, compare latency, errors and usage between the old and new platforms before switching anything off. Contract tests on your OpenAPI specification help confirm that behavior stays the same.

5Use the migration to strengthen your API governance

A migration is the best time to put your house in order. Make sure every API has an up-to-date OpenAPI specification and a clear owner. In addition, enforce design rules with linters and automate configuration deployment from Git.

This way, the new platform does not inherit the technical debt of the old one. And the next migration, when it comes, will be much simpler.