Une date de bascule fixée trop tôt devient une contrainte qui dégrade toutes les autres décisions. Mieux vaut commencer par les critères.
Changer de version majeure d’un BSS, ou migrer vers une nouvelle plateforme, figure parmi les opérations les plus risquées qu’un opérateur puisse entreprendre. Clients, offres, soldes, historiques de facturation : tout doit être transféré sans interruption visible du service.
Commencer par les critères, pas par la date
La tentation est forte d’annoncer une date de bascule dès le lancement du programme. Elle structure le planning, rassure la direction. Mais une date fixée avant que les critères de passage soient définis devient une contrainte qui pousse à réduire les tests, à accepter des écarts, à reporter des corrections. Nous recommandons l’inverse : définir d’abord ce qui doit être vrai pour basculer, puis en déduire une date.
Les répétitions sont le vrai plan
- Migrations à blanc successives sur des volumes réels, chronométrées, avec un rapprochement systématique des données migrées.
- Un plan de retour arrière testé, pas seulement écrit : la décision de revenir en arrière doit pouvoir être prise et exécutée dans la fenêtre prévue.
- Une vérification de service après bascule (VSR) préparée comme un livrable à part entière, avec des parcours clients de référence.
La gouvernance de la nuit de bascule
Le jour J, la question n’est plus technique mais décisionnelle : qui décide de poursuivre ou d’interrompre, sur quels indicateurs, à quelle heure ? Ces points de décision, les fameux go / no-go, se préparent des semaines à l’avance et se répètent comme le reste.
Une migration réussie ressemble souvent à une non-histoire. C’est exactement l’objectif.
Les informations publiées sur ce site sont fournies à titre indicatif et peuvent être modifiées à tout moment. Les publications de la rubrique Publications expriment des analyses générales et ne constituent pas un conseil adapté à une situation particulière.