Après l’upgrade : ce que l’organisation VM Apps préserve vraiment

Le tableau de bord est vert après l’upgrade, mais WebShop dépend encore de catalogues, d’identités et de workflows créés sous Aria Automation. Démarrer immédiatement la construction All Apps transformerait le premier incident en enquête impossible : régression de l’upgrade, dette historique ou erreur de migration ? Sans état initial fiable, ces trois causes se confondent.

L’objectif est donc plus exigeant qu’un contrôle de santé superficiel. Il faut démontrer que l’organisation VM Apps issue de l’upgrade reste un filet de sécurité opérationnel, avec ses utilisateurs réels, ses intégrations et un cycle de vie complet. Cette baseline devient la référence contre laquelle chaque vague All Apps sera comparée.

TL;DR

• L’upgrade convertit le legacy Aria Automation en une ou plusieurs organisations VM Apps. Il préserve la continuité du modèle historique ; il ne crée ni Region, ni Namespace, ni VPC All Apps.
• Une source n’est stable que si les comptes non-admin, Embedded Orchestrator, cloud accounts, catalogues, actions Day‑2 et dépendances externes fonctionnent, pas seulement si les services apparaissent en vert.
• Ouvre deux files de travail : UPG-* pour les écarts nés de l’upgrade et MIG-* pour la reconstruction All Apps. Aucune vague ne démarre avec un incident d’upgrade non qualifié.

Comprendre ce que l’upgrade préserve — et ce qu’il ne fait pas

Le parcours Broadcom importe une instance Aria Automation compatible dans VCF Operations puis l’élève vers VCF Automation. Pour le fil rouge, la source est annoncée en 8.18.1 ou ultérieur, mais le couple de builds réellement supporté doit être confirmé dans le VCF Upgrade Planner et dans la documentation à jour. Un numéro de version de famille n’est pas une autorisation de dérouler une procédure sur n’importe quel patch.

À l’issue du parcours, les tenants historiques deviennent des organisations VM Apps. Les Cloud Templates historiques, projets et déploiements restent associés à ce modèle. Lorsqu’il existe plusieurs tenants, la documentation décrit plusieurs organisations VM Apps ; la création supplémentaire suit par ailleurs des contraintes différentes entre interface et API.

Ce que l’upgrade ne réalise pas est tout aussi important : il ne crée pas la landing zone All Apps, ne transforme pas les cloud zones en Regions ou Region Quotas, ne place pas les VMs dans des Namespaces, ne convertit pas les réseaux historiques en VPC et ne remplace pas les types Cloud.* par les ressources du modèle All Apps. La compatibilité obtenue est un point de départ, pas une migration applicative terminée.

Archiver l’avant pour expliquer l’après

La meilleure baseline commence avant l’upgrade. Elle doit inventorier tenants, projets, utilisateurs, groupes, cloud accounts, intégrations, Cloud Templates, versions, Custom Forms, items de catalogue, entitlements, déploiements, owners, leases, policies, subscriptions, workflows Orchestrator, actions ABX et Custom Resources. Elle doit également contenir les certificats et endpoints attendus, une référence de sauvegarde et un test métier de WebShop.

Cette archive ne constitue pas un bouton de retour. Elle répond à une question plus élémentaire : « qu’est-ce qui existait, avec quel identifiant et quel propriétaire ? » Sans elle, un écart de quantité ou de comportement peut être interprété comme normal simplement parce que personne ne possède la mesure précédente.

post_upgrade_baseline:
  evidence_status: expected_result
  exact_vcfa_build: evidence_required
  source_aria_build: evidence_required
  vm_apps_organizations: evidence_required
  webshop_deployment_health: evidence_required
  cloud_accounts_collection: evidence_required
  embedded_orchestrator_health: evidence_required
  identity_login_matrix: evidence_required
  create_day2_delete_cycle: evidence_required
  backup_and_restore_reference: evidence_required
  open_upgrade_incidents: []
  migration_ready: false

migration_ready ne devient vrai qu’après résolution ou acceptation formelle des écarts, avec un propriétaire et une preuve. Le champ n’est jamais déduit d’un statut global de plateforme.

Reconstituer l’inventaire VM Apps

Dans Provider Management, relève pour chaque organisation son nom, son identifiant URL, son type, son état et ses administrateurs. Corrèle ensuite ces informations avec la source archivée. Pour WebShop, acme-vmapps-legacy doit encore contenir le projet prj-webshop-legacy et le déploiement webshop-prod-042.

Évite les changements cosmétiques pendant cette phase. Renommer trop tôt le nom affiché ou modifier les rattachements complique la corrélation avec les journaux, les exports et les tickets. L’identifiant URL possède en outre des contraintes propres et ne doit pas être traité comme une simple étiquette modifiable.

Pour chaque cloud account et intégration, vérifie le statut, la collecte supportée, le nombre d’objets, les endpoints, les certificats et les chaînes de confiance. Le KB 425489 documente un cas applicable au passage 8.18.1 vers 9.1.x : des certificats implicitement approuvés dans la source peuvent manquer dans la base migrée et faire échouer le précheck. Désactiver TLS pour avancer masquerait la cause et dégraderait la sécurité ; il faut corriger la confiance avec la procédure correspondant au build.

Vérifier Orchestrator et les extensions avec un effet maîtrisé

Embedded Orchestrator mérite un contrôle distinct. Le KB 443720 décrit un problème après certains upgrades 8.18.x vers 9.x : l’intégration peut conserver un ancien endpoint au lieu de https://embedded.orchestrator:443. Un simple voyant d’intégration ne suffit alors pas ; catalog items, subscriptions et workflows peuvent échouer plus tard.

Le contrôle prudent combine la vue d’intégration, le statut Embedded, l’endpoint attendu et l’exécution d’un workflow sans effet de bord. Une subscription non bloquante peut ensuite être déclenchée dans un périmètre isolé, avec ID de corrélation et logs. Le workaround du KB est conditionnel, en particulier lorsqu’un Orchestrator externe existe : aucune modification de base improvisée ne doit remplacer la procédure et la sauvegarde demandées par Broadcom.

Il faut également classer les extensions. Une action qui échoue maintenant est un écart UPG-* si elle fonctionnait dans la baseline et devait rester disponible dans VM Apps. Sa future réécriture selon les événements ou ressources All Apps relève d’un ticket MIG-*. Réécrire immédiatement l’action sur la cible cacherait une régression de la source qui doit pourtant rester le chemin de retour.

Tester l’identité avec des personas réels

Le compte Organization Admin est un mauvais échantillon : ses privilèges peuvent masquer une erreur de groupe, d’entitlement ou de policy. La matrice doit inclure au minimum Organization Admin, Project Admin, utilisateur de catalogue et compte de service/API. Pour chacun, vérifie connexion, visibilité du catalogue, accès au déploiement WebShop et actions Day‑2 autorisées.

Persona	Connexion	Catalogue	WebShop	Day‑2 attendu
Organization Admin	preuve requise	preuve requise	lecture/administration	selon policy
Project Admin	preuve requise	périmètre projet	lecture/administration	selon policy
utilisateur catalogue	preuve requise	items autorisés	propriétaire ou lecture	actions déléguées
compte de service/API	token et contexte org	selon contrat	accès minimal	opérations automatisées

Broadcom documente une continuité SSO pour VM Apps ainsi qu’une migration vers VCF Identity Broker/VCF SSO. Cette compatibilité est transitoire. La future organisation All Apps possède son propre rattachement d’identité et le KB 440245 indique que vIDM n’est pas un IdP supporté pour All Apps. Ne retire donc vIDM qu’après avoir prouvé le nouveau chemin pour les groupes, utilisateurs et clients automatisés concernés.

Prouver un cycle de vie sans toucher à la production

Un item de test isolé doit parcourir request, provisioning, action Day‑2 non destructive, éventuelle action personnalisée, delete, puis contrôle des orphelins DNS, IPAM, AD et CMDB. Cette séquence vérifie que VM Apps peut encore porter une opération normale pendant la transition. Elle ne dit rien de la capacité All Apps, qui aura ses propres tests.

WebShop doit en parallèle rester inchangé. Capture la résolution de webshop.corp.example, les réponses /healthz et /readyz, une transaction métier, l’accès à la base, l’état du load balancer, les métriques, les logs, la sauvegarde et les objets externes associés. Ne place ni secret ni donnée personnelle dans le dossier de preuve.

upgrade_gap:
  id: UPG-001
  area: orchestration
  source_baseline: embedded_endpoint_healthy
  observed_after_upgrade: workflow_test_failed
  business_impact: catalog_action_unavailable
  owner: platform_operations
  resolution_or_acceptance: evidence_required
  migration_blocker: true

Le registre évite aussi les diagnostics hâtifs. Le KB 445482 décrit un compteur d’organisations à zéro dans le périmètre précis d’un upgrade 9.0.2 vers 9.1, alors que l’accès structurel peut être restauré. C’est une illustration de divergence UI/inventaire, pas une preuve que le même symptôme affecte directement une source Aria Automation 8.18.1.

Incidents et diagnostic

Symptôme	Première vérification	Décision sûre
organisation absente	migration de base, rôles, inventaire via source de vérité	conserver bundles et task IDs, escalader
cloud account non sain	certificat, endpoint, compte, collecte	appliquer le précheck correspondant
Orchestrator non Embedded	endpoint et intégrations externes	suivre KB 443720, sans SQL improvisé
seul l’admin se connecte	IdP, groupes, rôles effectifs	bloquer la migration jusqu’au test des personas
action Day‑2 en échec	policy, subscription, workflow, credential	capturer l’ID de corrélation et classer UPG ou MIG
UI et inventaire divergent	API, base migrée, KB du build exact	ne supprimer aucun objet sur la seule UI

Rollback de l’upgrade : ne pas inventer

Le retour de l’upgrade et le retour d’une application sont deux sujets différents. Les sources consultées ne décrivent pas un mécanisme générique consistant à rallumer les anciens nœuds après une migration échouée. Un snapshot peut faire partie d’une procédure supportée ; il ne devient pas à lui seul une procédure de rollback.

Si la plateforme post-upgrade est instable, arrête les travaux All Apps, préserve sauvegardes, snapshots autorisés, bundles et IDs de tâches, puis applique la procédure officielle correspondant au point de défaillance. Ouvre un dossier GSS lorsque le cas n’est pas couvert. Ne redéclare la source stable qu’après les tests fonctionnels et d’identité, pas après le retour d’un voyant vert.

Sources officielles Broadcom

• Phase 3: Import and Upgrade Aria Automation 8 to VCF Automation 9
• KB 440630 — Upgrade Sequence and Related Issues
• Create a VCF Automation Organization for VM Applications
• Migrate VCF Automation SSO to VCF Identity Broker
• KB 425489 — 8.x Endpoint Certificates Upgrade Pre-check
• KB 443720 — Embedded Orchestrator after Upgrade
• KB 440245 — vIDM and All Apps

Conclusion

Une organisation VM Apps préservée n’est pas encore une organisation VM Apps démontrée stable. La différence tient au dossier de preuve : inventaire corrélé, intégrations testées, identité validée hors admin, cycle de vie complet, WebShop inchangé et aucun incident d’upgrade non qualifié. Une fois ces gates franchies, l’étape suivante peut dessiner le pont Mixed Tenancy ou dédié sans déplacer la ligne de départ pendant le projet.