SuiteCRM 7 vers 8 : liste de contrôle avant la transition
- SuiteCRM 8 n'est pas une mise à niveau sur place en un clic depuis 7 ; la voie officielle est une migration avec sa logique de packages et une intégration des parties historiques.
- La plupart des retards viennent d'inventaires incomplets : packages, hooks, intégrations, et de l'absence de tests réalistes en préproduction.
- Une mise en service sans retour arrière documenté ni critères de recette métier est un risque organisationnel, pas seulement informatique.
Estimer grossièrement la complexité de migration
Pas une prédiction d'heures, mais un filtre pour distinguer effort standard et projet spécifique.
Priorité à l'inventaire, la préproduction et la recette métier. Les outils structurés peuvent aider sans remplacer les tests.
Passer de SuiteCRM 7 à 8 devient incontournable pour de nombreuses organisations dès que support, pile PHP ou stratégie produit l'exigent. Ce n'est toutefois pas une simple correction courante. Documentation officielle et packages de migration montrent qu'il s'agit d'une transition structurée, pas d'écraser les fichiers d'installation en espérant le meilleur.
Cet article est une liste de préparation et de décision. Il ne remplace ni un plan de projet ni une évaluation ferme de votre code.
1. Architecture : pourquoi 7 et 8 diffèrent
SuiteCRM 8 apporte une architecture applicative et une couche d'interface modernisées ; composants historiques et parcours de migration font partie du modèle officiel. Pour les décideurs, cela signifie :
- Les attentes concernant interface, navigation et administration évoluent.
- Les personnalisations 7.x ne fonctionnent pas automatiquement à l'identique.
- L'exploitation : version PHP, étapes Composer ou console, cache et droits, suit plus étroitement les notes de la version cible.
Comparer uniquement les fonctionnalités sous-estime le travail concret de migration.
2. Clarifier le cadre avant la technique
- Fixer par écrit la version cible, par exemple une branche 8.x précise, plutôt que quelque chose de récent.
- Prioriser les motivations : sécurité, fin de vie PHP, absence de maintenance 7.x, stratégie d'interface.
- Prévoir la fenêtre de maintenance et le plan de communication aux métiers.
- Définir les rôles : qui décide du lancement, teste les processus et fournit l'hébergement ?
- Définir le retour arrière : quelles erreurs le déclenchent et combien de temps la sauvegarde reste-t-elle valable ?
3. L'inventaire, le volet le plus sous-estimé
3.1 Packages et code spécifique
Listez les packages avec version et dernier état connu. Indiquez : production, facultatif ou abandonné. Ajoutez hooks, tâches du planificateur, modules spécifiques et code copié dans custom/ sans jamais constituer un package.
3.2 Intégrations
SSO, ERP, marketing, téléphonie, gestion documentaire, exports décisionnels : chaque interface nécessite un responsable et un scénario de test après migration.
3.3 Qualité des données
Doublons, relations cassées, pièces jointes orphelines : la migration amplifie rarement les problèmes toute seule ; elle les révèle et ralentit la recette.
4. Préproduction : ce que signifie réellement « testé »
Une instance de démonstration vide prouve peu. Au minimum :
- Choisir et documenter explicitement une copie avec données réalistes ou une copie complète.
- Suivre le parcours officiel de migration de la branche choisie, plutôt que les rumeurs d'un forum comme procédure.
- Scénario : connexion, droits, processus commercial essentiel, e-mails entrants et sortants, rapport, flux spécifique critique, ouverture de pièce jointe.
- Échantillon de performance sur les modules riches en listes : subjectif, mais utile pour alerter tôt.
Les problèmes connus de la documentation, droits après CLI, CSRF ou sessions après une nouvelle migration sur la même URL, mauvais package au lieu du package de migration, doivent figurer dans la procédure, pas surprendre le week-end du lancement.
5. Données, fichiers et bascule
- Estimer les volumes de base et fichiers ; mesurer la durée de sauvegarde plutôt que l'estimer.
- Pièces jointes : échantillon avant et après, ouvrir réellement les fichiers.
- Ordre de bascule : page de maintenance, synchronisation finale, DNS ou URL, sessions et cookies, premiers tests rapides.
- Accompagnement renforcé : interlocuteur clair pendant 3 à 5 jours, contournements connus, circuit d'escalade.
SuiteMigrate facilite les reprises structurées et correspondances dans le contexte AgenticUltimate. Il ne remplace ni la recette métier ni votre responsabilité sur le code spécifique, mais peut rendre le parcours technique plus rigoureux que des scripts improvisés. L'adéquation dépend du système source et du périmètre.
SuiteMigrate ↗6. Critères de mise en service proposés
Définir avant, pas après :
- Tous les processus A validés en préproduction
- Aucun package A inconnu sans plan
- Sauvegarde et essai de restauration documentés
- Validations métier des responsables de processus
Des économies d'heures ou taux de réussite sans rapport avec votre code seraient spéculatifs ; ils sont donc volontairement absents.