Migrer vers AEM as a Cloud Service : les questions à trancher avant de lancer le projet

Migrer d’AEM 6.5 vers AEM as a Cloud Service n’est pas un simple changement d’hébergement. Le modèle de déploiement, la gestion des configurations et l’exploitation changent en profondeur. Ce qui change techniquement est décrit dans un autre article ; celui-ci recense les décisions à prendre avant de lancer le projet, celles qui déterminent son coût, sa durée et ses risques.

1. Pourquoi migrer, et pourquoi maintenant ?

La réponse conditionne tout le reste. Les raisons les plus fréquentes :

• la fin de support de votre version ou de votre service pack approche (vérifiez les dates auprès d’Adobe pour votre contrat) ;
• les mises à jour d’AEM coûtent cher à chaque montée de version ;
• l’infrastructure on-premise ou managée devient difficile à faire évoluer.

Si la motivation est floue, le projet dérivera : chaque arbitrage (réécrire ou non un composant, migrer ou archiver un contenu) se fera sans critère.

2. Quel est l’état réel du code ?

C’est le premier facteur de coût. Les points qui bloquent le passage au cloud sont connus :

• du code qui écrit dans /apps ou /libs à l’exécution, alors que cette partie du dépôt devient immuable ;
• des overlays de /libs qui dépendent d’une version précise d’AEM ;
• des fichiers lus ou écrits sur le système de fichiers local ;
• des index Oak personnalisés et des configurations OSGi à reprendre par environnement.

Le Best Practices Analyzer d’Adobe produit une première liste. Elle doit être complétée par une lecture du code : le rapport signale les symptômes, pas toujours leur ampleur réelle.

3. Que fait-on des contenus et des assets ?

Avant de tout transférer, posez trois questions :

• Quel volume ? Les pages, les fragments de contenu et surtout le DAM. Un DAM volumineux allonge les transferts.
• Que peut-on archiver ? Une migration est l’occasion de ne pas transporter des années de contenus obsolètes.
• Combien de temps peut-on geler la publication ? Le Content Transfer Tool permet des transferts en plusieurs passes ; le gel éditorial peut se limiter à la dernière.

4. Quelles intégrations dépendent du réseau ou de l’infrastructure ?

Les intégrations sont souvent la partie la moins visible et la plus risquée :

• appels vers des API internes qui filtrent par adresse IP ;
• échanges de fichiers (FTP, partages réseau) ;
• authentification d’entreprise (SAML, annuaires) ;
• traitements planifiés qui supposent un serveur toujours disponible.

Chacune doit être inventoriée avec sa solution cible : configuration réseau avancée de Cloud Manager, passage par une API, ou déplacement du traitement hors d’AEM.

5. Comment l’équipe va-t-elle livrer ?

Avec AEM as a Cloud Service, tout déploiement passe par Cloud Manager : pipelines, contrôles de qualité du code, tests. Les corrections faites directement en production ne sont plus possibles.

C’est une bonne nouvelle pour la stabilité, mais l’équipe doit s’y préparer : branches, environnements de développement, tests automatisés, temps de pipeline à intégrer dans le planning.

6. Que deviennent le Dispatcher et le cache ?

La configuration du Dispatcher doit respecter le format attendu par Cloud Manager et être validée avec les outils fournis par Adobe. C’est aussi le moment de revoir les règles de cache : une configuration reprise telle quelle peut dégrader les performances ou, à l’inverse, servir des pages périmées.

7. Bascule unique ou migration par lots ?

Une bascule unique paraît plus simple, mais elle concentre tous les risques sur une date. Un découpage en lots livrables et testables (par site, par marché ou par fonctionnalité) étale les risques et permet de corriger le tir. Le bon découpage dépend des dépendances entre sites et des contenus partagés.

8. Comment protéger le référencement ?

Le SEO est souvent traité trop tard. À prévoir dès le cadrage :

• l’inventaire des URL existantes et de leurs performances ;
• des redirections 301 testées pour toute URL qui change ;
• la vérification des canoniques, du sitemap et des balises hreflang éventuelles ;
• une mesure des Core Web Vitals avant et après la migration.

9. Quels critères pour décider de basculer ?

Définissez à l’avance ce qui autorise la mise en production : tests fonctionnels passés, performances au moins équivalentes, contenus vérifiés, redirections en place, plan de retour arrière documenté. Sans critères écrits, la décision se prend sous la pression du calendrier.

10. Qui fait quoi ?

Une migration mobilise l’équipe interne, l’intégrateur et Adobe. Clarifiez qui porte le code, les contenus, les intégrations, les tests et la recette, et qui tranche en cas de désaccord. Les retards viennent plus souvent de responsabilités floues que de difficultés techniques.

Par où commencer

L’ordre recommandé :

1. Faire l’état des lieux de la plateforme : la checklist d’audit AEM couvre les points à examiner ; si l’état de la plateforme est mal connu, un audit AEM au forfait en donne une vue priorisée.
2. Cadrer la migration : inventaire des incompatibilités, plan par lots, estimation de l’effort et des risques. C’est l’objet du cadrage de migration vers AEM as a Cloud Service.
3. Décider, avec des chiffres et des critères, plutôt qu’avec une estimation globale.

Les réponses à ces dix questions forment l’essentiel d’un dossier de décision. Elles évitent de découvrir les vrais sujets au milieu du projet, quand ils coûtent le plus cher.