R77.30 VS migration from legacy VSX cluster to new one on R81.20

[Daniel_Cimpeanu]

Hi Gents,

I have the following scenario in a legacy setup:

Clustered VSX appliances on R77.30, running multiple VS under different CMA/DMS. I need to migrate some of the virtual systems to a brand new VSX cluster running on R81.20, managed by the same MDS.

What would be the best and safe approach to do that, and can it be done without intermediary steps? 
It's intended to be both a hardware and software refresh.

Thanks,

Daniel

[the_rock]

Hey Daniel,

Im sure others will provide good steps, but since its totally unsupported version in question, I would also consider contacting Professional services.

[Lesley]

First step is to pick the upgrade path and method:

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_RN/Content/Topics-RN/Support...

[the_rock · Accepted solution]

FWIW, I "dumped" your query into AI and this is what it gave.

*******

Hi Daniel,

Migrating Virtual Systems (VS) from a legacy R77.30 VSX cluster to a new R81.20 VSX cluster, especially when it’s a full hardware and software refresh, is a common scenario in Check Point environments—but it needs careful planning to avoid disruptions. Below is a safe and recommended approach based on Check Point best practices, and tailored to your MDS environment.

---

✅ High-Level Plan Overview

1. Prepare the New VSX Cluster on R81.20

2. Create Corresponding VSes on the New Cluster

3. Export and Import Policy/Objects per VS (CMA/DMS)

4. Migrate Connectivity (Routing, Interfaces, NATs, etc.)

5. Test and Validate Traffic

6. Switch Over (Cutover) Traffic

7. Decommission Old VS/Cluster

---

🔧 Detailed Step-by-Step

1. Prepare New VSX Cluster on R81.20

• Build and patch the new VSX cluster to the latest R81.20 Jumbo Hotfix (recommended by TAC).

• Add the new VSX cluster to the same MDS via SmartConsole (create new CLMs for each VS).

• Ensure the correct interface and VLAN designations are in place to match existing VS layout.

• Run vsx_util reconfigure or use SmartConsole VSX configuration wizard.

2. Create Corresponding Virtual Systems

• Manually create new Virtual Systems (VS) on the new cluster to match the old ones.

• Assign the same VS IDs and interface/VLAN assignments if possible.

• Ensure interface names and IPs don't conflict during coexistence.

❗ You can't directly copy VSX configurations between clusters, but you can reuse policy packages, NAT, routes, and objects.

---

3. Migrate Policy & Objects (Per DMS/CMA)

Since both clusters are managed by the same MDS:

• Policies, objects, and NAT rules are already available in the DMS.

• You just need to install the same policy on the new VS after it's created.

• Make any necessary adjustments (e.g., interface names, routes).

Optional: Use vsx_util export/import if you're moving a VS to the same cluster or for DR purposes—but in this case, with different hardware/VSX cluster, it's better to manually re-create the VS, and reuse the policy.

---

4. Configure Routing and NAT

• Configure routing (static/dynamic) per VS.

• Mirror NAT rules from the old VS (already in the policy).

🧪 Before proceeding, test traffic in a lab or with a subset of live traffic if possible.

---

5. Validate

• Deploy test clients to point to the new VS (if possible).

• Validate interfaces, connectivity, and logs.

• Check SIC status and policy installation on each VS.

---

6. Cutover Plan

• Coordinate cutover per VS (can be gradual, per business unit).

• At cutover:

  • Disable old VS interface / VLAN.

  • Enable corresponding interface on new VS.

  • Ensure ARP/NDP and dynamic routing propagate.

  • Use monitoring tools to confirm service uptime.

🚨 Rollback Plan: Have the old VS still in standby or disconnected mode for immediate fallback.

---

7. Decommission Legacy VSX Cluster

Once all VSes have been migrated and stable:

• Remove policies from legacy VS.

• Clean up old objects if no longer needed.

• Optionally, repurpose or retire old hardware.

---

🛑 Important Considerations

• No In-Place Upgrade: You can't upgrade VSX from R77.30 to R81.20 directly in one step. In-place upgrade would require an intermediate (e.g., R80.40), but since you're replacing hardware, this is not recommended.

• Licensing: Ensure the new cluster has appropriate VSX licenses (and per VS, if applicable).

• SIC Reset: Each new VS will need SIC established again with the management server (automatic via VSX provisioning).

• Routing Overlap: Be cautious with overlapping IPs if both clusters are live during migration. Use separate VLANs or test networks.

---

✅ Summary

You can migrate directly from R77.30 to R81.20 VSX by:

• Building new VSX cluster

• Manually recreating VSes

• Reusing existing policy from the same CMA/DMS

• Cutting over traffic per VS

No intermediary upgrade is required thanks to the hardware refresh approach.

---

Let me know if you need a sample migration template or commands to assist in this.

[emmap · Accepted solution]

There's no 'move VS' option, so you basically just have to delete the old one off the old cluster and re-create it on the new one. If you look up VSX Provisioning Tool, this can help script the basic VS creation and topology side of things. If you give it a new name you can create the new VS alongside the old one, so it's all ready for you do just move the VLANs at the switching side.

[the_rock]

I believe Dan what @emmap  suggested makes most sense.