La migration téléphonie consiste à remplacer ou moderniser un PBX ou un SVI (serveur vocal interactif) arrivé en fin de vie, sans perturber l’activité. Matériel propriétaire qui n’est plus supporté, lignes TDM ou RNIS en cours d’abandon, licences coûteuses, SVI impossible à modifier sans l’éditeur : les raisons sont nombreuses, mais le risque est toujours le même, celui de couper les appels.
Voxivra mène ces migrations avec une approche progressive : l’ancien et le nouveau système cohabitent, les flux basculent un par un, et chaque étape dispose d’un plan de retour.
Quand envisager une migration
- Fin de support du PBX ou du SVI, ou pièces de rechange difficiles à trouver.
- Abandon des lignes analogiques, TDM ou RNIS par l’opérateur, qui impose de passer au SIP.
- SVI figé : chaque modification de menu demande l’intervention de l’éditeur, avec délais et coûts.
- Besoin d’intégration avec le CRM, d’un voicebot ou d’analyses d’appels que l’ancien système ne permet pas.
- Consolidation multisite : plusieurs PBX hétérogènes à réunir sous une même architecture.
Ce que nous migrons
- PBX propriétaires vers Asterisk ou FreePBX, sur serveurs, machines virtuelles ou cloud.
- SVI et serveurs vocaux existants, reconstruits avec un SVI sur mesure plus simple à faire évoluer.
- Raccordements opérateurs vers des trunks SIP, avec portabilité des numéros.
- Applications vocales maison (scripts, anciennes interfaces de téléphonie) vers AGI ou Asterisk ARI.
- Anciennes versions d’Asterisk vers une version maintenue, avec passage de chan_sip à PJSIP.
Notre méthode de migration sans interruption
1. Audit de l’existant
Nous documentons tout ce que fait réellement le système actuel : numéros, plans de numérotation, règles horaires, files, menus, messages, enregistrements, intégrations, postes et terminaux. Cette étape révèle souvent des règles oubliées que personne n’a documentées, mais dont dépendent des équipes.
2. Architecture cible
Nous définissons la plateforme cible : Asterisk et PJSIP pour le cœur, éventuellement un proxy SIP (Kamailio ou OpenSIPS) pour la répartition, redondance adaptée à votre criticité, chiffrement TLS/SRTP et protection contre la fraude téléphonique.
3. Cohabitation
Le nouveau système est interconnecté en SIP à l’ancien. Les deux fonctionnent en parallèle : on peut ainsi router un numéro, une file ou un site vers la nouvelle plateforme pendant que le reste continue sur l’ancienne.
4. Bascule progressive
Nous commençons par un flux à faible risque, observons, corrigeons, puis étendons. Chaque bascule est planifiée, testée avec des appels réels et accompagnée d’une procédure de retour arrière documentée.
5. Décommissionnement
Une fois tous les flux migrés et stables, l’ancien système est arrêté, après vérification des archives à conserver (enregistrements, journaux d’appels).
Nous détaillons cette démarche, côté SVI, dans notre article Moderniser un SVI existant.
Les risques d’une migration et comment nous les maîtrisons
- Comportements non documentés : une règle de jour férié, un renvoi caché, une ligne de télécopie oubliée. L’audit et la période de cohabitation servent précisément à les repérer avant la bascule.
- Délais de portabilité : chaque opérateur a ses délais, et une demande refusée peut décaler une date. Nous lançons les démarches tôt et ne planifions jamais une bascule qui dépend d’une portabilité non confirmée.
- Préparation du réseau : SIP et RTP sont sensibles aux pare-feu, au NAT et à la bande passante. Nous validons le chemin réseau, la qualité de service et les codecs avant tout trafic réel.
- Compatibilité des terminaux : certains postes anciens ou équipements analogiques ne s’enregistrent pas sur une plateforme moderne. Nous les recensons tôt pour prévoir remplacement ou adaptateurs.
- Accompagnement des équipes : de courts guides par rôle valent mieux qu’un long manuel.
- Sécurité dès le premier jour : une plateforme SIP exposée est sondée en quelques heures. Protection anti-fraude et contrôles d’accès sont en place avant la première bascule.
Comment se déroule un projet
| Phase | Contenu | Livrable |
|---|---|---|
| Audit | inventaire technique et fonctionnel | cartographie de l’existant |
| Conception | architecture cible, plan de migration | dossier d’architecture, planning |
| Construction | installation, reconstruction des flux, tests | plateforme en préproduction |
| Bascule | migration flux par flux | procès-verbaux de bascule |
| Stabilisation | suivi rapproché, corrections | documentation d’exploitation |
La durée dépend du nombre de sites, de numéros, de flux et d’intégrations, ainsi que des délais des opérateurs pour la portabilité. Nous la chiffrons après l’audit.
À quoi vous attendre et prérequis
Ce que vous obtenez : une plateforme ouverte, documentée et maintenue, sans dépendance à un éditeur pour chaque modification, et prête pour l’automatisation et l’IA vocale.
Prérequis :
- un accès administrateur à l’ancien système, ou au minimum ses exports de configuration ;
- les contrats et coordonnées de vos opérateurs, pour planifier la portabilité ;
- la liste des intégrations existantes (CRM, enregistrement, supervision) ;
- des fenêtres de bascule convenues avec les équipes métier ;
- un interlocuteur capable de valider chaque flux migré.
Pour les organisations qui ne peuvent tolérer aucune interruption, comme les services publics, nous intégrons dès la conception les exigences de haute disponibilité et un support renforcé pendant la bascule.