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

Daniel_Cimpeanu — Wed, 22 Oct 2025 14:26:41 GMT

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

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

the_rock — Wed, 22 Oct 2025 14:39:33 GMT

Hey Daniel,

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

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

the_rock — Wed, 22 Oct 2025 14:42:15 GMT

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

Prepare the New VSX Cluster on R81.20
Create Corresponding VSes on the New Cluster
Export and Import Policy/Objects per VS (CMA/DMS)
Migrate Connectivity (Routing, Interfaces, NATs, etc.)
Test and Validate Traffic
Switch Over (Cutover) Traffic
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.

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

emmap — Fri, 24 Oct 2025 02:07:48 GMT

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.

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

the_rock — Sat, 25 Oct 2025 17:49:11 GMT

I believe Dan what @emmap suggested makes most sense.

topic Re: R77.30 VS migration from legacy VSX cluster to new one on R81.20 in General Topics

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

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

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

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

✅ High-Level Plan Overview

🔧 Detailed Step-by-Step

1. Prepare New VSX Cluster on R81.20

2. Create Corresponding Virtual Systems

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

4. Configure Routing and NAT

5. Validate

6. Cutover Plan

7. Decommission Legacy VSX Cluster

🛑 Important Considerations

✅ Summary

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

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