Inventorier le legacy : choisir quoi migrer, conserver ou retirer

Exporter la liste des déploiements VM Apps donne rapidement un classeur rassurant. Pourtant, ce classeur ne dit pas qui dépend de webshop-db-01, quelle équipe peut accepter une coupure, ni si le certificat, la licence et la sauvegarde survivront à une reconstruction. Un inventaire de ressources n’est pas encore un plan de migration.

La bonne unité de décision est le service applicatif. Cet article relie la vérité de VCF Automation aux dépendances réseau, données, identité et exploitation, puis classe chaque service dans l’une de cinq stratégies. Le livrable n’est pas « tout migrer » : c’est obtenir 100 % de décisions justifiées, avec des blockers visibles et une vague vérifiable.

TL;DR

• Décision : inventorier le contrat de service complet, puis choisir retain, retire, rebuild, repackage ou modernize pour chaque application.
• Arbitrage coûteux : un score moyen cache les dépendances critiques ; une seule gate rouge sur les données ou le rollback doit bloquer la vague.
• Lundi matin : exporter les objets en lecture seule, nommer un owner pour chaque service et organiser un atelier de dépendances avec Réseau, IAM, Sauvegarde et Exploitation.

Une VM n’est pas une unité de migration

WebShop paraît simple dans l’interface : trois VM issues d’un Cloud Template. Vu par son consommateur, le service comprend pourtant un endpoint, une transaction métier, une base PostgreSQL, des identités, des certificats, des règles réseau, un load balancer, des sauvegardes, des alertes et plusieurs objets d’automatisation.

Schéma original : le registre joint le graphe plateforme au graphe applicatif.

Une vague ne réussit donc pas parce que webshop-web-01 démarre dans All Apps. Elle réussit lorsque l’endpoint attendu fonctionne, que la transaction de référence passe, que les données sont cohérentes, que l’astreinte reçoit une alerte exploitable et qu’un chemin retour reste disponible pendant la fenêtre décidée.

Pour construire cette vue, joins deux graphes :

1. Graphe plateforme — organisation, projet, catalog item, version du template, deployment, ressources, actions Day‑2 et owner technique.
2. Graphe applicatif — service, composants, flux, données, identités, systèmes externes, équipes et objectifs de reprise.

Le registre doit conserver les identifiants source et cible. Les noms seuls ne suffisent pas : webshop-prod peut désigner un catalog item, un deployment, une entrée CMDB ou un service métier sans que ces objets partagent le même cycle de vie.

Extraire quatre vérités sans modifier la source

L’inventaire commence par une collecte en lecture seule. Depuis VCF Automation, relève organisations, projets, membres, cloud accounts, zones, mappings, Blueprints/Cloud Templates, versions, catalog items, Custom Forms, deployments, leases, policies, subscriptions, workflows Orchestrator, actions ABX et Custom Resources. Pour chaque objet, conserve au minimum son ID, son scope, sa version, son owner, son dernier usage observé, ses dépendances et l’horodatage de l’export.

Cette vue plateforme doit être confrontée à trois autres sources :

Source	Ce qu’elle apporte	Angle mort fréquent
VCF Automation	objets gérés, template, owner, lifecycle	appels hors plateforme et données métier
vCenter/NSX	placement, NIC, segments, règles, trafic	intention métier et contrat de catalogue
CMDB, monitoring, backup	propriété, santé, restauration	dérive ou enregistrement obsolète
atelier applicatif	dépendances, fenêtres, tolérance	IDs techniques et flux réellement actifs

Un écart n’est pas résolu par une moyenne entre les sources. Si NSX voit un flux que le propriétaire ne connaît pas, le flux devient une question à investiguer. Si la CMDB attribue le service à une équipe dissoute, l’application n’a pas d’owner fiable et ne passe pas en pilote.

Ne mets ni mot de passe, ni token, ni clé privée dans ce registre. Enregistre la référence vers le coffre et le propriétaire de la rotation. La migration est justement l’occasion de recréer les secrets et d’éviter de transporter une identité historique dans la cible.

Définir le contrat WebShop avant la cible

Le contrat décrit ce qui doit rester vrai, indépendamment du mécanisme de déploiement. Cet exemple est volontairement concret sur les noms et prudent sur les résultats :

service_contract:
  id: webshop-prod
  consumer_endpoint: webshop.corp.example
  business_owner_role: ecommerce-owner
  functional_checks:
    - GET /healthz returns 200
    - GET /readyz returns 200 when dependencies are ready
    - reference checkout transaction succeeds
  data:
    technology: PostgreSQL
    rpo: required-before-wave
    rto: required-before-wave
    reconciliation: required-before-wave
  operations:
    monitoring_owner: platform-observability
    backup_owner: data-protection
    incident_route: ecommerce-on-call
  security:
    flow_review: required-before-wave
    identity_rotation: required-before-cutover
  evidence_status: design-example
  execution_status: not-executed

Les chemins /healthz et /readyz doivent avoir des sémantiques distinctes : le premier prouve que le processus vit ; le second ne passe que lorsque les dépendances nécessaires sont prêtes. Ajoute une transaction métier représentative, car un HTTP 200 sur la page d’accueil ne valide ni l’écriture en base, ni l’identité, ni l’appel vers un service externe.

Le contrat devient ensuite la matrice de parité du cutover. Même si la cible utilise un Blueprint différent et de nouveaux IDs, elle doit satisfaire les mêmes comportements tant que le programme n’a pas explicitement approuvé une modernisation fonctionnelle.

Choisir l’une des cinq décisions

Le portefeuille n’a pas besoin d’atteindre 100 % de migration. Il doit atteindre 100 % de décisions gouvernées. Une application retain avec une cible durable et une date de revue est plus saine qu’une application « à migrer » sans owner depuis six mois.

Utiliser des gates, jamais une moyenne rassurante

Un score de 82 % peut masquer l’absence totale de retour arrière sur la base de données. Les critères réellement bloquants doivent rester visibles individuellement :

Gate	Vert	Orange	Rouge bloquant
Owner	disponible et décisionnaire	intérim identifié	inconnu
Dépendances	cartographiées et testables	écarts mineurs ouverts	flux critique inconnu
Image/runtime	supporté, boot testé	adaptation définie	non supporté
Données	transfert et retour testés	méthode non répétée	aucune voie de retour
Réseau	flux et DNS/LB approuvés	règle temporaire gouvernée	dépendance impossible
Identité	groupes, comptes et certificats gérés	rotation planifiée	secret non maîtrisé
Extensions	mapping cible testé	rework important	dépendance irremplaçable
Licence	double run/rehost autorisé	validation juridique ouverte	usage interdit
Rollback	trigger, autorité et séquence exercés	exercice planifié	aucun chemin

Une gate rouge critique bloque la vague, même si toutes les autres sont vertes. Une gate orange a un owner et une échéance ; elle ne devient pas verte parce que le comité souhaite tenir la date.

Pour le pilote webshop-web-nonprod, l’absence de données métier réduit le risque, mais le service doit rester représentatif : VPC, identité, catalogue, monitoring, action Day‑2 et delete doivent tous être sollicités. Un « hello world » valide l’accès à la plateforme, pas le modèle opérationnel.

Classer aussi les objets d’automatisation

La décision applicative ne dit pas comment traiter chaque artefact VCF Automation. Ajoute un traitement séparé :

Traitement	Usage	Exemple WebShop
réutiliser sous conditions	objet sous-jacent conservé, nouvelle allocation	Content Library validée pour la cible
exporter, adapter, importer	source portable, dépendances rebranchées	logique du Cloud Template réécrite
recréer	scope ou ID cible différent	projet, policies, secrets avec rotation
conserver puis drainer	objet actif reste piloté par VM Apps	deployment webshop-prod-042
archiver seulement	preuve historique, pas d’objet cible	ancien historique d’approbation

Ne promets pas qu’un export implique une portabilité sémantique. VM Apps et All Apps n’exposent pas le même modèle de ressources. Un formulaire peut être transportable comme fichier tout en dépendant d’une action, d’un ID ou d’un endpoint qu’il faut recréer et reconnecter.

Construire les vagues autour des preuves

Une séquence raisonnable pour le cas d’étude est :

1. Vague 0 — fondation : Region, organisation, projet, Namespace, VPC, images, identité et politiques ; aucun workload métier.
2. Vague 1 — pilote : WebShop non-production stateless ; tests create, fonctionnalité, Day‑2, observabilité, delete et rollback.
3. Vague 2 — stateless production : tiers Web et App en All Apps, base encore legacy, flux temporaire gouverné.
4. Vague 3 — données : base cible, réplication, réconciliation et chemin retour exercé avant bascule.
5. Vague 4 — tail : autres services éligibles, retraits et exceptions formalisées.
6. Vague 5 — sortie : drain, désactivation observée puis retrait de VM Apps lorsque les dépendances acceptées sont nulles.

Chaque vague possède des conditions d’entrée et de sortie, un change owner et une autorité de rollback. La source reste opérable jusqu’à l’acceptation métier et la fermeture de la fenêtre retour. Cette logique de strangulation contrôlée évite de coupler reconstruction de la plateforme, migration des données et modernisation fonctionnelle dans un seul big bang.

Évaluer App Stack Formation séparément

L’éligibilité à All Apps et l’éligibilité à App Stack Formation sont deux questions différentes. Une application peut être reconstruite dans All Apps sans que son Namespace soit capturable comme Stateful Blueprint.

Pour une éventuelle capture ultérieure, relève dès maintenant le Namespace self-service, le VM Group, la Content Library du projet, les adresses ou hostnames codés en dur, l’ordre de démarrage et d’arrêt, ainsi que les exigences de cohérence des données. La documentation Working with Stateful Blueprints consultée pour VCF Automation 9.1 décrit également des blockers de capture, notamment la présence de VKS, d’un Avi Load Balancer ou de vSphere Pods dans le Namespace. Revalide cette liste sur le build cible avant le preflight.

Un blocker App Stack ne doit pas rougir toute l’application dans le registre principal. Il ferme une méthode de packaging ; il ne prouve pas que la migration All Apps est impossible.

Pièges & points de vigilance

• Conserve pagination, rôle et timestamp avec chaque export ; un écart UI/API peut venir du périmètre de lecture.
• Versionne les décisions au lieu d’écraser leur historique.
• Traite unknown comme une question bloquante, jamais comme une absence de dépendance.
• Vérifie les relations par ID lorsqu’un template semble inutilisé mais possède encore des deployments.
• N’autorise aucune suppression de masse pendant la découverte.

Sources officielles

• Broadcom TechDocs — Bimodal Consumption Design for VM Apps and All Apps Workloads
• Broadcom TechDocs — Understanding the All Apps Organization Multi-Tenancy Model
• Broadcom TechDocs — Working with Stateful Blueprints
• Broadcom TechDocs — Import or Export a Stateful Blueprint

Conclusion

Un inventaire utile ne compte pas seulement les objets : il relie un service, ses preuves et une décision. WebShop devient migrable lorsque ses dépendances sont connues, que son owner accepte le contrat, que chaque gate critique est verte et que la vague possède un retour démontrable. Jusqu’alors, le statut honnête reste bloqué ou non exécuté.

La prochaine étape pourra reconstruire Cloud Templates, Custom Forms et extensions dans le modèle All Apps.