Évaluer avant de planifier
Nous commençons par un inventaire : version et niveau de patch, personnalisations, intégrations, volumes de données et infrastructure sous-jacente. Chaque personnalisation est classée à conserver, à réécrire ou à retirer, car le code le moins cher à migrer est celui dont vous n’avez plus besoin.
Répéter jusqu’à ce que ce soit banal
La mise à niveau est exécutée à plusieurs reprises sur une copie de la production. Chaque répétition est chronométrée, contrôlée au regard des tests de recette convenus et transformée en un runbook plus précis. Au dernier passage, le plan de bascule se mesure en heures et en minutes ; il n’est plus estimé au jugé.
Basculer en gardant une porte de sortie
Le go-live suit le runbook étape par étape, avec des points go/no-go et un rollback déjà testé. Les utilisateurs retrouvent un système vérifié par les key users avant la fin du week-end.
Passer sur Azure
Une migration cloud déplace en même temps les vaults, la base de données et l’application : nous la traitons donc comme un projet de migration, pas comme un simple changement d’hébergement. Vous pouvez atterrir sur des machines virtuelles ou passer directement sur AKS ; dans les deux cas, le déploiement est automatisé dès le premier jour.
Quitter un système existant
Les données issues d’anciens systèmes PDM ou PLM, ou de partages de fichiers, sont chargées lors de répétitions successives jusqu’à ce que volumes, liens et états concordent. Nous définissons avec vous ce qui mérite d’être migré ; l’historique que personne ne rouvrira peut rester archivé.