This page applies toApigee, but not toApigee hybrid.

View Apigee Edge documentation.

Important: This topic only applies to organizations that were created with VPC peering enabled. See alsoApigee networking options.

This document explains how to migrate your client-to-Apigee (also called "northbound") routing configuration from a managed instance group (MIG) configuration to aPrivate Service Connect (PSC) based configuration.

Overview

If you are currently using themanaged instance group (MIG) based configuration using aGlobalexternal HTTPS Load Balancer (Classic) for routing external traffic to Apigee, you can chooseto migrate this "northbound" traffic to use a PSC based configuration.

Important:Because the classic global external HTTPS load balancer does not support PSC NEG backends, youmust create a new external Application Load Balancer and switch the incoming traffic through DNS.

Migration steps

Note:To ensure that the load balancer operates as expected, you must carry over any classic HTTPS load balancerconfigurations or add-on features to the new external Application Load Balancer.

1. Configure northbound routing to Apigee endpoints. For this task, follow the steps under theExternal routing (PSC) tab underConfigure routing in the Apigee CLI provisioning document.
2. If you have multiple Apigee instances (a multi-region use case), create corresponding NEGs for each of the Apigee regions and attach them to the backend service of the load balancer. SeeExpanding Apigee to multiple regions.
3. Test the new global load balancer endpoint.
4. When testing is complete, switch all of your existing DNS entries to point to the new load balancer endpoint. Note the following:Note:
   • Different DNS providers support different kinds of routing policies. For example:Cloud DNS supports weighted round robin (WRR) routing policy, which ensures the traffic is distributed according to the configured weights. Such routing policy can be leveraged for switching the traffic between the 2 load balancer endpoints.
   • The new global external load balancer (GXLB) endpoint can be added to the customer's DNS endpoint with small weight, enough to allow 5% or 10% of their traffic. This can be slowly ramped to allow 100% of traffic on the new GXLB endpoint and 0% on the old GXLB (Classic) endpoint.
   • Remove the old GXLB (Classic) endpoint from the DNS, and delete the old GXLB (Classic) along with the MIG backend.