diff --git a/pages/assets/screens/other/zerto/move2cloud-zerto.png b/pages/assets/screens/other/zerto/move2cloud-zerto.png
new file mode 100644
index 00000000000..6699991c2ab
Binary files /dev/null and b/pages/assets/screens/other/zerto/move2cloud-zerto.png differ
diff --git a/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/guide.en-gb.md b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/guide.en-gb.md
new file mode 100644
index 00000000000..6ba5ebf3f70
--- /dev/null
+++ b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/guide.en-gb.md
@@ -0,0 +1,340 @@
+---
+title: Move2Cloud - Migrate VMware workloads to OVHcloud Hosted Private Cloud with Zerto
+excerpt: "Learn how to migrate your on-premises VMware workloads to an OVHcloud Hosted Private Cloud environment using Zerto Virtual Replication"
+updated: 2025-07-17
+---
+
+## Objective
+
+This guide explains how to migrate your on-premises VMware workloads to an **OVHcloud Hosted Private Cloud (HPC)** using **Zerto Virtual Replication**.
+
+> [!primary]
+> **This guide applies to standard Hosted Private Cloud environments that are NOT part of SecNumCloud (SNC), PCI-DSS, or HDS-qualified frameworks.**
+> If you are using an SNC, PCI-DSS, or HDS-qualified Hosted Private Cloud, some features described here, such as OVHcloud IAM or NSX-T advanced networking, may not be available in SNC environments.
+> For SecNumCloud environments, please refer to the dedicated guide:  
+> [Move2Cloud - Migrating VMware Workloads to SecNumCloud Hosted Private Cloud with Zerto](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud)
+
+## Requirements
+
+Before you begin, make sure you have:
+
+- A complete inventory of your VMs, including FQDN, IP address, OS version, and application dependencies.
+- A batch migration plan grouped by application stack.
+- A full list of VLANs, subnets, and segments for your target network.
+- An HPC environment properly sized (hosts, datastores, vSAN, NSX-T).
+- A working IPsec VPN tunnel between your on-premises infrastructure and OVHcloud.
+- Access to the Zerto console and vCenter interfaces on both sides.
+
+>[!warning]
+> As of May 2025, **Zerto does not support replication of virtual machines with VMEncrypt enabled**.  
+> vSAN’s encryption at rest is supported. You can also encrypt your VMs after migration is complete.
+
+## Instructions
+
+![Move2CloudZerto](/pages/assets/screens/other/zerto/move2cloud-zerto.png){.thumbnail}
+
+### Step 1: Define your migration scope
+
+At the end of this step, you will have a structured list of workloads to migrate and the associated network design.
+
+#### Step 1.1: Create an inventory of source VMs
+
+List all virtual machines to be migrated and collect the following data:
+
+- FQDN and static IP address
+- Operating system and version
+- Application or service associated with each VM
+- Technical dependencies (for example, frontend servers depending on a database VM)
+
+This inventory allows you to group VMs into consistent application stacks for batch migration.
+
+#### Step 1.2: Group VMs into migration batches
+
+Organize your VMs into logical groups according to application-level dependencies.  
+Each batch should contain all virtual machines required to migrate and operate a single application, such as:
+
+- Web frontend VM
+- Application logic VM
+- Database backend VM
+
+#### Step 1.3: Document the current network configuration
+
+Record the full network configuration used by your source VMs:
+
+- VLAN IDs and associated subnets
+- IP address ranges to preserve
+- Inter-VM communication flows (source/destination, port, protocol)
+
+This network design will be recreated in your OVHcloud HPC tenant using `vRack` and NSX-T.
+
+You can find more about network planning in [NSX-T - First steps](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps).
+
+For additional guidance from Zerto, refer to [Installing the Zerto Solution](https://help.zerto.com/bundle/Install.HV.HTML/page/Installing_the_Zerto_Solution.htm){.external}.
+
+### Step 2: Plan Hosted Private Cloud resources
+
+This step helps you determine the required compute, storage, and network resources for your HPC environment.
+
+#### Step 2.1: Estimate CPU and memory
+
+Review your current infrastructure to calculate how many vCPUs and how much RAM you will need in the target environment.
+
+Use your existing pCPU/vCPU consolidation ratio to size the number of `ESXi hosts` required.
+
+#### Step 2.2: Define storage capacity
+
+Based on your workloads, select the most appropriate storage type:
+
+- `NFS datastores` for general-purpose workloads
+- `vSAN` for performance-intensive applications
+
+Estimate total disk space needed, plus redundancy if applicable.  
+If your workloads require high IOPS, vSAN is the preferred option.
+
+#### Step 2.3: Plan the target network
+
+Plan how your virtual network will be recreated using NSX-T:
+
+- Decide which segments will be VLAN-backed vs. overlay.
+- Identify gateway needs (Tier-0 and Tier-1).
+- Evaluate firewalling rules and north/south traffic.
+
+If you need to expose services on the internet, you can:
+
+- Request public IPs via your `Hosted Private Cloud`.
+- Migrate your existing IP ranges using the [Bring Your Own IP (BYOIP)](/links/network/byoip) feature.
+
+### Step 3: Enable access to the vCenter
+
+Access to vCenter is restricted by default in all OVHcloud HPC environments.
+
+You must explicitly allow your admin IPs to reach the `vCenter` endpoint.
+
+To do so:
+
+1. Log in to the [OVHcloud Control Panel](/links/manager).
+2. Select your `Hosted Private Cloud`{.action}.
+3. Navigate to the `Security`{.action} tab.
+4. Click `Add a new IP address range`{.action} to authorize your source infrastructure IPs and Zerto components.
+
+For step-by-step instructions, refer to [Authorise IPs to connect to vCenter](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/autoriser_des_ip_a_se_connecter_au_vcenter).
+
+### Step 4: Configure roles and permissions
+
+This step ensures that administrators and tools like Zerto have the correct access to vSphere resources within your OVHcloud Hosted Private Cloud.
+
+#### Step 4.1: Use OVHcloud IAM
+
+Set up roles and permissions in your `Hosted Private Cloud` using `OVHcloud IAM`.
+
+> [!warning]
+> **OVHcloud IAM is not available in SecNumCloud (SNC), PCI-DSS, or HDS environments.**
+> If you are using one of these qualified environments, you must configure roles and permissions directly in vSphere or use an external IAM solution such as Microsoft Active Directory or Okta.
+
+For instructions, refer to the [IAM setup guide](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_iam_getting_started).
+
+#### Step 4.2: Connect your own IAM solution
+
+If you prefer to use your existing identity provider (e.g., Active Directory or Okta), deploy a directory service directly in your OVHcloud tenant.
+
+You can also link OVHcloud IAM with your existing ADFS server to enable SAML-based SSO.
+
+To do so, follow [Connect OVHcloud IAM to ADFS](/pages/account_and_service_management/account_information/ovhcloud-account-connect-saml-adfs).
+
+#### Step 4.3: Service accounts for Zerto
+
+Zerto components require specific vSphere roles and permissions to function. You can:
+
+- Create a dedicated `zerto-admin` account in vSphere.
+- Assign the necessary privileges to manage replication and recovery.
+
+Details on required permissions are available in Zerto’s documentation:
+
+[Roles and Permissions Within Zerto](https://help.zerto.com/bundle/Admin.VC.HTML.90/page/Roles_and_Permissions_Within_.htm){.external}
+
+### Step 5: Build the target network
+
+Before starting any VM replication or failover test, your Hosted Private Cloud network must be ready to receive the workloads. This includes replicating the source structure, creating the right segments, and preparing firewall rules.
+
+#### Step 5.1: Recreate your VLANs and segments
+
+When your HPC is delivered, it comes with a default distributed virtual switch and at least one VLAN. You can add your own VLANs via the `vRack`.
+
+If you are using NSX-T, plan your segmentation as follows:
+
+- Define your segments (VLAN-backed or overlay).
+- Assign each to a corresponding application batch or service zone.
+- Recreate IP addressing schemes as defined in your inventory.
+
+Refer to [NSX-T – First steps](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps) for details on creating segments and assigning them to VMs.
+
+#### Step 5.2: Configure NSX-T routing and gateways
+
+If using NSX-T, you must define how traffic will route between segments and to the internet:
+
+- A **Tier-1 Gateway** handles internal routing.
+- A **Tier-0 Gateway** connects your environment to upstream services or external networks.
+
+These gateways are automatically deployed when NSX-T is enabled. You can review and modify them in the `NSX Manager` interface.
+
+Set up routing and services based on your flow matrix defined in Step 1.
+
+#### Step 5.3: Prepare firewall rules
+
+NSX-T provides a **distributed firewall (DFW)** that controls east-west traffic between VMs. You should define rules for:
+
+- Application-specific ports (e.g., web → app, app → db)
+- Management access to vCenter and Zerto components
+- Optional: quarantine or isolation zones for test VMs
+
+If you're not using NSX-T, implement similar rules using your preferred virtual appliance firewall (e.g., FortiVM, Stormshield, Palo Alto VM-Series).
+
+You can find an overview of how NSX handles these features in [NSX-T – First steps](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps).
+
+### Step 6: Deploy core services in the target HPC
+
+Your migrated workloads will need basic infrastructure services to function properly once they are running in your Hosted Private Cloud.
+
+#### Step 6.1: Deploy NTP
+
+Ensure all VMs and services use a consistent time source. You can configure your HPC workloads to use `ntp.ovh.net` as a reliable time server.
+
+#### Step 6.2: Deploy DNS
+
+If your applications rely on internal DNS resolution, deploy a domain controller or dedicated DNS server inside your HPC environment. This can be a clone of your on-prem server or a new instance.
+
+#### Step 6.3: Set up authentication services
+
+If your authentication is based on Active Directory, deploy a replica domain controller in the HPC.
+
+You can also establish secure communication between the on-prem AD and the tenant to avoid duplicating identities.
+
+### Step 7: Install and activate Zerto in the OVHcloud tenant
+
+Zerto is installed and managed per site. On the OVHcloud side, the components are deployed automatically when you activate Zerto.
+
+In your `Hosted Private Cloud`{.action} interface:
+
+1. Go to `Disaster Recovery`{.action}.
+2. Select `Enable Zerto Virtual Replication`{.action}.
+3. Confirm and wait for deployment.
+
+OVHcloud will deploy the following:
+
+- A dedicated ZVM (Zerto Virtual Manager).
+- A ZVRA (Zerto Virtual Replication Appliance) on each ESXi host.
+- An OVH-managed NSX-T firewall with preconfigured rules for Zerto ports.
+
+Full details can be found in [Zerto Virtual Replication on OVHcloud](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/zerto-virtual-replication-customer-to-ovhcloud).
+
+### Step 8: Install Zerto on the source site
+
+You must install Zerto components manually on your on-premises infrastructure.
+
+Follow the procedure in [Installing Zerto on source site](https://help.zerto.com/bundle/Install.VC.HTML/page/Performing_an_Express_Installation.htm){.external}.
+
+The main components are:
+
+- ZVM: Installed on a Windows Server with vSphere access
+- ZVRAs: Deployed on each ESXi host hosting protected VMs
+
+Ensure that:
+
+- TCP ports 9071, 9081 are open between ZVMs.
+- TCP ports 4007, 4008 are open between ZVRAs.
+
+### Step 9: Set up the IPsec VPN tunnel
+
+Zerto requires **direct communication** between ZVMs and ZVRAs. NAT is not supported.
+
+Set up a site-to-site IPsec tunnel between your on-prem firewall and the OVHcloud tenant.
+
+You can use any compatible device (e.g., Fortinet, Palo Alto, OPNsense).
+
+Details and parameters are available in [Zerto VPN Setup on OVHcloud](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_zerto_virtual_replication_customer_to_ovh).
+
+### Step 10: Pair the sites and create VPGs
+
+Once ZVMs are online and communication is confirmed:
+
+1. Use the Zerto console to **pair both sites**.
+2. Create your first **Virtual Protection Group (VPG)**.
+
+A VPG groups all VMs that should be replicated and failed over together.
+
+More information in [Creating a VPG](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Creating_a_VPG.htm){.external}
+
+### Step 11: Monitor the replication status
+
+Monitor each VPG from the Zerto UI:
+
+- Confirm that replication is active.
+- Check the RPO (Recovery Point Objective).
+- Resolve any alerts before running a test or failover.
+
+Refer to [Monitoring Virtual Protection Groups](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Monitoring_Virtual_Protection_Groups.htm){.external}
+
+### Step 12: Run a test failover
+
+Before migrating production workloads, test the behavior of your VMs in the OVHcloud tenant.
+
+Use the `Failover Test` option in the Zerto UI. This powers on the replicated VMs without impacting production.
+
+Instructions:
+
+- [Starting and Stopping Failover Tests](https://help.zerto.com/bundle/Admin.VC.HTML.10.0_U3/page/StartingFailoverTest.htm){.external}
+- [What Happens After Starting a Test?](https://help.zerto.com/bundle/Admin.VC.HTML.10.0_U3/page/What_Happens_After_Starting_a_Test.htm){.external}
+
+### Step 13: Execute the planned migration
+
+When you are ready to migrate:
+
+1. Use the **Move** operation in Zerto to migrate each VPG.
+2. Choose the commit policy (manual, auto, rollback).
+
+See [The Move Process](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/The_Move_Process.htm){.external} for full instructions.
+
+### Step 14: Validate application availability
+
+After the move:
+
+- Verify that all VMs are powered on.
+- Test connectivity (AD, DNS, Bastion, internet).
+- Validate each application and service.
+
+### Step 15: Commit or roll back the migration
+
+If all tests succeed, commit the operation in Zerto.
+
+If something is not working, you can cancel the move and roll back to your on-prem environment.
+
+More in [Moving Protected VMs to Remote Site](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Moving_Protected_Virtual_Machines_to_the_Remote_Site.htm){.external}
+
+### Step 16: Use Storage vMotion to place VMs on target storage
+
+After migration, you may want to move some VMs to another datastore or vSAN policy.
+
+Use `Storage vMotion`{.action} via the `vSphere Client`{.action}:
+
+1. Right-click on the VM > `Migrate`{.action}.
+2. Select `Change storage only`{.action}.
+3. Choose the destination datastore or vSAN policy.
+
+See [VMware Storage vMotion](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_storage_vmotion) for full details.
+
+### Step 17: Back up your workloads
+
+Once your VMs are in production, secure them with a backup plan.
+
+You have 2 options:
+
+- **Option 1**: Use **Veeam Backup as a Service** if you want a managed backup solution integrated with your HPC.
+- **Option 2**: Deploy your own Veeam Backup server and use **Veeam Backup & Replication for Public Cloud**.
+
+## Go further
+
+If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for a custom analysis of your project.
+
+Ask questions, give your feedback and interact directly with the team building our Hosted Private Cloud services on the dedicated [Discord](https://discord.gg/ovhcloud) channel.
+
+Join our [community of users](/links/community).
\ No newline at end of file
diff --git a/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/guide.fr-fr.md b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/guide.fr-fr.md
new file mode 100644
index 00000000000..bf7bc26b323
--- /dev/null
+++ b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/guide.fr-fr.md
@@ -0,0 +1,341 @@
+---
+title: Move2Cloud - Migration de charges de travail VMware vers OVHcloud Hosted Private Cloud avec Zerto
+excerpt: "Découvrez comment migrer vos charges de travail VMware on-premises vers un environnement Hosted Private Cloud OVHcloud à l’aide de Zerto Virtual Replication"
+updated: 2025-07-17
+---
+
+## Objectif
+
+Ce guide explique comment migrer vos charges de travail VMware on-premises vers un **Hosted Private Cloud (HPC) OVHcloud** en utilisant **Zerto Virtual Replication**.
+
+> [!primary]
+> **Ce guide s’applique aux environnements Hosted Private Cloud standards (hors SecNumCloud, PCI-DSS ou HDS).**
+> Si vous utilisez un environnement SecNumCloud, certaines fonctionnalités décrites ici comme **OVHcloud IAM**, le **vRack**, ou les **segments adossés à des VLAN** peuvent ne pas être disponibles.
+> Dans ce cas, consultez le guide suivant :
+> [Move2Cloud - Migration de charges de travail VMware vers le Hosted Private Cloud SecNumCloud avec Zerto](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud)
+
+## Prérequis
+
+Avant de commencer, assurez-vous de détenir :
+
+- Un inventaire complet de vos machines virtuelles (VM) : FQDN, adresse IP, version du système d'exploitation, dépendances applicatives.
+- Un plan de migration par lots regroupés par pile applicative.
+- Une liste complète des VLAN, sous-réseaux et segments du réseau cible.
+- Un environnement HPC correctement dimensionné (hosts, datastores, vSAN, NSX-T).
+- Un tunnel VPN IPsec fonctionnel entre votre infrastructure on-premises et OVHcloud.
+- Un accès à la console Zerto et aux interfaces vCenter sur les deux environnements.
+
+> [!warning]
+> Depuis mai 2025, **Zerto ne prend pas en charge la réplication des VM avec le chiffrement VMEncrypt activé**.
+> Le chiffrement au repos de vSAN est pris en charge. Vous pouvez également chiffrer vos VM après la migration.
+
+## En pratique
+
+![Move2CloudZerto](/pages/assets/screens/other/zerto/move2cloud-zerto.png){.thumbnail}
+
+### Étape 1 : Définir votre périmètre de migration
+
+À la fin de cette étape, vous détiendrez une liste structurée des charges de travail à migrer et la conception du réseau associée.
+
+#### Étape 1.1 : Créer un inventaire des VM sources
+
+Répertoriez toutes les machines virtuelles à migrer avec les informations suivantes :
+
+- FQDN et adresse IP statique.
+- Système d’exploitation et sa version.
+- Application ou service associé à chaque VM.
+- Dépendances entre les VM (par exemple : web/app/db).
+
+Cet inventaire vous permet de regrouper les machines virtuelles en piles d'applications cohérentes pour la migration par lots.
+
+#### Étape 1.2 : Regrouper les VM en lots de migration
+
+Organisez vos VM en lots applicatifs cohérents.
+
+Chaque lot doit contenir toutes les machines virtuelles nécessaires à la migration et à l’exploitation d’une seule application, comme :
+
+- VM frontend web.
+- VM applicative.
+- VM backend de base de données.
+
+#### Étape 1.3 : Documenter la configuration réseau existante
+
+Notez la configuration réseau complète utilisée par vos VM sources :
+
+- Les VLAN utilisés et les sous-réseaux associés.
+- Les plages d'adresses IP à conserver.
+- Les flux autorisés (IP source/destination, ports, protocoles).
+
+Cette structure réseau sera répliquée dans votre Hosted Private Cloud à l'aide de `vRack` et de NSX-T.
+
+Retrouvez plus d'informations sur la planification du réseau dans notre guide « [Premiers pas avec NSX](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps) ».
+
+Pour obtenir des conseils supplémentaires sur l'utilisation de Zerto, référez-vous à la documentation suivante : [Installer la solution Zerto](https://help.zerto.com/bundle/Install.HV.HTML/page/Installing_the_Zerto_Solution.htm){.external}.
+
+### Étape 2 : Planifier les ressources de votre Hosted Private Cloud
+
+Cette étape vous aide à déterminer les ressources de calcul, de stockage et de réseau requises pour votre environnement HPC.
+
+#### Étape 2.1 : Estimer le CPU et la mémoire
+
+Examinez votre infrastructure actuelle pour calculer la quantité de vCPU et de RAM nécessaires dans l'environnement cible.
+
+Utilisez votre ratio de consolidation pCPU/vCPU existant pour dimensionner le nombre de `ESXi hosts` requis.
+
+#### Étape 2.2 : Définir la capacité de stockage
+
+En fonction de vos charges de travail, sélectionnez le type de stockage le plus approprié :
+
+- `Datastores NFS` pour les charges de travail générales.
+- `vSAN` pour les applications exigeantes en performances.
+
+Estimez l'espace disque total nécessaire, plus la redondance le cas échéant.  
+Si vos charges de travail nécessitent des IOPS élevées, vSAN est l'option privilégiée.
+
+#### Étape 2.3 : Planifier le réseau cible
+
+Planifiez la recréation de votre réseau virtuel à l'aide de NSX-T :
+
+- Décidez quels segments seront de type VLAN ou Overlay.
+- Identifiez les besoins en matière de passerelles (Tier-0 et Tier-1).
+- Évaluez les règles de pare-feu et le trafic nord-sud.
+
+Si vous devez exposer des services sur Internet, vous pouvez :
+
+- Demander des adresses IP publiques via votre `Hosted Private Cloud`.
+- Migrer vos plages d'adresses IP existantes grâce à la fonctionnalité [Bring Your Own IP (BYOIP)](/links/network/byoip).
+
+### Étape 3 : Activer l'accès au vCenter
+
+L'accès au vCenter est restreint par défaut dans tous les environnements HPC OVHcloud.
+
+Vous devez explicitement autoriser vos adresses IP d'administration à atteindre le point de terminaison `vCenter`.
+
+Pour ce faire :
+
+1. Connectez-vous à votre [espace client OVHcloud](/links/manager).
+2. Sélectionnez votre `Hosted Private Cloud`{.action}.
+3. Accédez à l'onglet `Sécurité`{.action}
+4. Cliquez sur `Ajouter une nouvelle plage d'adresses IP`{.action} pour autoriser vos adresses IP d'infrastructure source et vos composants Zerto.
+
+Pour des instructions détaillées, référez-vous à notre guide « [Autoriser des IP à se connecter au vCenter](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/autoriser_des_ip_a_se_connecter_au_vcenter) ».
+
+### Étape 4 : Configurer les rôles et les permissions
+
+Cette étape garantit que les administrateurs et les outils comme Zerto ont un accès correct aux ressources vSphere au sein de votre Hosted Private Cloud OVHcloud.
+
+#### Étape 4.1 : Utiliser la solution IAM (Identity and Access Management) d’OVHcloud
+
+Configurez les rôles et permissions dans votre `Hosted Private Cloud`{.action} via la solution **IAM** d'OVHcloud.
+
+> [!warning]
+> **La solution IAM d'OVHcloud n’est pas disponible dans les environnements qualifiés SecNumCloud (SNC), PCI-DSS ou HDS.**
+> Si vous utilisez l'un de ces environnements qualifiés, vous devez configurer les rôles et les autorisations directement dans vSphere ou utiliser une solution IAM externe telle que Microsoft Active Directory ou Okta.
+
+Pour des instructions détaillées, référez-vous au [guide de configuration IAM](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_iam_getting_started).
+
+#### Étape 4.2 : Connecter votre propre solution IAM
+
+Si vous préférez utiliser votre fournisseur d'identité existant (comme Active Directory ou Okta), déployez un service d'annuaire directement dans votre tenant OVHcloud.
+
+Vous pouvez également associer la solution IAM d’OVHcloud à votre serveur ADFS existant pour activer l’authentification unique basée sur SAML.
+
+Pour cela, suivez notre guide « [Activer les connexions Active Directory Federation Services (AD FS) SSO avec votre compte OVHcloud](/pages/account_and_service_management/account_information/ovhcloud-account-connect-saml-adfs) ».
+
+#### Étape 4.3 : Comptes de service Zerto
+
+Les composants Zerto nécessitent des rôles et des autorisations vSphere spécifiques pour fonctionner. Vous pouvez :
+
+- Créer un compte dédié `zerto-admin` dans vSphere.
+- Attribuer les privilèges nécessaires pour gérer la réplication et la restauration.
+
+Les détails sur les autorisations requises sont disponibles dans la documentation de Zerto : [Rôles et autorisations dans Zerto](https://help.zerto.com/bundle/Admin.VC.HTML.90/page/Roles_and_Permissions_Within_.htm){.external}.
+
+### Étape 5 : Construire le réseau cible
+
+Avant de commencer tout test de réplication ou de failover de VM, votre réseau Hosted Private Cloud doit être prêt à recevoir les charges de travail.
+
+Cela inclut notamment la réplication de la structure source, la création des segments de réseau appropriés et la configuration des règles de pare-feu nécessaires.
+
+#### Étape 5.1 : Recréer vos VLAN et segments
+
+Lors de la livraison de votre HPC, celui-ci est configuré par défaut avec un commutateur virtuel distribué et au moins un VLAN. Vous pouvez ajouter vos propres VLAN via le `vRack`.
+
+Si vous utilisez NSX-T, planifiez votre segmentation comme suit :
+
+- Définissez vos segments (VLAN-backed ou overlay).
+- Affectez chaque application à un lot d'applications ou à une zone de service correspondante.
+- Reproduisez les plans d’adressage IP définis dans votre inventaire
+
+Référez-vous à notre guide « [Premiers pas avec NSX](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps) » pour obtenir plus de détails sur la création de segments et leur affectation aux machines virtuelles.
+
+#### Étape 5.2 : Configurer le routage et les passerelles NSX-T
+
+Si vous utilisez NSX-T, vous devez définir comment le trafic sera routé entre les segments et vers Internet :
+
+- Une **Gateway Tier-1** gère le routage interne.
+- Une **Gateway Tier-0** relie votre environnement à des services en amont ou à des réseaux externes.
+
+Ces passerelles sont automatiquement déployées lorsque NSX-T est activé. Vous pouvez les consulter et les modifier depuis l'interface `NSX Manager`.
+
+Paramétrez des routages et des services basés sur votre matrice de flux définie à l'étape 1.
+
+#### Étape 5.3 : Préparation des règles de firewall
+
+NSX-T fournit un **pare-feu distribué** qui contrôle le trafic est-ouest entre les machines virtuelles. Vous devez définir des règles pour :
+
+- Les ports spécifiques des applications (par exemple : web → app, app → db).
+- L'accès à la gestion des composants vCenter et Zerto.
+- Facultatif : Les zones de quarantaine ou d'isolement pour les VM de test.
+
+Si vous n'utilisez pas NSX-T, mettez en œuvre des règles similaires à l'aide du pare-feu de l'appliance virtuelle de votre choix (par exemple : FortiVM, Stormshield ou Palo Alto VM-Series).
+
+Vous retrouverez un aperçu de la façon dont NSX gère ces fonctionnalités dans notre guide « [Premiers pas avec NSX](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps) ».
+
+### Étape 6 : Déployer les services core dans le HPC cible
+
+Vos charges de travail migrées nécessiteront des services d'infrastructure de base pour fonctionner correctement lorsqu'elles seront en cours d'exécution dans votre Hosted Private Cloud.
+
+#### Étape 6.1 : Déployer NTP
+
+Assurez-vous que toutes les machines virtuelles et tous les services utilisent une source de temps cohérente. Vous pouvez configurer vos charges de travail HPC pour utiliser `ntp.ovh.net` comme serveur de temps fiable.
+
+#### Étape 6.2 : Déployer DNS
+
+Si vos applications s'appuient sur une résolution DNS interne, déployez un contrôleur de domaine ou un serveur DNS dédié au sein de votre environnement HPC. Il peut s’agir d’un clone de votre serveur on-premises ou d’une nouvelle instance.
+
+#### Étape 6.3 : Mise en place des services d'authentification
+
+Si votre authentification est basée sur Active Directory, déployez un contrôleur de domaine réplica dans le HPC.
+
+Vous pouvez également établir une communication sécurisée entre l'AD on-premises et le client pour éviter la duplication des identités.
+
+### Étape 7 : Installer et activer Zerto sur le locataire OVHcloud
+
+Zerto est installé et géré par site. Côté OVHcloud, les composants sont déployés automatiquement lors de l’activation de Zerto.
+
+Dans votre interface `Hosted Private Cloud`{.action} :
+
+1. Accédez à `Reprise d'activité`{.action}.
+2. Sélectionnez `Activer la réplication virtuelle Zerto`{.action}.
+3. Confirmez et attendez le déploiement.
+
+OVHcloud déploiera les éléments suivants :
+
+- Un ZVM (Zerto Virtual Manager) dédié.
+- Un ZVRA (Zerto Virtual Replication Appliance) sur chaque hôte ESXi.
+- Un firewall NSX-T géré par OVHcloud avec des règles préconfigurées pour les ports Zerto.
+
+Tous les détails sont disponibles dans notre guide « [Utiliser Zerto entre OVHcloud et une plateforme tierce](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/zerto-virtual-replication-customer-to-ovhcloud) ».
+
+### Étape 8 : Installer Zerto sur le site source
+
+Vous devez installer manuellement les composants Zerto sur votre infrastructure on-premises.
+
+Suivez la procédure décrite dans le guide Zerto suivant : [Réaliser une installation rapide](https://help.zerto.com/bundle/Install.VC.HTML/page/Performing_an_Express_Installation.htm){.external}.
+
+Les principaux composants sont les suivants :
+
+- ZVM : Installé sur un serveur Windows avec accès vSphere.
+- ZVRA : Déployé sur chaque hôte ESXi hébergeant des VM protégées.
+
+Assurez-vous que :
+
+- Les ports TCP 9071 et 9081 sont ouverts entre les ZVM.
+- Les ports TCP 4007 et 4008 sont ouverts entre les ZVRA.
+
+### Étape 9 : Configurer le tunnel VPN IPsec
+
+Zerto nécessite **une communication directe** entre les ZVM et les ZVRA. Le NAT n'est pas pris en charge.
+
+Mettez en place un tunnel IPsec site-à-site entre votre pare-feu local et l'environnement OVHcloud.
+
+Vous pouvez utiliser n'importe quel périphérique compatible (par exemple : Fortinet, Palo Alto ou OPNsense).
+
+Les détails et les paramètres sont disponibles dans notre guide « [Utiliser Zerto entre OVHcloud et une plateforme tierce](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/zerto-virtual-replication-customer-to-ovhcloud) ».
+
+### Étape 10 : Coupler les sites et créer des VPG
+
+Une fois les ZVM en ligne et la communication validée :
+
+1. Utilisez la console Zerto pour **coupler les deux sites**.
+2. Créez votre premier **Virtual Protection Group (VPG)**.
+
+Un VPG regroupe toutes les VM qui doivent être répliquées et basculées ensemble.
+
+Retrouvez plus d'informations dans le guide Zerto suivant : [Créer un VPG](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Creating_a_VPG.htm){.external}.
+
+### Étape 11 : Surveiller l'état de la réplication
+
+Surveillez chaque VPG depuis l'interface utilisateur Zerto :
+
+- Confirmez que la réplication est active.
+- Vérifiez le RPO (Recovery Point Objective).
+- Résolvez les alertes avant d'exécuter un test ou un failover.
+
+Si besoin, consultez le guide Zerto suivant : [Surveillance des groupes de protection virtuels](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Monitoring_Virtual_Protection_Groups.htm){.external}.
+
+### Étape 12 : Exécuter un test de failover
+
+Avant de migrer les charges de travail de production, testez le comportement de vos VM dans le tenant OVHcloud.
+
+Utilisez l'option `Failover Test` dans l'interface utilisateur Zerto. Cela permet de mettre sous tension les machines virtuelles répliquées sans impacter la production.
+
+Retrouvez ci-dessous les guides de Zerto à ce sujet :
+
+- [Démarrage et arrêt des tests de failover](https://help.zerto.com/bundle/Admin.VC.HTML.10.0_U3/page/StartingFailoverTest.htm){.external}
+- [Que se passe-t-il après avoir démarré un test ?](https://help.zerto.com/bundle/Admin.VC.HTML.10.0_U3/page/What_Happens_After_Starting_a_Test.htm){.external}
+
+### Étape 13 : Exécuter la migration prévue
+
+Lorsque vous êtes prêt à migrer :
+
+1. Utilisez l'opération **Move** dans Zerto pour migrer chaque VPG.
+2. Choisissez la stratégie de validation (manuelle, automatique, annulation).
+
+Pour obtenir des instructions complètes, référez-vous au guide Zerto suivant : [Processus de déplacement](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/The_Move_Process.htm){.external}.
+
+### Étape 14 : Valider la disponibilité de l'application
+
+Après le déplacement :
+
+- Vérifiez que toutes les VM sont sous tension.
+- Testez la connectivité (AD, DNS, Bastion, Internet).
+- Validez chaque application et service.
+
+### Étape 15 : Valider ou annuler la migration
+
+Si tous les tests réussissent, validez l'opération dans Zerto.
+
+Si quelque chose ne fonctionne pas, vous pouvez annuler le déplacement et revenir à votre environnement local.
+
+Voir le guide Zerto suivant : [Déplacement des machines virtuelles protégées vers le site distant](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Moving_Protected_Virtual_Machines_to_the_Remote_Site.htm){.external}.
+
+### Étape 16 : Utiliser Storage vMotion pour placer les VM sur le stockage cible
+
+Après la migration, vous pouvez souhaiter déplacer certaines machines virtuelles vers un autre datastore ou une autre stratégie vSAN.
+
+Utilisez `Storage vMotion`{.action} via `vSphere Client`{.action} :
+
+1. Faites un clic droit sur la VM puis cliquez sur `Migrer`{.action}.
+2. Sélectionnez `Modifier le stockage uniquement`{.action}.
+3. Choisissez le datastore de destination ou la stratégie vSAN.
+
+Pour plus de détails, consultez notre guide « [VMware Storage vMotion](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_storage_vmotion) ».
+
+### Étape 17 : Sauvegarder vos charges de travail
+
+Une fois vos VM en production, sécurisez-les avec un plan de sauvegarde.
+
+Vous disposez de 2 options :
+
+- **Option 1** : Utiliser **Veeam Backup as a Service** si vous souhaitez une solution de sauvegarde managée intégrée à votre HPC.
+- **Option 2** : Déployer votre propre serveur Veeam Backup et utiliser **Veeam Backup & Replication for Public Cloud**.
+
+## Aller plus loin
+
+Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en œuvre de nos solutions, contactez votre Technical Account Manager ou demandez une analyse personnalisée de votre projet à nos experts de l’équipe [Professional Services](/links/professional-services).
+
+Posez des questions, donnez votre avis et interagissez directement avec l’équipe qui construit nos services Hosted Private Cloud sur le canal [Discord](https://discord.gg/ovhcloud){.external} dédié.
+
+Échangez avec notre [communauté d'utilisateurs](/links/community).
\ No newline at end of file
diff --git a/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/meta.yaml b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/meta.yaml
new file mode 100644
index 00000000000..5024ad399a8
--- /dev/null
+++ b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto/meta.yaml
@@ -0,0 +1,2 @@
+id: 610f87c4-b499-426c-aabe-c93016425f31
+full_slug: vmware-migration-zerto
\ No newline at end of file
diff --git a/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/guide.en-gb.md b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/guide.en-gb.md
new file mode 100644
index 00000000000..665af78d6f4
--- /dev/null
+++ b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/guide.en-gb.md
@@ -0,0 +1,313 @@
+---
+title: Move2Cloud - Migrate VMware workloads to OVHcloud SecNumCloud Hosted Private Cloud with Zerto
+excerpt: "Learn how to migrate on-premises VMware workloads to a SecNumCloud-qualified Hosted Private Cloud using Zerto Virtual Replication"
+updated: 2025-07-17
+---
+
+## Objective
+
+This guide explains how to migrate your on-premises VMware workloads to an **OVHcloud SecNumCloud Hosted Private Cloud (HPC)** using **Zerto Virtual Replication**.
+
+> [!primary]
+> **This guide applies to SecNumCloud (SNC) qualified Hosted Private Cloud environments.**
+> Some features available in standard environments like **OVHcloud IAM**, **vRack** or the **advanced NSX-T network** may be restricted or unavailable here.
+> For standard environments, refer to the dedicated guide:
+> [Move2Cloud - Migrate VMware workloads to OVHcloud Hosted Private Cloud with Zerto](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto).
+
+## Requirements
+
+Before you begin, make sure you have:
+
+- A complete inventory of your VMs, including FQDN, IP address, OS version, and application dependencies.
+- A batch migration plan grouped by application stack.
+- A full list of VLANs, subnets, and segments for your target network.
+- An HPC environment properly sized (hosts, datastores, vSAN, NSX-T).
+- A working IPsec VPN tunnel between your on-premises infrastructure and OVHcloud.
+- Access to the Zerto console and vCenter interfaces on both sides.
+
+>[!warning]
+> As of May 2025, **Zerto does not support replication of virtual machines with VMEncrypt enabled**.  
+> vSAN’s encryption at rest is supported. You can also encrypt your VMs after migration is complete.
+
+## Instructions
+
+![Move2CloudZerto](/pages/assets/screens/other/zerto/move2cloud-zerto.png){.thumbnail}
+
+### Step 1: Define your migration scope
+
+At the end of this step, you will have a structured list of workloads to migrate and the associated network design.
+
+#### Step 1.1: Create an inventory of source VMs
+
+List all virtual machines to be migrated and collect the following data:
+
+- FQDN and static IP address
+- Operating system and version
+- Application or service associated with each VM
+- Technical dependencies (for example, frontend servers depending on a database VM)
+
+This inventory allows you to group VMs into consistent application stacks for batch migration.
+
+#### Step 1.2: Group VMs into migration batches
+
+Organize your VMs into logical groups according to application-level dependencies.  
+Each batch should contain all virtual machines required to migrate and operate a single application, such as:
+
+- Web frontend VM
+- Application logic VM
+- Database backend VM
+
+#### Step 1.3: Document the current network configuration
+
+Record the full network configuration used by your source VMs:
+
+- VLAN IDs and associated subnets
+- IP address ranges to preserve
+- Inter-VM communication flows (source/destination, port, protocol)
+
+This network design will be recreated in your OVHcloud HPC tenant using NSX-T overlay segments.
+
+You can find more about network planning in [NSX-T - First steps](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps).
+
+For additional guidance from Zerto, refer to [Installing the Zerto Solution](https://help.zerto.com/bundle/Install.HV.HTML/page/Installing_the_Zerto_Solution.htm){.external}.
+
+### Step 2: Plan Hosted Private Cloud resources
+
+This step helps you determine the required compute, storage, and network resources for your HPC environment.
+
+#### Step 2.1: Estimate CPU and memory
+
+Review your current infrastructure to calculate how many vCPUs and how much RAM you will need in the target environment.
+
+Use your existing pCPU/vCPU consolidation ratio to size the number of `ESXi hosts` required.
+
+#### Step 2.2: Define storage capacity
+
+Based on your workloads, select the most appropriate storage type:
+
+- `NFS datastores` for general-purpose workloads
+- `vSAN` for performance-intensive applications
+
+Estimate total disk space needed, plus redundancy if applicable.  
+If your workloads require high IOPS, vSAN is the preferred option.
+
+#### Step 2.3: Plan the target network
+
+Plan your virtual network using NSX-T:
+
+- Only **overlay segments** are supported; VLAN-backed segments are not allowed.
+- Define Tier-0 and Tier-1 gateway needs based on internal routing.
+- Configure firewall rules for east-west traffic.
+
+No direct internet exposure is permitted. All access must go through approved bastion or VPN links.
+
+> [!primary]
+> The [Bring Your Own IP (BYOIP)](/links/network/byoip) feature is not available in SecNumCloud environments.
+
+### Step 3: Enable access to the vCenter
+
+Access to `vCenter`{.action} is restricted by default in SecNumCloud environments.
+
+You must request access from OVHcloud Support.
+
+1. Open a support ticket from the [OVHcloud Control Panel](/links/manager).
+2. Select your `Hosted Private Cloud`{.action}.
+3. Provide the list of source IPs that require access.
+
+For step-by-step instructions, refer to [Authorize IPs to connect to vCenter](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/autoriser_des_ip_a_se_connecter_au_vcenter).
+
+### Step 4: Configure roles and permissions
+
+As IAM is not available in SecNumCloud environments, you must configure roles and permissions for your VMware environment using **local accounts** within the OVHcloud SecNumCloud tenant.
+
+> [!primary]
+> All accounts in a SecNumCloud environment must be secured with **two-factor authentication (2FA)**.
+
+For detailed instructions on how to enroll local accounts with 2FA, refer to the official guide:
+[Enabling secure access to the vSphere interface](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/interface-secure)
+
+### Step 5: Build the target network
+
+Before starting any VM replication or failover test, your Hosted Private Cloud network must be ready to receive the workloads. This includes replicating the source structure, creating the right segments, and preparing firewall rules.
+
+#### Step 5.1: Recreate your segments
+
+In SecNumCloud environments, VLAN-backed segments and vRack are not available.
+
+When your HPC is delivered, it comes with a default distributed virtual switch. You must use NSX-T overlay segments only.
+
+Use `NSX Manager` to:
+
+- Create overlay segments for each application batch or service zone.
+- Reproduce the IP addressing plan from your inventory.
+- Attach segments to the relevant gateways (usually Tier-1).
+
+Do not expose any segment to the internet. Access must be routed through bastions or private VPN links.
+
+#### Step 5.2: Configure NSX-T routing and gateways
+
+In SNC environments, NSX-T gateways are used only for internal routing or secure VPN-based flows.
+
+- A **Tier-1 Gateway** handles internal routing between overlay segments.
+- **Tier-0 Gateways** may be deployed but only for approved VPN uplinks.
+
+Use the `NSX Manager` interface to define and manage your gateway configuration.
+
+No external/public IP connectivity is allowed.
+
+#### Step 5.3: Prepare firewall rules
+
+NSX-T provides a **distributed firewall (DFW)** that controls east-west traffic between VMs. You should define rules for:
+
+- Application-specific ports (e.g., web → app, app → db)
+- Management access to vCenter and Zerto components
+- Optional: quarantine or isolation zones for test VMs
+
+If you are not using NSX-T, implement similar rules using your preferred virtual firewall appliance (e.g., FortiVM, Stormshield, Palo Alto VM-Series).
+
+You can find an overview of how NSX handles these features in [NSX-T – First steps](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps).
+
+> [!primary]
+> 
+> In SecNumCloud, firewall rules must strictly restrict traffic to internal flows or secured VPN entry points. No DNAT/SNAT rules toward the public internet are allowed.
+>
+
+### Step 6: Deploy core services in the target HPC
+
+Your migrated workloads will need basic infrastructure services to function properly once they are running in your Hosted Private Cloud.
+
+#### Step 6.1: Deploy NTP
+
+Ensure all VMs and services use a consistent time source. You can configure your HPC workloads to use `ntp.ovh.net` as a reliable time server.
+
+#### Step 6.2: Deploy DNS
+
+If your applications rely on internal DNS resolution, deploy a domain controller or dedicated DNS server inside your HPC environment. This can be a clone of your on-prem server or a new instance.
+
+#### Step 6.3: Set up authentication services
+
+If your authentication is based on Active Directory, deploy a replica domain controller in the HPC.
+
+You can also establish secure communication between the on-prem AD and the tenant to avoid duplicating identities.
+
+### Step 7: Install and activate Zerto in the OVHcloud tenant
+
+Zerto must be installed by OVHcloud in SecNumCloud environments.
+
+1. In the `Hosted Private Cloud`{.action} interface, open a support ticket.
+2. Request Zerto Virtual Replication for your SNC tenant.
+3. Wait for OVHcloud to deploy the ZVM, ZVRAs, and required firewall rules.
+
+Full details: [Zerto Virtual Replication on OVHcloud](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_zerto_virtual_replication_customer_to_ovh)
+
+### Step 8: Install Zerto on the source site
+
+You must install Zerto components manually on your on-premises infrastructure.
+
+Follow the procedure in [Installing Zerto on source site](https://help.zerto.com/bundle/Install.VC.HTML/page/Performing_an_Express_Installation.htm){.external}.
+
+The main components are:
+
+- ZVM: Installed on a Windows Server with vSphere access
+- ZVRAs: Deployed on each ESXi host hosting protected VMs
+
+Ensure that:
+
+- TCP ports 9071, 9081 are open between ZVMs.
+- TCP ports 4007, 4008 are open between ZVRAs.
+
+### Step 9: Set up the IPsec VPN tunnel
+
+Zerto requires **direct communication** between ZVMs and ZVRAs. NAT is not supported.
+
+Set up a site-to-site IPsec tunnel between your on-prem firewall and the OVHcloud tenant.
+
+You can use any compatible device (e.g., Fortinet, Palo Alto, OPNsense).
+
+Details and parameters are available in [Zerto VPN Setup on OVHcloud](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_zerto_virtual_replication_customer_to_ovh).
+
+### Step 10: Pair the sites and create VPGs
+
+Once ZVMs are online and communication is confirmed:
+
+1. Use the Zerto console to **pair both sites**.
+2. Create your first **Virtual Protection Group (VPG)**.
+
+A VPG groups all VMs that should be replicated and failed over together.
+
+More information in [Creating a VPG](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Creating_a_VPG.htm){.external}
+
+### Step 11: Monitor the replication status
+
+Monitor each VPG from the Zerto UI:
+
+- Confirm that replication is active.
+- Check the RPO (Recovery Point Objective).
+- Resolve any alerts before running a test or failover.
+
+Refer to [Monitoring Virtual Protection Groups](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Monitoring_Virtual_Protection_Groups.htm){.external}
+
+### Step 12: Run a test failover
+
+Before migrating production workloads, test the behavior of your VMs in the OVHcloud tenant.
+
+Use the `Failover Test` option in the Zerto UI. This powers on the replicated VMs without impacting production.
+
+Instructions:
+
+- [Start a test failover](https://help.zerto.com/bundle/Admin.VC.HTML.10.0_U3/page/StartingFailoverTest.htm){.external}
+- [Stop a test failover](https://help.zerto.com/bundle/Admin.VC.HTML.10.0_U3/page/What_Happens_After_Starting_a_Test.htm){.external}
+
+### Step 13: Execute the planned migration
+
+When you are ready to migrate:
+
+1. Use the **Move** operation in Zerto to migrate each VPG.
+2. Choose the commit policy (manual, auto, rollback).
+
+See [The Move Process](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/The_Move_Process.htm){.external} for full instructions.
+
+### Step 14: Validate application availability
+
+After the move:
+
+- Verify that all VMs are powered on.
+- Test connectivity (AD, DNS, Bastion, internet).
+- Validate each application and service.
+
+### Step 15: Commit or roll back the migration
+
+If all tests succeed, commit the operation in Zerto.
+
+If something is not working, you can cancel the move and roll back to your on-prem environment.
+
+More in [Moving Protected VMs to Remote Site](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Moving_Protected_Virtual_Machines_to_the_Remote_Site.htm){.external}
+
+### Step 16: Use Storage vMotion to place VMs on target storage
+
+After migration, you may want to move some VMs to another datastore or vSAN policy.
+
+Use `Storage vMotion`{.action} via the `vSphere Client`{.action}:
+
+1. Right-click on the VM > `Migrate`{.action}.
+2. Select `Change storage only`{.action}.
+3. Choose the destination datastore or vSAN policy.
+
+See [VMware Storage vMotion](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_storage_vmotion) for full details.
+
+### Step 17: Back up your workloads
+
+Once your VMs are in production, secure them with a backup plan.
+
+You have 2 options:
+
+- **Option 1**: Use **Veeam Backup as a Service** if you want a managed backup solution integrated with your HPC.
+- **Option 2**: Deploy your own Veeam Backup server and use **Veeam Backup & Replication for Public Cloud**.
+
+## Go further
+
+If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for a custom analysis of your project.
+
+Ask questions, give your feedback and interact directly with the team building our Hosted Private Cloud services on the dedicated [Discord](https://discord.gg/ovhcloud) channel.
+
+Join our [community of users](/links/community).
\ No newline at end of file
diff --git a/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/guide.fr-fr.md b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/guide.fr-fr.md
new file mode 100644
index 00000000000..a4f6055e497
--- /dev/null
+++ b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/guide.fr-fr.md
@@ -0,0 +1,338 @@
+---
+title: Move2Cloud - Migration de charges de travail VMware vers OVHcloud Hosted Private Cloud SecNumCloud avec Zerto
+excerpt: "Découvrez comment migrer des charges VMware on-premises vers un Hosted Private Cloud qualifié SecNumCloud à l’aide de Zerto Virtual Replication"
+updated: 2025-07-17
+---
+
+## Objectif
+
+Ce guide explique comment migrer vos charges de travail VMware on-premises vers un **Hosted Private Cloud (HPC) SecNumCloud OVHcloud** en utilisant **Zerto Virtual Replication**.
+
+> [!primary]
+> **Ce guide s’applique aux environnements Hosted Private Cloud qualifiés SecNumCloud (SNC).**
+> Certaines fonctionnalités disponibles dans les environnements standards comme **OVHcloud IAM**, le **vRack** ou le **réseau NSX-T avancé** peuvent être restreintes ou indisponibles ici.
+> Pour les environnements standards, consultez le guide suivant :
+> [Move2Cloud - Migration de charges de travail VMware vers le Hosted Private Cloud OVHcloud avec Zerto](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto)
+
+## Prérequis
+
+Avant de commencer, assurez-vous de détenir :
+
+- Un inventaire complet de vos machines virtuelles (VM) : FQDN, adresse IP, version du système d'exploitation, dépendances applicatives.
+- Un plan de migration par lots regroupés par pile applicative.
+- Une liste complète des VLAN, sous-réseaux et segments du réseau cible.
+- Un environnement HPC correctement dimensionné (hosts, datastores, vSAN, NSX-T).
+- Un tunnel VPN IPsec fonctionnel entre votre infrastructure sur site et OVHcloud.
+- Un accès à la console Zerto et aux interfaces vCenter sur les deux environnements.
+
+> [!warning]
+> Depuis mai 2025, **Zerto ne prend pas en charge la réplication des VM avec le chiffrement VMEncrypt activé**.
+> Le chiffrement au repos de vSAN est pris en charge. Vous pouvez également chiffrer vos VM après la migration.
+
+## En pratique
+
+![Move2CloudZerto](/pages/assets/screens/other/zerto/move2cloud-zerto.png){.thumbnail}
+
+### Étape 1 : Définir votre périmètre de migration
+
+À la fin de cette étape, vous détiendrez une liste structurée des charges de travail à migrer et la conception du réseau associée.
+
+#### Étape 1.1 : Créer un inventaire des VM sources
+
+Répertoriez toutes les machines virtuelles à migrer avec les informations suivantes :
+
+- FQDN et adresse IP statique.
+- Système d’exploitation et sa version.
+- Application ou service associé.
+- Dépendances entre les VM (par exemple : web/app/db).
+
+Cet inventaire vous permet de regrouper les machines virtuelles en piles d'applications cohérentes pour la migration par lots.
+
+#### Étape 1.2 : Regrouper les VM en lots de migration
+
+Organisez vos VMs en lots applicatifs cohérents.
+
+Chaque lot doit contenir toutes les machines virtuelles nécessaires à la migration et à l’exploitation d’une seule application, comme :
+
+- VM frontend web.
+- VM applicative.
+- VM backend de base de données.
+
+#### Étape 1.3 : Documenter la configuration réseau existante
+
+Notez la configuration réseau complète utilisée par vos VM sources :
+
+- Les VLAN utilisés et les sous-réseaux associés.
+- Les plages d'adresses IP à conserver.
+- Les flux autorisés (IP source/destination, ports, protocoles).
+
+Cette conception réseau sera recréée dans votre tenant HPC OVHcloud à l'aide de segments de superposition NSX-T.
+
+Retrouvez plus d'informations sur la planification du réseau dans notre guide « [Premiers pas avec NSX](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps) ».
+
+Pour obtenir des conseils supplémentaires sur l'utilisation de Zerto, référez-vous à la documentation suivante : [Installer la solution Zerto](https://help.zerto.com/bundle/Install.HV.HTML/page/Installing_the_Zerto_Solution.htm){.external}.
+
+### Étape 2 : Planifier les ressources de votre Hosted Private Cloud
+
+Cette étape vous aide à déterminer les ressources de calcul, de stockage et de réseau requises pour votre environnement HPC.
+
+#### Étape 2.1 : Estimer le CPU et la mémoire
+
+Examinez votre infrastructure actuelle pour calculer combien de vCPU et de RAM vous aurez besoin dans l'environnement cible.
+
+Utilisez votre ratio de consolidation pCPU/vCPU existant pour dimensionner le nombre de `ESXi hosts` requis.
+
+#### Étape 2.2 : Définir la capacité de stockage
+
+En fonction de vos charges de travail, sélectionnez le type de stockage le plus approprié :
+
+- `Datastores NFS` pour les charges de travail générales.
+- `vSAN` pour les applications exigeantes en performances.
+
+Estimez l'espace disque total nécessaire, plus la redondance le cas échéant.  
+Si vos charges de travail nécessitent des IOPS élevées, vSAN est l'option privilégiée.
+
+#### Étape 2.3 : Planifier le réseau cible
+
+Planifiez votre réseau virtuel avec NSX-T :
+
+- Seuls **les segments de superposition** sont pris en charge; les segments adossés à des VLAN ne sont pas autorisés.
+- Définissez les besoins en matière de passerelles (Tier-0 et Tier-1) en fonction du routage interne.
+- Configurez les règles de pare-feu pour le trafic est-ouest.
+
+Aucune exposition directe à Internet n'est autorisée. Tous les accès doivent passer par des bastions ou des liens VPN approuvés.
+
+> [!primary]
+> La fonctionnalité [Bring Your Own IP (BYOIP)](/links/network/byoip) n'est pas disponible dans les environnements SecNumCloud.
+
+### Étape 3 : Activer l'accès au vCenter
+
+L'accès à `vCenter`{.action} est restreint par défaut dans les environnements SecNumCloud.
+
+Vous devez demander l'accès au support OVHcloud.
+
+1. Créez un ticket depuis votre [espace client OVHcloud](/links/manager).
+2. Sélectionnez votre `Hosted Private Cloud`{.action}.
+3. Fournissez la liste des IP sources qui nécessitent un accès.
+
+Pour des instructions détaillées, référez-vous à notre guide « [Autoriser des IP à se connecter au vCenter](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/autoriser_des_ip_a_se_connecter_au_vcenter) ».
+
+### Étape 4 : Configurer les rôles et les permissions
+
+Cette étape garantit que les administrateurs et les outils comme Zerto ont un accès correct aux ressources vSphere au sein de votre Hosted Private Cloud OVHcloud.
+
+#### Étape 4.1 : Utiliser la solution IAM (Identity and Access Management) d’OVHcloud
+
+Configurez les rôles et permissions dans votre `Hosted Private Cloud`{.action} via la solution **IAM d'OVHcloud**.
+
+> [!warning]
+> **La solution IAM d'OVHcloud n’est pas disponible dans les environnements qualifiés SecNumCloud (SNC), PCI-DSS ou HDS.**
+> Si vous utilisez l'un de ces environnements qualifiés, vous devez configurer les rôles et les autorisations directement dans vSphere ou utiliser une solution IAM externe telle que Microsoft Active Directory ou Okta.
+
+Pour des instructions détaillées, référez-vous au [guide de configuration IAM](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_iam_getting_started).
+
+#### Étape 4.2 : Connecter votre propre solution IAM
+
+Si vous préférez utiliser votre fournisseur d'identité existant (comme Active Directory ou Okta), déployez un service d'annuaire directement dans votre tenant OVHcloud.
+
+Vous pouvez également associer la solution IAM d’OVHcloud à votre serveur ADFS existant pour activer l’authentification unique basée sur SAML.
+
+Pour cela, suivez notre guide « [Activer les connexions Active Directory Federation Services (AD FS) SSO avec votre compte OVHcloud](/pages/account_and_service_management/account_information/ovhcloud-account-connect-saml-adfs) ».
+
+#### Étape 4.3 : Comptes de service Zerto
+
+Les composants Zerto nécessitent des rôles et des autorisations vSphere spécifiques pour fonctionner. Vous pouvez :
+
+- Créer un compte dédié `zerto-admin` dans vSphere.
+- Attribuer les privilèges nécessaires pour gérer la réplication et la restauration.
+
+Les détails sur les autorisations requises sont disponibles dans la documentation de Zerto : [Rôles et autorisations dans Zerto](https://help.zerto.com/bundle/Admin.VC.HTML.90/page/Roles_and_Permissions_Within_.htm){.external}.
+
+### Étape 5 : Construire le réseau cible
+
+Avant de commencer tout test de réplication ou de failover de VM, votre réseau Hosted Private Cloud doit être prêt à recevoir les charges de travail. 
+
+Cela inclut notamment la réplication de la structure source, la création des segments de réseau appropriés et la configuration des règles de pare-feu nécessaires.
+
+#### Étape 5.1 : Recréer vos segments
+
+Dans les environnements SecNumCloud, les segments sauvegardés par VLAN et le vRack ne sont pas disponibles.
+
+Lors de la livraison de votre HPC, celui-ci est configuré par défaut avec un commutateur virtuel distribué. Vous devez utiliser uniquement des segments de superposition NSX-T.
+
+Utilisez `NSX Manager` pour :
+
+- Créer des segments de superposition pour chaque lot d'applications ou zone de service.
+- Reproduire le plan d'adressage IP depuis votre inventaire.
+- Attacher des segments aux passerelles concernées (généralement Tier-1).
+
+N'exposez aucun segment à Internet. L'accès doit être routé par des bastions ou des liens VPN privés.
+
+#### Étape 5.2 : Configurer le routage et les passerelles NSX-T
+
+Dans les environnements SNC, les passerelles NSX-T sont utilisées uniquement pour le routage interne ou les flux VPN sécurisés.
+
+- Une **Gateway Tier-1** gère le routage interne entre les segments de superposition.
+- Les **Gateways Tier-0** peuvent être déployées, mais uniquement pour les liaisons VPN montantes approuvées.
+
+Utilisez l'interface `NSX Manager` pour définir et gérer la configuration de votre passerelle.
+
+Aucune connectivité IP externe/publique n'est autorisée.
+
+#### Étape 5.3 : COnfigurer les règles de firewall
+
+NSX-T fournit un **pare-feu distribué** qui contrôle le trafic est-ouest entre les machines virtuelles. Vous devez définir des règles pour :
+
+- Les ports spécifiques des applications (par exemple : web → app, app → db).
+- L'accès à la gestion des composants vCenter et Zerto.
+- Facultatif : Les zones de quarantaine ou d'isolement pour les VM de test.
+
+Si vous n'utilisez pas NSX-T, mettez en œuvre des règles similaires à l'aide du pare-feu de l'appliance virtuelle de votre choix (par exemple : FortiVM, Stormshield ou Palo Alto VM-Series).
+
+Vous retrouverez un aperçu de la façon dont NSX gère ces fonctionnalités dans notre guide : [Premiers pas avec NSX](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/nsx-01-first-steps).
+
+> [!primary]
+>
+> Dans un environnement SecNumCloud, les règles de pare-feu doivent strictement restreindre le trafic aux flux internes ou aux points d'entrée sécurisés du VPN. Aucune règle DNAT/SNAT vers l'Internet public n'est autorisée.
+>
+
+### Étape 6 : Déployer les services core dans le HPC cible
+
+Vos charges de travail migrées nécessiteront des services d'infrastructure de base pour fonctionner correctement lorsqu'elles seront en cours d'exécution dans votre Hosted Private Cloud.
+
+#### Étape 6.1 : Déployer NTP
+
+Assurez-vous que toutes les machines virtuelles et tous les services utilisent une source de temps cohérente. Vous pouvez configurer vos charges de travail HPC pour utiliser `ntp.ovh.net` comme serveur de temps fiable.
+
+#### Étape 6.2 : Déployer les DNS
+
+Si vos applications s'appuient sur une résolution DNS interne, déployez un contrôleur de domaine ou un serveur DNS dédié au sein de votre environnement HPC. Il peut s’agir d’un clone de votre serveur on-premises ou d’une nouvelle instance.
+
+### Étape 6.3 : Mise en place des services d'authentification
+
+Si votre authentification est basée sur Active Directory, déployez un contrôleur de domaine réplica dans le HPC.
+
+Vous pouvez également établir une communication sécurisée entre l'AD on-premises et le client pour éviter la duplication des identités.
+
+### Étape 7 : Installer et activer Zerto sur le tenant OVHcloud
+
+Zerto doit être installé par OVHcloud dans les environnements SecNumCloud.
+
+1. Créez un ticket depuis votre [espace client OVHcloud](/links/manager).
+2. Sélectionnez votre `Hosted Private Cloud`{.action}.
+3. Demandez l'installation de **Zerto Virtual Replication** pour votre client SNC.
+4. Patientez le temps du déploiement par OVHcloud des ZVM, des ZVRA et des règles de pare-feu requises.
+
+Tous les détails sont disponibles dans notre guide « [Utiliser Zerto entre OVHcloud et une plateforme tierce](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/zerto-virtual-replication-customer-to-ovhcloud) ».
+
+### Étape 8 : Installer Zerto sur le site source
+
+Vous devez installer manuellement les composants Zerto sur votre infrastructure on-premises.
+
+Suivez la procédure décrite dans le guide Zerto suivant : [Réaliser une installation rapide](https://help.zerto.com/bundle/Install.VC.HTML/page/Performing_an_Express_Installation.htm){.external}.
+
+Les principaux composants sont les suivants :
+
+- ZVM : Installé sur un serveur Windows avec accès vSphere.
+- ZVRA : Déployé sur chaque hôte ESXi hébergeant des VM protégées.
+
+Assurez-vous que :
+
+- Les ports TCP 9071 et 9081 sont ouverts entre les ZVM.
+- Les ports TCP 4007 et 4008 sont ouverts entre les ZVRA.
+
+### Étape 9 : Configurer le tunnel VPN IPsec
+
+Zerto nécessite **une communication directe** entre les ZVM et les ZVRA. Le NAT n'est pas pris en charge.
+
+Mettez en place un tunnel IPsec site-à-site entre votre pare-feu local et l'environnement OVHcloud.
+
+Vous pouvez utiliser n'importe quel périphérique compatible (par exemple : Fortinet, Palo Alto ou OPNsense).
+
+Les détails et les paramètres sont disponibles dans notre guide « [Utiliser Zerto entre OVHcloud et une plateforme tierce](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/zerto-virtual-replication-customer-to-ovhcloud) ».
+
+### Étape 10 : Coupler les sites et créer des VPG
+
+Une fois les ZVM en ligne et la communication validée :
+
+1. Utilisez la console Zerto pour **coupler les deux sites**.
+2. Créez votre premier **Virtual Protection Group (VPG)**.
+
+Un VPG regroupe toutes les VM qui doivent être répliquées et basculées ensemble.
+
+Retrouvez plus d'informations dans le guide Zerto suivant : [Créer un VPG](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Creating_a_VPG.htm){.external} .
+
+### Étape 11 : Surveiller l'état de la réplication
+
+Surveillez chaque VPG depuis l'interface utilisateur Zerto :
+
+- Confirmez que la réplication est active.
+- Vérifiez le RPO (Recovery Point Objective).
+- Résolvez les alertes avant d'exécuter un test ou un failover.
+
+Si besoin, consultez le guide Zerto suivant : [Surveillance des groupes de protection virtuels](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Monitoring_Virtual_Protection_Groups.htm){.external}.
+
+### Étape 12 : Exécuter un test de failover
+
+Avant de migrer les charges de travail de production, testez le comportement de vos VM dans le tenant OVHcloud.
+
+Utilisez l'option `Failover Test` dans l'interface utilisateur Zerto. Cela permet de mettre sous tension les machines virtuelles répliquées sans impacter la production.
+
+Retrouvez ci-dessous les guides de Zerto à ce sujet :
+
+- [Démarrage et arrêt des tests de failover](https://help.zerto.com/bundle/Admin.VC.HTML.10.0_U3/page/StartingFailoverTest.htm){.external}
+- [Que se passe-t-il après avoir démarré un test ?](https://help.zerto.com/bundle/Admin.VC.HTML.10.0_U3/page/What_Happens_After_Starting_a_Test.htm){.external}
+
+### Étape 13 : Exécuter la migration prévue
+
+Lorsque vous êtes prêt à migrer :
+
+1. Utilisez l'opération **Move** dans Zerto pour migrer chaque VPG.
+2. Choisissez la stratégie de validation (manuelle, automatique, annulation).
+
+Pour obtenir des instructions complètes, référez-vous au guide Zerto suivant : [Processus de déplacement](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/The_Move_Process.htm){.external}.
+
+### Étape 14 : Valider la disponibilité de l'application
+
+Après le déplacement :
+
+- Vérifiez que toutes les VM sont sous tension.
+- Testez la connectivité (AD, DNS, Bastion, Internet).
+- Validez chaque application et service.
+
+### Étape 15 : Valider ou annuler la migration
+
+Si tous les tests réussissent, validez l'opération dans Zerto.
+
+Si quelque chose ne fonctionne pas, vous pouvez annuler le déplacement et revenir à votre environnement local.
+
+Voir le guide Zerto suivant : [Déplacement des machines virtuelles protégées vers le site distant](https://help.zerto.com/bundle/Admin.ZSSP.HTML.10.0_U3/page/Moving_Protected_Virtual_Machines_to_the_Remote_Site.htm){.external}.
+
+### Étape 16 : Utiliser Storage vMotion pour placer les VM sur le stockage cible
+
+Après la migration, vous pouvez souhaiter déplacer certaines machines virtuelles vers un autre datastore ou une autre stratégie vSAN.
+
+Utilisez `Storage vMotion`{.action} via `vSphere Client`{.action} :
+
+1. Faites un clic droit sur la VM puis cliquez sur `Migrer`{.action}.
+2. Sélectionnez `Modifier le stockage uniquement`{.action}.
+3. Choisissez le datastore de destination ou la stratégie vSAN.
+
+Pour plus de détails, consultez notre guide « [VMware Storage vMotion](/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_storage_vmotion) ».
+
+### Étape 17 : Sauvegarder vos charges de travail
+
+Une fois vos VM en production, sécurisez-les avec un plan de sauvegarde.
+
+Vous disposez de 2 options :
+
+- **Option 1** : Utiliser **Veeam Backup as a Service** si vous souhaitez une solution de sauvegarde managée intégrée à votre HPC.
+- **Option 2** : Déployer votre propre serveur Veeam Backup et utiliser **Veeam Backup & Replication for Public Cloud**.
+
+## Aller plus loin
+
+Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en œuvre de nos solutions, contactez votre Technical Account Manager ou demandez une analyse personnalisée de votre projet à nos experts de l’équipe [Professional Services](/links/professional-services).
+
+Posez des questions, donnez votre avis et interagissez directement avec l’équipe qui construit nos services Hosted Private Cloud sur le canal [Discord](https://discord.gg/ovhcloud){.external} dédié.
+
+Échangez avec notre [communauté d'utilisateurs](/links/community).
\ No newline at end of file
diff --git a/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/meta.yaml b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/meta.yaml
new file mode 100644
index 00000000000..033070e2e51
--- /dev/null
+++ b/pages/hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud/meta.yaml
@@ -0,0 +1,2 @@
+id: 95fa5913-2e97-4e82-9730-925c5c37de31
+full_slug: vmware-migration-zerto-secnumcloud
\ No newline at end of file
diff --git a/pages/index.md b/pages/index.md
index 1c344a89b3a..682aaecaf23 100644
--- a/pages/index.md
+++ b/pages/index.md
@@ -510,8 +510,10 @@
             + [VPN-SPN Concept](hosted_private_cloud/hosted_private_cloud_powered_by_vmware/snc-connectivity-concepts-vpn-spn)
             + [SPN Connector Concept](hosted_private_cloud/hosted_private_cloud_powered_by_vmware/snc-connectivity-concepts-spn-connector)
             + [Migrating VMware Workloads to OVHcloud SecNumCloud with Veeam Replication](hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_veeam_secnumcloud)
+            + [Migrating VMware Workloads to OVHcloud SecNumCloud with Zerto](hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto_secnumcloud)
         + [Migration](hosted-private-cloud-hosted-private-cloud-powered-by-vmware-migration)
             + [Move2Cloud - Migrating VMware Workloads to OVHcloud Hosted Private Cloud with Veeam Replication](hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_veeam)
+            + [Move2Cloud - Migrating VMware Workloads to OVHcloud Hosted Private Cloud with Zerto](hosted_private_cloud/hosted_private_cloud_powered_by_vmware/vmware_migration_zerto)
     + [Nutanix on OVHcloud](products/hosted-private-cloud-nutanix-on-ovhcloud)
         + [Getting started](hosted-private-cloud-nutanix-on-ovhcloud-getting-started)
             + [Nutanix global high-level documentation](hosted_private_cloud/nutanix_on_ovhcloud/01-global-high-level-doc)