Checklist de migration vers l'auto-hébergement

Une liste de contrôle d'une page pour faire passer une équipe d'un outil payant à un outil auto-hébergé. Elle couvre les étapes qui décident si la migration sera banale ou désastreuse : l'export des données, le dimensionnement, les sauvegardes, et le plan de retour arrière que la plupart des gens oublient.

1. Avant d'installer quoi que ce soit

• Exportez dès aujourd'hui une vraie copie de vos données. Pas un compte de test : votre espace de travail réel. Certains exports sont partiels, limités en débit ou réservés aux offres supérieures. Mieux vaut le découvrir maintenant que le jour où votre contrat se termine.
• Ouvrez l'export et vérifiez ce qui manque. Pièces jointes, commentaires, historique, mentions d'utilisateurs et permissions sont les victimes habituelles.
• Confirmez que le remplaçant sait importer ce format. Sinon, prévoyez le temps de conversion. Ce coût ne figure dans aucun chiffre de ce site.
• Listez les intégrations dont vous dépendez. SSO, notifications de messagerie, webhooks, synchronisation d'agenda. Vérifiez que chacune existe pour l'outil auto-hébergé.
• Vérifiez la licence. Plusieurs outils populaires sont en code source disponible plutôt qu'open source, avec des limites sur l'usage commercial. Chaque page outil de ce site le signale.
• Nommez un responsable. Un logiciel auto-hébergé sans personne chargée des mises à jour, c'est la façon la plus courante dont ces projets échouent.

2. Dimensionnement et installation

• Dimensionnez le serveur à partir de la page de coût de l'outil pour votre taille d'équipe, en gardant les 25 % de marge de mémoire. Un serveur dimensionné au plus juste a tendance à tomber lors de sa première montée de version.
• Utilisez le fichier Docker Compose du projet plutôt qu'un fichier tiers, et fixez la version de l'image au lieu d'utiliser latest.
• Placez-le derrière HTTPS, sur son propre sous-domaine, dès le premier jour. Changer l'adresse plus tard casse les liens, les retours OAuth et les applications mobiles.
• Configurez l'e-mail sortant via un service d'envoi transactionnel. Sans cela, les réinitialisations de mot de passe et les notifications échouent sans bruit, et la plupart des outils ne vous préviennent pas.
• Fermez tous les ports sauf 80 et 443, et n'exposez jamais la base de données directement.
• Activez le SSO, ou au minimum la double authentification obligatoire, avant d'inviter qui que ce soit.

3. Des sauvegardes testées

• Sauvegardez à la fois la base de données et les fichiers envoyés. Un dump de base sans le dossier des fichiers restaure un outil rempli de pièces jointes cassées.
• Gardez au moins une copie hors du serveur, chez un autre fournisseur ou dans une autre région que le serveur lui-même.
• Automatisez-les, et soyez alerté en cas d'échec. Une tâche de sauvegarde arrêtée depuis trois semaines, c'est la façon normale de découvrir qu'on n'avait pas de sauvegarde.
• Restaurez-la sur un serveur neuf avant la mise en service. Chronométrez l'opération. Ce chiffre est votre vrai temps de reprise ; tant que vous ne l'avez pas, vous n'avez pas de sauvegardes, seulement des fichiers.

4. La bascule

• Choisissez un jour calme et annoncez un gel des contenus sur l'ancien outil pendant la migration.
• Faites un dernier export après le gel, importez-le, et contrôlez un échantillon d'enregistrements, de pièces jointes et de permissions par rapport à l'ancien outil.
• Faites passer un petit groupe d'abord, pour une semaine de vrai travail, avant tout le monde.
• Redirigez ou mettez à jour les favoris partout où l'ancienne adresse était référencée : documentation, messagerie, navigateurs, applications mobiles.

5. Le plan de retour arrière que la plupart des gens oublient

• Écrivez avant la bascule ce qui vous ferait revenir en arrière. Perte de données, fonction indispensable manquante, pannes à répétition. Fixez le seuil pendant que vous êtes calme.
• Gardez l'ancien abonnement un cycle de facturation de plus après la mise en service, même si cela semble du gaspillage. C'est l'assurance la moins chère que vous achèterez.
• Sachez comment réexporter depuis le nouvel outil vers un format que l'ancien sait lire.
• Ne résiliez l'ancien abonnement qu'une fois un test de restauration réussi, l'équipe entière passée sur le nouvel outil pour du vrai travail, et personne n'ayant réclamé l'ancien.

6. Après la mise en service

• Inscrivez les mises à jour à l'agenda. Ce site prévoit de 0,5 à 3 heures par mois selon l'outil. Ce qui n'est pas planifié n'est pas fait.
• Lisez les notes de version avant chaque mise à jour, surtout pour les versions majeures avec migration de base de données.
• Ajoutez une supervision de disponibilité pour apprendre une panne avant votre équipe.
• Refaites le test de restauration tous les quelques mois.

Avant de commencer

Si vous n'avez pas encore chiffré la migration, vérifiez que l'auto-hébergement fait vraiment économiser de l'argent pour votre taille d'équipe. Pour certains outils, ce n'est pas le cas une fois les heures ci-dessus comptées. Voir tous les comparatifs ou lire comment les coûts sont calculés.