This document explains how to migrate your client-to-Apigee (also called "northbound") routing configuration
from a managed instance group (MIG) configuration to a Private Service Connect (PSC) based
configuration.
Configure northbound routing to Apigee endpoints. For this task, follow the steps
under the External routing (PSC) tab under Configure routing in the Apigee CLI provisioning
document.
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. See
Expanding Apigee to multiple regions.
Test the new global load balancer endpoint.
When testing is complete, switch all of your existing DNS entries to point to the new
load balancer endpoint. Note the following:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[[["\u003cp\u003eThis guide explains how to migrate client-to-Apigee routing from a managed instance group (MIG) to a Private Service Connect (PSC) based configuration.\u003c/p\u003e\n"],["\u003cp\u003eThe migration is relevant for those currently using a Global external HTTPS Load Balancer (Classic) with a managed instance group (MIG) for routing traffic to Apigee and want to switch to using PSC.\u003c/p\u003e\n"],["\u003cp\u003eMigration involves configuring northbound routing to Apigee endpoints using the Apigee CLI, creating NEGs for multi-region use cases, testing the new load balancer, and switching DNS entries to the new load balancer endpoint.\u003c/p\u003e\n"],["\u003cp\u003eBecause the global external HTTPS load balancer does not support PSC NEG backends, a new global external HTTPS load balancer needs to be created and have the traffic switched to it.\u003c/p\u003e\n"]]],[],null,["# Migrate northbound routing to Private Service Connect\n\n*This page\napplies to **Apigee** , but not to **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Important:** This topic only applies to organizations that were created with VPC peering enabled. See also [Apigee networking options](/apigee/docs/api-platform/get-started/networking-options).\n\n\nThis document explains how to migrate your client-to-Apigee (also called \"northbound\") routing configuration\nfrom a managed instance group (MIG) configuration to a [Private Service Connect (PSC)](/apigee/docs/api-platform/system-administration/northbound-networking-psc) based\nconfiguration.\n\nOverview\n--------\n\nIf you are currently using the\n[managed instance group (MIG)\nbased configuration](/apigee/docs/api-platform/get-started/install-cli#configure-routing) using a [Global\nexternal HTTPS Load Balancer (Classic)](/load-balancing/docs/https) for routing external traffic to Apigee, you can choose\nto migrate this \"northbound\" traffic to use a PSC based configuration.\n| **Important:**Because the classic global external HTTPS load balancer does not support PSC NEG backends, you must create a new global external HTTPS load balancer and switch the incoming traffic through DNS.\n\nMigration steps\n---------------\n\n| **Note:** To ensure that the load balancer operates as expected, you must carry over any classic HTTPS load balancer [configurations or add-on features](/load-balancing/docs/features) to the new global load balancer.\n\n1. Configure northbound routing to Apigee endpoints. For this task, follow the steps under the **External routing (PSC)** tab under [Configure routing](/apigee/docs/api-platform/get-started/install-cli#configure-routing) in the Apigee CLI provisioning document.\n2. 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. See [Expanding Apigee to multiple regions](/apigee/docs/api-platform/system-administration/multi-region).\n3. Test the new global load balancer endpoint.\n4. When testing is complete, switch all of your existing DNS entries to point to the new load balancer endpoint. Note the following: **Note:**\n | - Different DNS providers support different kinds of routing policies. For example: [Cloud DNS supports](/dns/docs/zones/manage-routing-policies) 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.\n | - 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.\n | - Remove the old GXLB (Classic) endpoint from the DNS, and delete the old GXLB (Classic) along with the MIG backend."]]
