​

Migrate Legacy Non-Orchestrated CE Site to SMSv2

Published December 6, 2025 | Last modified December 5, 2025

Objective

This guide provides instructions for NetOps teams migrating a legacy Customer Edge (CE) Site — whether standalone or part of a Virtual Site (vSite) — to the Secure Mesh Site v2 Site in F5 Distributed Cloud Console. The goal is to ensure a seamless, phased, and verifiable transition with minimal service disruption, while offering rollback paths and validation procedures at each stage.

This guide also provides a detailed walkthrough to help you successfully migrate a legacy Customer Edge (CE) site to the newer Secure Mesh Site v2 Site in F5 Distributed Cloud Console. This explains the complete migration workflow for CE sites deployed as:

This guide also includes pre-migration planning, maintenance window execution, traffic redirection, rollback, and post-migration cleanup.

Planning

Read the following documents before deploying a Secure Mesh Site in any provider environment:

Important: After you deploy the CE Site, the IP address for the SLO interface cannot be changed. Also, the MAC address cannot be changed.

Prerequisites

  • An F5 Distributed Cloud Account. If you do not have an account, see Getting Started with Console.

  • One or more devices or virtual machines (VMs) consisting of interfaces with Internet reachability for site deployment.

  • Resources required per node: Minimum 8 vCPUs, 32 GB RAM, and 80 GB disk storage. For a full listing of the resources required, see Customer Edge Site Sizing Reference guide. All the nodes in a given CE Site should have the same resources regarding the compute, memory, and disk storage. When deploying in cloud environments, these nodes should use the same instance flavor.

  • Internet Control Message Protocol (ICMP) needs to be opened between the CE nodes on the Site Local Outside (SLO) interfaces. This is needed to ensure intra-cluster communication checks.

  • Optional, configure your firewall or proxy server to allow connections from and to the IP addresses listed in the F5 Customer Edge IP Address and Domain Reference for Firewall or Proxy Settings guide.

Determine Whether Your Site Uses the Virtual Site Model

To determine whether your CE Site is using the Virtual Site (vSite) deployment model, follow the steps below.

  • Navigate to the Multi-Cloud Network Connect workspace.

  • Locate your Site and select it.

  • Select Manage Configuration > Edit Configuration.

  • Check whether a Virtual Site label is configured under the Labels field, in the Metadata section.

  • If a label is present, follow the Virtual Site (vSite) deployment model section.

  • If no label is present, follow the Standalone Cluster deployment model section.

High-Level Migration Process Overview

Here is a high-level summary of the migration process from legacy CE Site types to Secure Mesh Site v2. This migration process involves creating a new Secure Mesh v2 Site, validating its functionality, redirecting traffic during a planned maintenance window, and finally decommissioning the legacy Site once the migration is successfully validated.

Two migration paths are supported: one for Standalone Cluster deployments and one for Virtual Site (vSite) deployments. Refer to this section to determine which option applies to your Site.

The migration process is executed in the following phases:

Pre-Maintenance Window

  • Provision a new SMSv2 using the same settings as the existing site.

  • Plan for changes to user-managed infrastructure components (for example, DNS records, network load balancers, and NAT gateways) that must be updated during migration.

  • Optionally, create a temporary test load balancer and test origin pool to validate that the new SMSv2 site is functioning as expected.

During Maintenance Window

  • Redirect all production traffic to the newly provisioned SMSv2 site.

  • Update DNS records or network load balancer configurations as required.

  • If an issue occurs, traffic can be reverted to the original site.

Note: For CE sites that use a Site Mesh Group or a DC Cluster Group, both old site and new site may temporarily communicate during phased migration.

  • Once traffic is fully operating through the new SMSv2 and validation is complete, decommission the old site.

Identify Migration Path and Deployment Model

There are two migration paths that you can use, depending on how your existing CE Site is deployed. Before you begin the migration, you must identify which deployment model applies to your site, as the end-to-end workflow differs for each model.

Standalone Cluster Deployment Model

In this model, the CE Site operates independently and is not attached to a vSite construct. The migration procedure involves provisioning a new SMSv2 instance that mirrors the existing configuration, validating functionality, and then shifting traffic during a planned maintenance window all at once.

Virtual Site Deployment Model

In this model, the CE Site participates in a vSite configuration using labels. The migration workflow includes additional steps to ensure the new SMSv2 is properly added to the vSite grouping.

Refer to the appropriate section below for the step-by-step procedure based on your deployment model.

Standalone Cluster Deployment Model

For standalone cluster deployments, here are the step-by-step instruction to be followed in phases:

Phase-1: Pre-Maintenance Window

These steps can be executed before the maintenance window happens.

Step 1: Create SMSv2.

You must deploy your new Secure Mesh Site v2 with the same infrastructure properties (in other words. vCPU, RAM, disk, and number of interfaces) and same provider as your existing legacy site. See Create Secure Mesh Site v2 document for this.

Important: If Common V4 IP is configured for your legacy site, then a different VIP address must be provided in the Common V4 IP setting of the Secure Mesh Site v2 to avoid IP address overlaps.

Step 2: Identify the DNS, network load balancer, and routing infrastructure changes.

Identify and plan for necessary DNS, network load balancer, and routing infrastructure changes that need to be executed during the maintenance window for traffic to switch to the new Secure Mesh Site v2.

Step 3: Optionally, create a new test HTTP or TCP load balancer.

This optional step is only needed if you want to test the newly created SMSv2 for traffic handling (before using this site for production traffic).

Create a new test load balancer and test origin pool that use the newly created SMSv2 and validate it with test traffic.

Phase-2: During Maintenance Window

You must execute these steps only within the maintenance window. During this window, all production traffic switches to the newly provisioned SMSv2.

Step 1: Validate SMSv2 is healthy and online.

  • Validate that the SMSv2 admin state is online and the Site Health score is 100.

  • Ensure that there are no active alerts with alert level Critical for the newly provisioned SMSv2.

Step 2: Create a new origin pool.

  • Create a new origin pool using the SMSv2 created in the previous step. Refer to the Create Manage Origin Pools guide.

  • Ensure the new origin pool has the same settings as the origin pool used with the legacy site.

Step 3: Transition load balancer to use the new SMSv2.

After you verify that the SMSv2 is online and healthy, you can move the load balancer over to this new SMSv2.

Depending on where the VIP is advertised, the steps to follow vary:

  • Refer to Step 3A if the VIP is advertised on the Internet.

  • Refer to Step 3B if the VIP is advertised on the CE Site.

Step 3A: Configure load balancer advertised on Internet (specified VIP).

  • Find and select the load balancer in the Multi-Cloud App Connect workspace.

  • Edit the Origin section settings to add a new origin pool with the desired Weight. Examples include:

    • 100 (old origin pool), 0 (new-origin-pool) > 100% of production traffic is served by old site.
    • 80 (old origin pool), 20 (new-origin-pool) > 80% of production traffic is served by old site and 20% new site.
    • 0 (old origin pool), 100 (new-origin-pool) > 100% of production traffic is served by new site.

Note: You can modify the Weight while keeping the same Priority for all origin pools. This provides for a gradual transition.

  • Decommission your old site after the Weight of new origin pool is set to 100. All production traffic is now served by the new SMSv2.

  • Once the new SMSv2 is serving production traffic, verify all production traffic is working as expected.

  • Verify that the new SMSv2 remains healthy and that there are no critical active alerts on the SMSv2 dashboard.

  • After you validate that the new SMSv2 is operating as expected, delete your old site from the Origins configuration in the load balancer.

  • If you need to revert the traffic back to legacy site, edit the load balancer Origins settings to modify the Weight:

    • 100 (old origin pool), 0 (new-origin-pool) > 100% of the production traffic will be served by old site. All traffic switches back to the legacy site.
Step 3B: Configure load balancer advertised on CE Site.

  • Find and select the load balancer in the Multi-Cloud App Connect workspace.

  • Modify the load balancer Other Settings. From the VIP Advertisement drop-down menu, select Custom. Select Configure.

  • Add the new SMSv2 and the old site to Custom Advertise VIP Configuration. This configuration setting advertises the load balancer on both the old and new CE sites.

  • Add a new origin pool to the load balancer, with the following Weight, so that traffic gradually moves to the new SMSv2. Examples include:

    • 100 (old origin pool), 0 (new-origin-pool) > 100% of production traffic is served by old site.

    • 80 (old origin pool), 20 (new-origin-pool) > 80% of production traffic is served by old site and 20% new site.

    • 0 (old origin pool), 100 (new-origin-pool) > 100% of production traffic is served by new site.

Note: You can modify the Weight while keeping the same Priority for all origin pools. This provides for a gradual transition.

  • Update any public DNS records so that all production traffic lands only on the new SMSv2. All production traffic is now migrated to the new SMSv2.

  • Verify all production traffic is working as expected.

  • Verify that the new SMSv2 remains healthy and that there are no critical active alerts on the SMSv2 dashboard.

  • Modify the load balancer settings to delete the old site entry from the Custom Advertise VIP Configuration settings.

  • Remove the old site from the Origins section origin pool settings.

  • If you need to revert the traffic back to the legacy site:

    • Modify the load balancer settings to remove the new SMSv2 from the Custom Advertise VIP Configuration settings.
    • For the Origins settings, modify Weight to 100 (old origin pool), 0 (new-origin-pool). This action returns 100% of the production traffic to the old site.

Virtual Site Deployment Model

If your CE Site is part of a Virtual Site, here are the step-by-step instruction to be followed in phases:

Phase-1: Pre-Maintenance Window

These steps can be executed before the maintenance window happens.

Step 1: Create a new SMSv2.

Create a new SMSv2 with the same infrastructure properties (in other words, vCPU, RAM, disk, and number of interfaces) and same provider as the existing legacy site. See the Create Secure Mesh Site v2 guide for more information.

Important: If Common V4 IP is configured for your legacy site, then a different VIP address must be provided in the Common V4 IP setting of the Secure Mesh Site v2 to avoid IP address overlaps.

Step 2: Identify the DNS, network load balancer, and routing infrastructure changes.

Identify and plan for necessary DNS, network load balancer, and routing infrastructure changes that need to be executed during the maintenance window for traffic to switch to the new SMSv2.

Step 3: Optionally, create a new test HTTP or TCP load balancer.

This optional step is only needed if you want to test the newly created SMSv2 for traffic handling (before using this site for production traffic).

Create a new test load balancer and test origin pool that use the newly created SMSv2 and validate it with test traffic.

Phase-2 - During Maintenance Window

You must execute these steps only within the maintenance window. During this window, all production traffic switches to the newly provisioned SMSv2.

Step 1: Validate SMSv2 is healthy and online.

  • Validate that the SMSv2 admin state is online and the Site Health score is 100.

  • Ensure that there are no active alerts with alert level Critical for the newly provisioned SMSv2.

Step 2: Add new SMSv2 to vSite.

Edit the new SMSv2 configuration to add the required labels to add to the vSite (that the legacy site is part of).

Step 3: Transition the load balancer to use the new SMSv2.

After you verify the SMSv2 is online and healthy, you can transition the load balancer over to the new SMSv2. The steps will vary depending on how the virtual site is used in the load balancer and the origin pool settings:

Step 3A: Transition to new SMSv2.

When both the load balancer and origin pool are using the vSite construct, and the vSite label is added to the new SMSv2, the origin is discovered on the new SMSv2. The load balancer is advertised to the new SMSv2 as well.

Step 4: Remove the legacy Site from vSite.

Edit the legacy site configuration to remove the required labels to dissociate it from the vSite.

Step 5: Update other network infrastructure.

Update the public DNS records, network load balancer, and any other routing infrastructure to ensure all production traffic diverts to the new SMSv2.

Step 6: Validate that the SMSv2 is healthy.

  • Once the new SMSv2 is serving production traffic, verify all production traffic works as expected.

  • Verify that new SMSv2 remains healthy and Site Alerts page does NOT have any critical active alerts.

  • If the legacy site was part of a Site Mesh Group (SMG), ensure that all site-to-site tunnels are formed with the new SMSv2. Validate those tunnels are up and running.

To create a load balancer on the CE Site, see the HTTP Load Balancer guide, or the TCP Load Balancer guides.

To create an origin pool, see the Create Origin Pool guide.

Concepts

On this page: