Checklist migration SaaS : 5 étapes pour décider

La majorité des ressources sur le self-hosting répondent à la question « comment migrer » en supposant que la décision est déjà prise. Or, les équipes qui ont commencé par le « comment » sans avoir résolu le « quoi » et le « pourquoi » se retrouvent souvent avec trois outils self-hostés qui tournent bien — et aucune économie réelle, parce qu'ils n'ont pas migrés les postes de dépenses les plus lourds.

Une agence gère rarement un seul SaaS. Elle gère un portefeuille : CRM, gestion de projet, messagerie, stockage, mots de passe, analytics, formulaires, facturation. La décision de migrer un outil ne se prend pas isolément — elle dépend de ce que l'outil coûte vraiment (abonnement, intégrations, formation), de ce qu'il faudrait pour le remplacer (compétences, temps, serveur), et de l'ordre dans lequel les migrations ont du sens.

Cette checklist est un méta-guide : elle ne documente pas les étapes de déploiement d'un outil spécifique, elle vous aide à construire votre propre plan de migration, outil par outil, avec une méthode reproductible.

Avant toute décision, cartographiez l'existant. L'exercice prend moins d'une heure et révèle souvent des surprises : des abonnements actifs dont personne ne sait qui les utilise, des outils qui facturent par siège alors que la moitié des comptes sont inactifs, des doublons fonctionnels.

Le coût à mesurer n'est pas seulement le coût direct (la ligne sur la carte bancaire). C'est le coût total : abonnement mensuel ou annuel × nombre de sièges × 12, auquel s'ajoute le coût d'intégration (connecteurs, APIs tierces payantes, modules complémentaires) et le coût de dépendance (combien d'autres outils cessent de fonctionner si cet outil disparaît).

Ce dernier critère — la dépendance — est le plus important pour décider de l'ordre des migrations. Un outil central, branché à dix autres, coûte souvent moins à conserver qu'à migrer.

Une fois l'inventaire dressé, identifiez les candidats à la migration : les outils dont le coût annuel dépasse significativement ce que coûterait un VPS pour les faire tourner. Ce n'est pas une règle absolue — un outil critique à faible coût peut rester en SaaS sans que personne ne remette la décision en question.

Pour chaque candidat, le calcul du ROI réel comporte quatre lignes. La première : le coût SaaS actuel annuel. La deuxième : le coût infrastructure (VPS ou portion d'un VPS existant, selon la RAM et le CPU requis par l'outil). La troisième : le coût de migration initiale (temps de déploiement, de migration des données, de formation de l'équipe, estimé honnêtement en heures × coût horaire). La quatrième : le coût de maintenance récurrente annuelle (mises à jour, sauvegardes, surveillance).

Le point mort se calcule : coût migration initiale ÷ (coût SaaS annuel − coût infra annuel − coût maintenance annuelle). Si ce point mort dépasse 24 mois, la migration n'est rentable que dans un horizon long terme — ce qui est valable pour un outil stratégique, mais questionnable pour un outil périphérique.

Attention à ne pas sous-estimer la maintenance. Un outil self-hébergé qui reçoit des correctifs de sécurité fréquents consomme du temps réel, même si ce temps est faible par incident. Documentez une estimation honnête avant de valider le ROI.

L'ordre dans lequel vous migrez vos outils a autant d'importance que le choix des outils à migrer. Une erreur courante consiste à commencer par l'outil qui économise le moins (parce qu'il est techniquement plus simple) ou par l'outil le plus complexe (par ambition).

L'ordre rationnel suit deux règles. D'abord, commencez par les outils à ROI rapide et faibles dépendances : ceux dont la migration prend moins d'une journée, qui ne sont pas branchés à d'autres outils critiques, et dont l'économie est immédiate. Ces premières migrations permettent à l'équipe de monter en compétence sur les opérations courantes (déploiement, sauvegardes, mises à jour) sur des outils à faible risque. Ensuite, attaquez les outils à fort enjeu économique uniquement quand les processus opérationnels sont rodés.

La règle de séquençage la plus simple : commencez par les outils dont la migration est réversible (retour au SaaS possible si la migration échoue), avant les outils où le retour arrière est coûteux ou impossible.

Une migration réussie ne commence pas par le déploiement de l'outil, mais par la préparation de l'infrastructure qui va l'accueillir. Migrer chaque outil sur un VPS dédié n'est pas toujours la solution la plus économique : un VPS correctement dimensionné peut héberger plusieurs outils à la fois, à condition que leurs besoins en RAM et CPU soient compatibles.

La préparation de l'infrastructure couvre quatre domaines. D'abord, le dimensionnement du serveur : chaque outil publie ses prérequis en RAM et CPU, additionnez-les et ajoutez une marge de 30 % pour les pics. Ensuite, le durcissement de base : pare-feu, mises à jour automatiques de sécurité, accès SSH par clé uniquement. Puis la stratégie de sauvegarde : des sauvegardes automatiques quotidiennes vers un emplacement distinct du serveur de production. Enfin, la supervision : une alerte en cas d'indisponibilité et une vérification régulière des mises à jour de sécurité.

Ces quatre domaines sont des prérequis, pas des options. Un outil self-hébergé sans sauvegarde testée n'est pas une alternative à un SaaS — c'est un SaaS sans garantie de service.

La migration n'est terminée que lorsque trois conditions sont réunies : l'équipe utilise l'outil self-hébergé au quotidien depuis au moins une semaine sans problème bloquant, les sauvegardes ont été testées avec une restauration réelle (pas seulement vérifiées dans les logs), et la documentation de maintenance est rédigée et connue du responsable technique.

Seulement alors, résiliez l'abonnement SaaS. Pas avant. Cette règle est la protection contre les migrations précipitées qui se terminent par un retour d'urgence au SaaS, parfois avec des données perdues dans l'intervalle.

Documentez également les décisions prises pour chaque outil : pourquoi vous avez migré, quel était le coût avant, quelles sont les procédures de maintenance. Cette documentation est utile si un nouveau membre de l'équipe doit reprendre la gestion de l'infrastructure, et elle permet de mesurer le ROI réel après six mois d'exploitation.

Cette checklist couvre la décision et le séquençage. Elle ne remplace pas les guides de migration spécifiques à chaque outil, qui documentent les étapes techniques de déploiement, la migration des données et les erreurs courantes. Pour chaque outil retenu dans votre plan de migration, un guide dédié existe : migration de gestionnaire de mots de passe vers Vaultwarden, migration d'un CRM vers Twenty CRM, migration d'une suite bureautique vers Nextcloud, et d'autres encore.

La checklist est aussi une aide à la décision, pas une garantie. Certains outils semblent candidats à la migration selon tous les critères et se révèlent difficiles à maintenir dans votre contexte spécifique. D'autres semblent complexes et se déploient en quelques heures. Les estimations données ici sont des ordres de grandeur, pas des promesses.

Enfin, cette checklist ne traite pas de la gestion multi-clients : si vous êtes une agence qui héberge l'infrastructure de vos clients plutôt que la vôtre, les contraintes sont différentes — isolation entre clients, gestion des accès, facturation de la prestation, responsabilité contractuelle. Ces aspects relèvent d'une architecture multi-tenant, au-delà du périmètre de ce guide.

Si vous lisez cet article avec un tableau de SaaS ouvert dans un autre onglet, voici les premières actions concrètes : réalisez l'inventaire de coût total sur une heure, identifiez le ou deux candidats à ROI rapide et faibles dépendances, et préparez un VPS de qualification avant de déployer quoi que ce soit en production.

Pour les agences qui gèrent l'infrastructure de plusieurs clients, centraliser la gestion des domaines, des hébergements et des VPS sur une seule plateforme avant d'entamer les migrations simplifie considérablement les opérations : vous savez ce qui tourne où, et vous pouvez allouer des ressources à chaque client sans jongler entre des panneaux d'administration disparates.

Le self-hosting est un investissement, pas une économie immédiate. La checklist sert précisément à distinguer les migrations qui rentrent rapidement de celles qui demandent un horizon plus long — pour que chaque décision soit une décision, et non une réaction à une facture.