W-19688912 ch1 to ch2 migration

modules/ROOT/nav.adoc

@@ -3,6 +3,7 @@
 * xref:partner-manager-release-notes.adoc[Release Notes]
 * xref:get-started.adoc[Getting Started with Partner Manager]
 * xref:partner-manager-architecture.adoc[Partner Manager Architecture]
+* xref:ch2-migration.adoc[Partner Manager CloudHub 2.0 Migration Guide]
 * xref:setup.adoc[Setting up the Partner Manager Environment]
   ** xref:deploy-partner-manager.adoc[]
   ** xref:cloudhub-deployment-settings.adoc[]

modules/ROOT/pages/ch2-migration.adoc

@@ -0,0 +1,125 @@
+= Partner Manager CloudHub 2.0 Migration Guide
+
+To migrate your B2B operations from CloudHub 1.0 (CH1) to the more advanced CloudHub 2.0 (CH2), follow the relevant path in this guide based on your deployment scenario.
+
+* <<migration-with-vpc-and-dlb-with-url-preservation>>
+* <<migration-with-vpc-and-dlb-without-url-preservation>>
+* <<shared-load-balancer-migration-to-a-private-space>>  
+
+[#migration-with-vpc-and-dlb-with-url-preservation]
+== Migration With VPC and DLB with URL Preservation
+
+This path is for customers migrating from a CH1 Virtual Private Cloud (VPC) with a Dedicated Load Balancer (DLB) who must preserve their external URLs for zero-downtime transition. The process keeps critical CH1 inbound apps active, updates the target environment via API, and uses the CH1 to CH2 Migration Tool to create CH2 counterparts that inherit existing URLs. Finally, traffic is incrementally shifted from CH1 to CH2 before the DLB is failed over and retired.
+
+. Follow the steps on the xref:cloudhub::vpc-upgrade.adoc[] page to upgrade your CH1 Anypoint Virtual Private Cloud (Anypoint VPC) to a CH2 private space.
+. In Runtime Manager:
+.. Stop all inbound Partner Manager applications deployed to CH1.
+.. Make sure you don't have any inflight messages.
+.. Delete these Partner Manager deployed applications but not the `inbound-as2` and `inbound-http` applications:
+... b2b-outbound-*
+... b2b-document-processing-service-*
+... b2b-api-replication-service-*
+
+[NOTE]
+Don't undeploy your message flows in Partner Manager as part of this process.
+
+[start=2]
+. On the Business Groups > Partner Manager tab in Access Management:
+.. Click *Edit Configuration* for the environment you want to update.
+.. Select CloudHub 2.0 from the *Deployment Target Type* dropdown.
+.. In the *Deployment Target* dropdown, select the private space that was configured previously.
+.. Before saving, open your browser's developer tools and navigate to the *Network* or equivalent tab to make sure the Method column is enabled.
+.. Click *Save* in Access Management.
+.. Check the *I understand the effects of this action* box and click *Save*. Ignore the error message about the target runtime type.
+. In your browser's developer tools:
+.. Right-click on the most recent PUT request, and then hover over *Copy* and select *Copy as CURL*.
+.. Paste the CURL command into your preferred API Client, such as  Postman. Set *forceUpdate* to True by updating the URL.
+.. Send the PUT request.
+. In Access Management, refresh the Partner Manager tab. The deployment target is now CH2.
+. In Runtime Manager, start the `inbound-as2` and `inbound-http` applications.
+[NOTE]
+Incoming messages are delivered to Anypoint MQ but aren't processed until the CH1 app is running. For the app switching to work, ensure the CH1 app is in a Running state.
+
+. Use the CH1 to CH2 migration tool xref:cloudhub::app-migration.adoc[] to upgrade the deployment for the `inbound-as2` and `inbound-https` applications, which creates their counterparts in CH2.
+.. Make sure the application name remains the same.
+.. Use a dummy jar file with the same name, "dummy jar." You can use any placeholder jar file, since the file is overwritten in a later step with the correct jar file.
+.. Preserve the ingress urls. Initially, the name resolution is 0% for CH2 and 100% for CH1.
+. On the Message Flows tab in Partner Manager:
+.. Click *Manage Deployments* and choose either *Upgrade deployments* or *Apply environment settings*, which redeploys all Partner Manager applications without requiring you to redeploy individual message flow.
+.. Check *I understand the effects of these actions* and click *Confirm*.
++
+Partner Manager deploys and updates the corresponding apps in CH2 that were deployed with dummy jar files.
++
+Before shifting traffic, keep the CH1 inbound AS2 and HTTP applications running and handling 100% of the traffic to confirm they're functioning as expected post-migration.
+. In Runtime Manager, increase the traffic on the CH2 app incrementally over a period of a few days until it reaches 100%. Keep the CH1 apps in a Shutdown status after traffic reaches 100%.
+. After you've stopped all CH1 applications that use the DLB, failover the DLB domain (anypointdns.net) to CH2 and delete the DLB.
+
+New message flow deployments in Partner Manager beyond this point only update the CH2 apps.
+
+
+[#migration-with-vpc-and-dlb-without-url-preservation]
+== Migration With VPC and DLB Without URL Preservation
+
+This path is for customers who choose not to preserve external URLs when migrating from a CH1 Anypoint VPC with a DLB. Migration involves decommissioning all existing CH1 applications, upgrading the environment target via an API call, and then redeploying all applications directly to a new CH2 Private Space by using Partner Manager's deployment management tool.
+
+. Follow the steps on the xref:cloudhub::vpc-upgrade.adoc[] page to upgrade your CH1 Anypoint VPC to a CH2 private space.
+. In Runtime Manager:
+.. Stop all inbound Partner Manager applications deployed to CH1.
+.. Make sure you don't have any inflight messages.
+.. Delete these Partner Manager deployed applications:
+... b2b-inbound-*
+... b2b-outbound-*
+... b2b-document-processing-service-*
+... b2b-api-replication-service-*
+. On the Business Groups > Partner Manager tab in Access Management:
+.. Click *Edit Configuration* for the environment you want to update.
+.. Select CloudHub 2.0 from the *Deployment Target Type* dropdown.
+.. In the *Deployment Target* dropdown, select the private space that was configured previously.
+.. Before saving, open your browser's developer tools and navigate to the *Network* or equivalent tab to make sure the Method column is enabled.
+.. Click *Save* in Access Management.
+.. Check *I understand the effects of this action* and click *Save*. Ignore the error message about the target runtime type.
+. In Developer Tools:
+.. Right-click on the most recent PUT request, and then hover over *Copy* and select *Copy as CURL*.
+.. Paste the CURL command into your preferred API Client, such as  Postman. Update the URL so that *forceUpdate* is set to True.
+.. Send the PUT request.
+. In Access Management, refresh the Partner Manager tab. The deployment target is now CH2.
+. On the Message Flows tab in Partner Manager:
+.. Click *Manage Deployments* and choose either *Upgrade deployments* or *Apply environment settings*, which redeploys all Partner Manager applications without requiring you to redeploy individual message flow.
+.. Check *I understand the effects of these actions* and click *Confirm*.
++
+Partner Manager deploys and updates the corresponding apps in CH2 that were deployed with dummy jar files.
+
+New message flow deployments in Partner Manager beyond this point only update the CH2 apps.
+
+[#shared-load-balancer-migration-to-a-private-space]
+== Shared Load Balancer Migration to a Private Space
+
+This section details the straightforward path for customers moving applications from CH1 with a Shared Load Balancer (SLB) to a CH2 Private or Shared Space. Migration involves stopping and deleting all applications in CH1, updating the environment target via API, and then redeploying all applications directly to the new CH2 space by using the deployment management tool.
+
+. In Runtime Manager:
+.. Stop all inbound Partner Manager applications deployed to CH1.
+.. Make sure you don't have any inflight messages.
+.. Delete these Partner Manager deployed applications:
+... b2b-inbound-*
+... b2b-outbound-*
+... b2b-document-processing-service-*
+... b2b-api-replication-service-*
+. On the Business Groups > Partner Manager tab in Access Management:
+.. Click *Edit Configuration* for the environment you want to update.
+.. Select CloudHub 2.0 from the *Deployment Target Type* dropdown.
+.. In the *Deployment Target* dropdown, select the private space or shared space.
+.. Before saving, open your browser's developer tools and navigate to the *Network* or equivalent tab to make sure the Method column is enabled.
+.. Click *Save* in Access Management.
+.. Check the *I understand the effects of this action* box and click *Save*. Ignore the error message about the target runtime type.
+. In Developer Tools:
+.. Right-click on the most recent PUT request, and then hover over *Copy* and select *Copy as CURL*.
+.. Paste the CURL command into your preferred API Client, such as Postman. Update the URL so that *forceUpdate* is set to True.
+.. Send the PUT request.
+. In Access Management, refresh the *Partner Manager* tab. The deployment target is now CH2.
+. On the Message Flows tab in Partner Manager:
+.. Click *Manage Deployments* and choose either *Upgrade deployments* or *Apply environment settings*, which redeploys all Partner Manager applications without requiring you to redeploy individual message flow.
+.. Check *I understand the effects of these actions* and click *Confirm*.
++
+Partner Manager deploys and updates the corresponding apps in CH2 that were deployed with dummy jar files.
+
+New message flow deployments in Partner Manager beyond this point only update the CH2 apps.