Migrez vers le cloud en limitant les interruptions
Migrez votre infrastructure vers le cloud avec un plan clair, en limitant les coupures.
Ce qui casse quand deux systèmes écrivent en même temps
La bascule est annoncée pour un week-end, la copie se termine dans la nuit, et le lundi matin une partie des salariés travaille sur la nouvelle plateforme pendant que l'autre écrit encore dans l'ancienne, parce que son fournisseur d'accès conserve en mémoire l'ancienne adresse. Rien ne se voit tant que les deux systèmes répondent : la divergence se découvre le mardi, quand il faut réconcilier à la main deux versions du même dossier.
Le second symptôme est plus discret. Le plan décrit les serveurs à déplacer, mais il ne dit rien du copieur qui numérise vers un partage précis, de la licence attachée à l'identifiant matériel de l'ancienne machine, ni du partenaire qui a inscrit une adresse IP en dur dans sa configuration. Ces dépendances se révèlent pendant la coupure, au moment exact où la seule option restante consiste à terminer coûte que coûte.
Ce que nous prenons en charge, de l'inventaire à la fermeture
Nous commençons par un audit d'une à trois semaines selon la taille du système d'information. Il produit l'inventaire des applications et des données, la cartographie des flux, la liste des comptes à privilèges, la perte de données et le délai de retour acceptés par la direction, et la liste de ce qui ne migrera pas. Un environnement dont le compte principal appartient à un indépendant parti depuis deux ans n'est pas une cible de migration, c'est d'abord un chantier d'identités.
Vient ensuite l'exécution, vague par vague, du moins risqué vers le plus critique, avec des critères de réussite écrits avant chaque étape. Nous préparons le DNS une semaine à l'avance, nous conservons l'ancien environnement intact et éteint plusieurs jours, et nous laissons une documentation utilisable par votre support. Nos missions se déroulent en France et en Suisse, à distance, avec un déplacement quand le dossier le justifie.
Ce que couvre une mission de migration, étape par étape
- Nous produisons l'inventaire des applications, des données et des flux réseau, avec la liste explicite de ce qui ne migrera pas.
- Nous relevons les comptes à privilèges et remettons la propriété du compte fournisseur au nom de votre entreprise.
- Nous fixons avec la direction la perte de données et le délai de retour acceptés, puis nous dimensionnons l'architecture cible.
- Nous décrivons le réseau, les droits et le stockage dans des fichiers versionnés, pour une plateforme reproductible et reprenable.
- Nous exécutons la bascule par vagues, avec une préparation du DNS, des critères de réussite écrits et un repli daté.
- Nous contrôlons après chaque vague les traitements de nuit, les impressions, les temps de réponse et la première sauvegarde.
- Nous remettons une documentation d'exploitation, puis nous proposons un run ou un transfert de compétences.
Les trois décisions qui font la différence le lundi matin
L'ancien environnement passe en lecture seule
Avant la copie finale, les partages sont démontés et les tâches planifiées de nuit désactivées explicitement. La fenêtre pendant laquelle deux systèmes acceptent des écritures est supprimée, pas seulement surveillée.
Le TTL du DNS s'abaisse une semaine avant
Un enregistrement dont la durée de vie est réglée à vingt-quatre heures envoie une partie de vos utilisateurs vers l'ancien serveur pendant une journée entière. Nous abaissons cette valeur avant la bascule, puis nous la remontons.
Le repli est écrit avant, jamais improvisé pendant
La procédure indique qui décide de l'abandon, à quelle heure au plus tard, dans quel ordre les services repartent et ce que deviennent les données saisies entre-temps. C'est ce dernier point que les plans oublient.
Une bascule par lots, pas un week-end héroïque
Nous cartographions dépendances, DNS et données, puis nous migrons par vagues avec un repli possible. Le TJM de 1000 HT couvre le conseil et l'exécution, pas un forfait miracle annoncé avant l'audit.
Outils et délai
Audit 1 à 3 semaines, bascule selon le volume de données.
Comment se conduit une bascule que vos utilisateurs ne remarquent pas
Une migration se juge sur la période pendant laquelle deux systèmes peuvent recevoir des écritures, pas sur la vitesse de la copie. Nous fixons donc deux valeurs avec la direction : la perte de données acceptable si la dernière copie utilisable date de la veille au soir, et le délai au bout duquel le service doit être revenu. Elles relèvent du métier, car une fiduciaire en période de bouclement et un atelier qui facture en fin de mois n'ont pas la même tolérance. Nous les posons comme dans un plan de sauvegarde et de reprise d'activité.
La deuxième décision se prend avant le premier transfert : reprenez-vous la machine telle quelle, ou redécoupez-vous l'application pour la confier à des services gérés par le fournisseur. Un cran intermédiaire existe, souvent le plus utile : la machine part sans être réécrite, mais la base de données passe en service managé, les sauvegardes sortent du serveur et le réseau est refait proprement. Nous instruisons ce choix application par application dans notre article comparant la reprise telle quelle et la refonte, car un même système d'information mélange presque toujours les trois approches.
Nous traitons la fenêtre de double écriture comme un risque à supprimer. L'ancien environnement passe en lecture seule avant la copie finale, l'accès applicatif est bloqué au niveau du réseau et les traitements de nuit sont désactivés un par un : un travail automatique oublié fait le même dégât qu'un utilisateur resté du mauvais côté. Le découpage en vagues suit la même logique, la production venant en dernier et le changement de DNS parmi les toutes dernières étapes, comme nous le détaillons dans notre article sur la migration sans couper l'activité.
Ce que nous automatisons, c'est la description de la plateforme cible : réseau, droits, stockage, règles de filtrage et étiquetage sont écrits dans des fichiers plutôt que cliqués dans une console, méthode expliquée dans notre article sur Terraform et Ansible. L'environnement devient lisible et transmissible à un autre prestataire. Ce qui reste manuel ne se délègue à aucun outil : la décision de basculer ou de replier, l'appel aux partenaires qui pointent vers une adresse fixe, et la validation métier de chaque vague par des utilisateurs désignés.
Une machine reprise telle quelle tourne en continu et se paie tous les mois, là où le serveur du local technique était un investissement amorti : la discipline de suivi des dépenses s'ouvre donc dès le premier jour, sujet de notre article sur une facture cloud qui augmente. Il nous arrive aussi de conseiller de ne pas migrer, car une entreprise de moins de trente personnes obtient souvent un meilleur résultat avec un hyperviseur bien tenu, comme l'explique notre article sur le serveur d'une PME. L'exploitation courante se traite ensuite en maintenance cloud.
Les erreurs de plan que nous corrigeons le plus souvent
-
Tout basculer en une seule nuit
La bascule globale d'un week-end suppose un inventaire parfait du système d'information, et nous n'en avons jamais rencontré. Il reste toujours un automate ou une licence matérielle qui se révèle pendant la coupure.
-
Découvrir le DNS le jour de la bascule
La durée de vie des enregistrements ne se règle pas au moment de la modification, elle se prépare une semaine avant. Sinon une partie de vos utilisateurs continue de travailler sur l'ancien serveur sans le savoir.
-
Supprimer l'ancien environnement trop vite
Effacer la source dans la foulée pour alléger la facture d'hébergement est une fausse économie. Nous la conservons intacte plusieurs jours, le temps que les usages réels révèlent ce qui a été oublié.
De l'inventaire à la fermeture de l'ancien environnement
-
Audit et cartographie
1 à 2 jours
-
Architecture cible
sous 7 jours
-
Migration par lots
selon le périmètre
-
Validation et documentation
48 h
Les trois situations qui déclenchent l'appel
Nous intervenons pour des entreprises dont le serveur arrive en fin de garantie, pour celles dont l'application doit rester joignable depuis plusieurs sites ou en télétravail, et pour celles à qui un client impose par écrit une exigence de continuité ou de localisation. Nous reprenons aussi des migrations laissées à mi-chemin par un autre prestataire, avec deux environnements en parallèle et personne pour trancher.
Zone d'intervention
Migrations pour des SI dont les utilisateurs sont à Genève ou en France, avec hébergement cible en Suisse quand la souveraineté l'impose.
Ce que disent nos clients
Des PME et des indépendants du Bassin Genevois, suivis dans la durée.
« Très satisfait du site création paysage, merci à Mickael de sa disponibilité et de son professionnalisme, service au top. »
« Service au top, je recommande à 1000%. »
« Mickael est super pro et très compétent. »
Questions fréquentes
Une migration sans aucune interruption est-elle possible ?
Elle suppose une application conçue pour tourner en deux endroits à la fois, avec une base répliquée et un basculement automatique, ce qui n'est presque jamais le cas d'une application métier de PME. L'objectif réaliste est une interruption courte, annoncée à l'avance, encadrée et réversible. Nous vous le disons avant de signer.
Vers quelles plateformes migrez-vous ?
Vers AWS, Microsoft Azure, Google Cloud et OpenStack, y compris vers un cloud privé lorsque la localisation des données est une exigence écrite. Le choix se fait après l'audit, à partir de vos contraintes et des compétences disponibles chez vous, pas d'une préférence de notre part.
Combien de temps dure une migration complète ?
L'audit prend d'une à trois semaines selon la taille du système d'information. L'exécution dépend ensuite du volume de données, du nombre d'applications et du nombre de vagues. Nous cadrons la durée à la fin de l'audit plutôt que d'annoncer un délai avant d'avoir vu votre existant.
Que se passe-t-il si la bascule se passe mal ?
Le plan de repli est écrit et daté avant l'opération : il indique qui prononce l'abandon, à quelle heure au plus tard, dans quel ordre les services repartent et ce que deviennent les données saisies entre-temps. L'ancien environnement reste intact et éteint plusieurs jours, ce qui rend le retour arrière possible.
Comment cette prestation est-elle facturée ?
Au taux journalier de 1000 HT. La trajectoire est chiffrée en journées à l'issue de l'audit, application par application. Une fois la plateforme stabilisée, un forfait de run se discute pour sortir du décompte au jour le jour.
Les autres prestations expertise cloud
Réalisations liées
Un projet, une panne, un rendez-vous.
Choisissez un créneau, ou décrivez votre besoin : nous répondons avec un périmètre clair, un prix hors taxes, et un interlocuteur nommé.