Move from APIM to APIM 3.0

If your organization is moving from APIM to API Management 3.0, it will help to understand the basic conceptual differences. This topic compares terms and concepts and introduces the automated migration process.

APIM compared with API Composer

In API Management 3.0, Services are SnapLogic assets just like tasks and pipelines. This makes it easier to organize and manage them. You also define Policies independently, which makes them easier to reuse.

The following table maps APIM terms and components to APIM 3.0.


APIM	APIM 3.0
API Manager: Console to define and manage API Versions, Proxies, and Policies.	ServiceManager: Interface for defining Services, Policies, and. For existing APIM customers, includes access to API Manager, Portal Manager, and a Migration tool.
Portal Manager: Interface for setting up and managing the Developer Portal.	Site Manager: Interface for setting up and managing the DeveloperHub.
Developer Portal: Makes APIs and Proxies available to internal and external consumers.	DeveloperHub: Makes Services available to internal and external consumers. Admins define the look and feel with themes and customizable components.
API Version: A Triggered or Ultra Task endpoint with a user-applied version and Policies.	Service Version: A collection of Triggered Task, Ultra Task, or external endpoints with a user-applied version and Policies.
Proxy Version: Collection of one or more external endpoints.	Service: One or more endpoints, which can include references to Triggered and Ultra Tasks, or external URLs with a user-applied version and Policies.
Policy: Authentication/authorization, traffic management, transformation logic, and request validation applied to a specific API version or Proxy.	Policy: A collection of rules. Rules were called Policies in APIM. Policies are reusable, they can apply to all Services, individual Services, or specific Service endpoints.

Introduction to API migration

If APIM assets exist in your environment and both APIM and API Management 3.0 features are enabled, API Management 3.0 includes a Migration Tool and pages to access the legacy API Manager, Portal Manager, and Subscription Manager:

API Management 3.0 with legacy APIM pages

Migration wizard

The migration wizard guides you through three main steps:

Select one or more API and Proxy versions to migrate.
Migrate the associated Policies or disable the Migrate Policies toggle to use Policies from API Management 3.0 Policy Catalog after migration.
Select the location for the migrated assets.

When you start migration of one or more assets, the migration process happens in the background and you can continue working. Notifications inform you about the status of migration for each asset. A migration that fails for some reason doesn't block other migrations.

To migrate assets, the SnapLogic Platform:

For an API Version, creates a Service Version with the same name, description, endpoints, accounts, files, tags, and status.
For a Proxy and its endpoints, creates a Service Version with the same name. Each Proxy endpoint and each mapping rule becomes a Service endpoint.
Creates Service Policies that correspond to the Proxy Policies. All Policies on a Proxy become rules in one Policy associated with the new Service and all of the new endpoints. Proxy endpoint Policies become rules in a Policy associated with the new Service endpoint.
Copies the assets related to the API or Proxy to the Service version and saves the Service version in the project you select.
Resolves the references to the new location.
Tracks the number of times an API or Proxy is migrated.
Locks the original API or Proxy so that it can't be changed. You should make all updates to the Service in APIM 3.0.

A successful migration results in the addition of a Service version in the Services Catalog. No changes are made to the original API Version, Proxy, or any assets. Calls to the original URL of a migrated API Version continue to be processed by the original API Version until the new Service created by migration is published. Refer to the Migration reference page for details on how API Management 3.0 migrates specific assets.

Important: Always test and validate the behavior of a migrated Service before publishing it.

Known limitations

In API Management 3.0 the Service name must be unique in a project and the URL slug must be unique in an environment. If you try to migrate an API Version or Proxy into a location where that name already exists, the migration process appends an underscore and a number to the name.
APIM Policies created in Classic Manager from the Project menu Manage API Policy option aren't included in migration because they aren't part of the API version:
Mapping expressions are migrated as is. You should check to make sure that they make sense in the context of the new Service. For example, an expression that relies on uri.pathsegment[1] might not behave as expected.
You might have to adjust the URL that you use to call an external endpoint migrated from a Proxy. The default behavior of API Management 3.0 is to append the end of the path to the URL. For example, for an upstream path of https://google.com with a path of list list, if a user calls https://google.com/list/apps, the URL is updated to https://google.com/apps. If mapping rules append values to the upstream URL, make sure to modify the upstream URL.