Vos questions sur la migration.

Le délai dépend du nombre de VM, des dépendances applicatives, du réseau, du stockage et des fenêtres de changement. À titre indicatif, un périmètre de 20 à 50 VM peut tenir en 4 à 8 semaines ; un parc de plus de 200 VM s'étale souvent sur plusieurs mois. L'audit confirme le calendrier, les prérequis et les vagues avant tout engagement.

Pas nécessairement, mais nous ne promettons pas un arrêt nul pour tous les workloads. Chaque vague précise la méthode de bascule, la fenêtre d'interruption éventuelle et les contrôles de reprise. La source VMware reste disponible tant que la vague n'est pas validée.

Chaque vague possède un scénario de retour arrière, un point de décision et une durée de rétention de la source. Le niveau de perte de données possible dépend du mode de réplication et du RPO retenu : il est mesuré et accepté avant la bascule, jamais supposé nul par défaut.

Pas systématiquement. L'audit vérifie la virtualisation CPU, les contrôleurs, les interfaces réseau, le firmware, la capacité, la garantie et le cycle de vie. Le matériel n'est réutilisé que s'il répond à l'architecture cible et au niveau de risque accepté.

Non. Les appliances certifiées uniquement sur VMware, les dépendances fortes à NSX, vSAN ou VCF, certaines contraintes de latence et les exigences de support éditeur doivent être étudiées séparément. L'audit classe chaque workload : migrable, migrable sous condition, à conserver ou à réorienter.

Oui, si l'architecture et l'exploitation sont conçues pour le niveau de service attendu. Haute disponibilité, fencing, stockage, sauvegarde, supervision, sécurité, capacité et support doivent être validés ensemble. Nous ne présentons pas Proxmox comme un remplacement composant par composant de VMware.

On ne les remplace pas par un produit unique. Nous décomposons les usages réels — stockage distribué, microsegmentation, automatisation, réseau virtuel, opérations — puis définissons les composants cibles nécessaires. Les écarts fonctionnels et opérationnels sont validés en POC avant décision.

L'exploitation demande des bases solides en Linux, réseau, stockage, haute disponibilité et sauvegarde. Nous évaluons les écarts de compétences, formons les équipes et livrons les procédures d'exploitation. Le niveau d'autonomie cible est défini avec vous ; il n'est pas présumé.

Oui. La migration par vagues est notre approche standard : workloads représentatifs, services non critiques, puis périmètres plus sensibles. Chaque lot possède ses dépendances, ses critères de GO / NO-GO, son runbook et son retour arrière documenté.

Ils font partie de la cible, pas d'un lot ultérieur. Nous testons la restauration, définissons les RPO / RTO, documentons les scénarios de reprise et vérifions leur exploitation par les équipes. Une sauvegarde déclarée mais non restaurée ne constitue pas une validation.

Pas automatiquement. Le TCO doit inclure les souscriptions, le matériel, le stockage, la sauvegarde, la migration, la formation et l'exploitation sur trois à cinq ans. Nous comparons ces postes au contrat VMware et au parc réel afin de présenter une fourchette et des hypothèses vérifiables.

Oui. VSHIFT est partenaire Proxmox avec le statut Authorized Reseller. Nous pouvons gérer les souscriptions Proxmox VE et Proxmox Backup Server, les renouvellements et l'escalade des demandes techniques, avec un interlocuteur identifié.

Un POC reproduit les contraintes utiles sur VSHIFT Cloud ou sur votre infrastructure : performances, réseau, stockage, haute disponibilité, sauvegarde et exploitation. La décision GO / NO-GO s'appuie sur des mesures et des critères acceptés avant le test.

Nous cadrons le périmètre, les contraintes de production et le niveau de décision attendu lors d'un échange technique de 30 à 45 minutes. Vous recevez ensuite une proposition de prochaine étape : audit, atelier d'architecture ou POC.