La dernière VM migrée ne termine pas le programme. Un token oublié, une subscription de cleanup, un dashboard pointant vers l’ancien CI ou une équipe qui ouvre encore ses incidents sur VM Apps suffit à maintenir la dépendance. Compter les workloads donne donc une fausse impression de fermeture.
Ce dernier chapitre traite la plateforme dans son ensemble : identité, clients API, support, coût, archives, writers externes et organisation legacy. La sortie suit quatre états : ouverte → gelée → désactivée → éventuellement supprimée. Les contrôles proposés sont une reconstitution non exécutée. Ils doivent être adaptés au build VCF Automation 9.1, au contrat de rétention et aux réponses GSS obtenues pour l’environnement.
TL;DR
- Geler les nouvelles demandes, drainer les deployments et couper les writers legacy précède la désactivation ; un inventaire nul de VM ne suffit pas.
- La désactivation est le sas d’observation : les utilisateurs perdent l’accès, tandis que le Provider Administrator conserve une capacité de gestion documentée. La suppression, elle, est permanente.
- Dès lundi, construisez une matrice « zéro dépendance non acceptée » couvrant workload, donnée, réseau, identité, API, extensions, opérations et audit, avec un owner pour chaque exception.
Quatre états, un seul point irréversible
Les TechDocs d’activation et de désactivation indiquent que désactiver une organisation empêche les utilisateurs de se connecter et termine leurs sessions. Le Provider Administrator peut encore administrer ses ressources et réseaux. Cette propriété fait de l’état Disabled un bon sas : on observe ce qui casse sans avoir encore supprimé l’organisation.
L’état Frozen est une convention d’exploitation proposée, pas un type d’organisation Broadcom. Les nouveaux catalog requests sont bloqués, mais les actions Day-2 et les subscriptions nécessaires aux ressources encore vivantes restent disponibles. Le retour de Disabled vers un état exploitable doit être vérifié sur le build exact avant d’être promis. La suppression d’organisation est documentée comme permanente : elle ne sert jamais de test.
La suppression n'est pas un mécanisme de rollback
Après delete, aucune restauration de l’organisation n’est promise. La reconstruction dépendrait des archives, sauvegardes, systèmes externes et procédures supportées. Toute décision de suppression doit donc venir après l’observation, pas pour la provoquer.
Sortir de l’identité legacy sans perdre les utilisateurs
Après upgrade, vIDM peut continuer à assurer la compatibilité du rail VM Apps. La cible sépare les plans : le Provider Management migre vers VCF Identity Broker et VCF SSO, tandis que l’organisation All Apps utilise un IdP supporté et ses mappings de groupes. Le KB Broadcom 440245, dont l’environnement déclaré est VCF Automation 9.0.x, documente l’incompatibilité de vIDM comme IdP All Apps. Pour 9.1, confirmez ce point avec les TechDocs IdP 9.1 et le build exact.
La séquence sûre commence par un compte break-glass testé, puis la connexion de l’IdP cible. Importez des groupes plutôt qu’une liste manuelle d’utilisateurs, affectez les rôles Organization Admin, Project Admin et Project User, et testez chaque persona : login autorisé, visibilité attendue, action autorisée et refus prévu. Le succès du seul administrateur ne prouve pas le mapping des consommateurs.
Les comptes de service et clients machine suivent leur propre inventaire. Ils reçoivent un endpoint cible, un flux de token supporté, un contexte d’organisation et de projet, des scopes minimaux et un secret tourné. Observez les logs d’authentification avant de révoquer le rail précédent. La migration SSO vers VCF Identity Broker fournit la procédure produit ; votre registre relie chaque groupe et client source à son équivalent cible.
Requalifier les API et extensions
VM Apps et All Apps n’exposent pas le même contrat fonctionnel. Un client qui reçoit HTTP 200 mais un catalogue vide peut utiliser le mauvais tenant, le mauvais scope ou le mauvais projet. Testez une opération utile de bout en bout, pas seulement l’obtention du token.
| Élément | Rail VM Apps | Rail All Apps | Preuve de fermeture |
|---|---|---|---|
| endpoint | URL legacy inventoriée | URL cible approuvée | requête utile réussie |
| token | ancien flow | flow supporté | expiration et rotation testées |
| contexte | organisation VM Apps | organisation + projet All Apps | objets attendus visibles |
| payload | types historiques | modèle All Apps | contrat et erreur validés |
| scopes | hérités | moindre privilège | refus négatif testé |
Le KB 427076 rappelle que l’Embedded Orchestrator ne prend pas en charge Basic Authentication dans le contexte documenté. Ne réactivez pas un mécanisme faible pour éviter d’adapter un client. Migrez packages, endpoints, certificats et token flows, puis révoquez les credentials legacy.
Pour les subscriptions et Custom Resources, l’ordre compte. Désactivez les subscriptions de création ou de mise à jour lorsque plus aucun service ne doit écrire dans DNS, IPAM, AD ou CMDB. Conservez les chemins de delete/cleanup jusqu’au dernier objet, sinon la plateforme ne pourra plus nettoyer ce qu’elle a créé. Archivez ensuite package, version, topic, payload observé, workflow, compte technique et relation avec les IDs externes.
client_migration_record_template:
evidence_status: expected-result
validation_requirements:
- useful-operation-succeeds
- least-privilege-negative-test
- legacy-secret-revoked-after-observation
client: webshop-release-pipeline
target_context: acme-all-apps/prj-webshop-modern
authentication: supported-token-flow
useful_test: catalog-query-and-deployment-read
least_privilege_negative_test: required
old_secret_revocation: after-observation
execution_status: not-performedExploiter deux rails sans deux vérités
Pendant la coexistence, Service Desk, NOC et SecOps doivent connaître le rail propriétaire de chaque service. Pour chaque cible All Apps, publiez runbook, équipe d’astreinte, dashboards, alertes, corrélation des logs par organisation/projet/Namespace/deployment, backup et restauration, règles de rotation, actions Day-2 et route d’escalade provider versus organization.
Créez une table de correspondance entre ancien et nouveau CI. Sans elle, un incident peut être ouvert sur l’objet VM Apps retiré, une alerte cible peut être routée vers l’ancienne équipe et un audit peut perdre la relation entre request source et deployment cible. La coexistence technique est simple comparée à la discipline d’ownership qu’elle exige.
Le reporting de coût requiert également une correction. Le KB 435125 indique que les organisations VM Apps ne sont pas visibles dans Capacity > Cost > ShowBack > Organization, contrairement aux organisations All Apps. Une baisse apparente dans cette vue ne prouve donc pas le drainage du legacy. Construisez un rapport transitoire à partir d’autres vues ou exports supportés et affichez séparément le coût du double run. Ne promettez pas une continuité historique de showback entre les deux modèles.
Geler, drainer, archiver
Classez chaque catalog item VM Apps en replace, retain, retire ou unknown. replace masque ou dépublie l’item legacy pour les nouvelles demandes et renvoie les consommateurs vers la cible. retain décrit une exception avec owner et date de révision. retire ferme après preuves. unknown bloque le retrait et reçoit immédiatement un propriétaire d’investigation.
Chaque deployment restant obtient une disposition explicite :
deployment_disposition_example:
evidence_status: design-hypothesis
execution_status: not-performed
source_id: webshop-prod-042
service: webshop-prod
owner: ecommerce-operations
decision: migrated
target_id: webshop-modern-118
data_disposition: reconciled-and-accepted
external_objects: [dns-record, cmdb-ci, ad-computer-accounts]
audit_reference: CHG-2026-1842
delete_authorized: falseUn deployment sans owner n’est pas un bon candidat à la suppression. Il est un blocker. Pour les objets retirés, l’archive conserve organisation, projet, catalog item, template et versions ; requests, deployments et resources ; owners, leases et approbations ; historique d’événements utile ; Custom Forms ; packages Orchestrator ; instances de Custom Resources ; relation ancien ID → nouvel ID ; décisions de cutover et preuves de nettoyage.
Testez l’archive en recherchant un ancien ID depuis un poste qui ne dépend pas de l’organisation VM Apps. Une archive seulement lisible depuis la plateforme que l’on s’apprête à supprimer n’est pas une archive de sortie.
Couper les writers dans le bon ordre
Commencez par interdire les nouvelles demandes. Vérifiez ensuite qu’aucun deployment n’a besoin d’un create/update externe, exécutez les derniers cleanups, désactivez les subscriptions de create/update, conservez le delete jusqu’à la fin, puis révoquez comptes et workflows legacy. Enfin, confirmez que les writers All Apps sont les seuls propriétaires actifs.
Cette séquence évite qu’une action tardive modifie un CI, une adresse ou un compte AD pendant l’observation. Elle évite aussi le piège inverse : supprimer trop tôt le workflow de cleanup et conserver des objets externes sans lifecycle.
La revue « zéro dépendance non acceptée »
| Domaine | Question de fermeture |
|---|---|
| workload | chaque deployment possède-t-il une disposition et un owner ? |
| donnée | chaque volume, backup et archive a-t-il une rétention décidée ? |
| réseau | règles, VIP, DNS et IPAM legacy sont-ils traités ? |
| identité | groupes, comptes, tokens et certificats sont-ils migrés ou révoqués ? |
| extensions | subscriptions, workflows et Custom Resources sont-ils éteints ou archivés ? |
| opérations | monitoring, backup, incident et coût cible sont-ils opérationnels ? |
| audit | tout ancien ID est-il retrouvable hors de VM Apps ? |
| support | les questions GSS bloquantes ont-elles une réponse écrite ? |
Le mot acceptée permet une exception légitime, mais jamais une exception invisible. Elle possède un owner, un risque, une échéance, un coût et une plateforme durable. Le gate ne cherche pas nécessairement zéro objet ; il exige zéro dépendance dont le sort reste inconnu.
Désactiver, observer, décider
Après approbation, désactivez acme-vmapps-legacy depuis Provider Management. Conservez task ID, horodatage, approbateurs, état avant action, test de refus utilisateur et résultats des contrôles All Apps. Pendant la période d’observation, surveillez authentifications refusées, appels API, tâches planifiées, alertes et tickets utilisateur.
Si une dépendance légitime apparaît, le contrôle de l’organisation dans Provider Management est présenté comme « Enable or Disable », mais le comportement de réactivation et la conservation de l’état doivent être validés sur le build exact. Si la réactivation est nécessaire et validée, réactivez l’organisation sous change approuvé, n’exposez que la fonction de catalogue ou Day-2 indispensable au traitement de la dépendance, remettez l’organisation à l’état gelé et recommencez l’observation. Ne rouvrez pas tout le catalogue par réflexe.
La suppression permanente requiert au minimum : observation achevée, aucun workload ou objet externe non traité, archive testée, credentials révoqués, backups conformes, signatures application/data/platform/sécurité/audit et change irréversible approuvé. Les prérequis de delete varient selon le type d’organisation ; appliquez la procédure du build pour la source VM Apps et n’extrapolez pas les prérequis d’une organisation All Apps.
Un script échoue après désactivation
Le catalogue API est vide
Le coût VM Apps est absent du showback
Le cleanup ne démarre plus
Une dépendance apparaît après delete
Sortir aussi de Mixed Tenancy
Une fois VM Apps et ses dépendances partagées retirées, réévaluez feature flag, visibilité résiduelle, capacité vCenter/NSX, règles réseau temporaires, comptes legacy et éventuelle infrastructure de transition. La séquence exacte de retrait du flag et ses prechecks doivent être validés en lab et, pour la production, avec GSS. Ne désactivez pas une capacité de partage parce que le dernier deployment a disparu ; vérifiez d’abord ce qui l’utilise encore.
Conclusion
La fin de migration est une démonstration, pas un nettoyage opportuniste. On prouve que l’identité cible fonctionne, que les clients agissent dans le bon tenant, que l’exploitation sait prendre l’astreinte, que les archives survivent au legacy et que chaque writer s’est arrêté au bon moment. Ensuite seulement, la désactivation observe le silence attendu ; la suppression reste une décision séparée et irréversible.
Zéro inconnue
Une exception peut rester, mais son owner, son risque, son échéance et son chemin d’exploitation sont explicites.
Désactiver avant de supprimer
Le sas coupe les sessions et révèle les dépendances tardives tout en conservant la capacité de gestion provider documentée.
L’audit survit
Ancien et nouvel ID restent reliés dans une archive lisible sans rallumer l’organisation source.
Le produit cible construit dans l’article App Stack Formation précédent donne au consommateur un vrai chemin de remplacement. Pour reprendre l’ensemble de la décision, revenez à l’étude de migration VM Apps vers All Apps.
Sources officielles : migration SSO vers Identity Broker · gestion des Identity Providers · KB 440245 — vIDM et All Apps · KB 427076 — Orchestrator Authentication · KB 435125 — Showback · désactiver une organisation · supprimer une organisation.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
