--- title: Migrer BiBOARD vers un nouveau serveur description: "Une migration d’environnement BiBOARD consiste à **recréer l’environnement BiBOARD sur un nouveau serveur**, puis à y transférer le référentiel et les différentes configurations nécessaires à son fonctionnement. Le principe reste globalement identique quelle que soit la version de BiBOARD. Les…" url: "https://wiki.biboard.fr/wiki/migrer-biboard-vers-un-nouveau-serveur/" updated: "2026-09-07" category: Support --- # Migrer BiBOARD vers un nouveau serveur Une migration d’environnement BiBOARD consiste à **recréer l’environnement BiBOARD sur un nouveau serveur**, puis à y transférer le référentiel et les différentes configurations nécessaires à son fonctionnement. Le principe reste globalement identique quelle que soit la version de BiBOARD. Les prérequis peuvent toutefois varier selon la version installée. L’objectif est généralement de préparer et valider le nouveau serveur **tout en conservant l’ancien environnement disponible**, puis d’effectuer la bascule une fois les contrôles terminés. ## Faire l’inventaire de l’environnement actuel Avant toute intervention, nous conseillons de relever les principaux éléments de configuration de l’environnement existant : - version de BiBOARD ; - version des Addins ; - nom du serveur et de l’instance SQL Server ; - nom de la base contenant le référentiel BiBOARD ; - site IIS, port et type d’authentification ; - compte utilisé par le pool d’applications IIS ; - configuration du service **BiBOARD PowerSystem** ; - ODBC utilisés ; - connexions vers les différentes bases de données ; - chemins réseau et partages utilisés ; - configuration SMTP ; - certificats HTTPS éventuels ; - comptes de service ; - lots actifs et leurs planifications. Il est également conseillé de conserver une copie des différents fichiers de configuration de BiBOARD. ## Sauvegarder l’environnement existant Avant la migration, réaliser au minimum : - une **sauvegarde complète SQL Server** (.bak) du référentiel BiBOARD ; - une sauvegarde des éventuelles bases Datawarehouse utilisées par BiBOARD ; - une sauvegarde des bases utilisées par les composants réalisant des écritures ; - une sauvegarde de l'arborescence BiBOARD existante. Une sauvegarde SQL Server du référentiel doit être réalisée. Un export BiBOARD ne remplace pas une sauvegarde de la base de données. Nous conseillons également de conserver l’ancien serveur disponible jusqu’à validation complète du nouvel environnement. ## Sauvegarder les fichiers personnalisés Certains éléments utilisés par les tableaux de bord ne sont pas nécessairement contenus dans le référentiel SQL Server. Il faut donc rechercher et sauvegarder les fichiers personnalisés présents dans l’arborescence BiBOARD, notamment dans le dossier Web : - images ; - logos ; - fichiers utilisés par les tableaux de bord ; - feuilles de style ; - thèmes personnalisés ; - fichiers HTML ; - scripts éventuels ; - ressources ajoutées manuellement ; - autres fichiers spécifiques à l'installation. Ces éléments devront être replacés sur le nouveau serveur. ## Préparer le nouveau serveur Installer et configurer les prérequis nécessaires à la version de BiBOARD utilisée, consultez la **documentation d'installation correspondant à votre version de BiBOARD** pour les vérifier. Il faut notamment prévoir : - Windows Server ; - IIS ; - les fonctionnalités IIS nécessaires ; - .NET Framework ; - SQL Server si le référentiel est hébergé sur le même serveur ; - les pilotes ODBC nécessaires ; - les éventuels runtimes ou composants requis par ces pilotes. Il faut également vérifier les flux réseau entre le nouveau serveur BiBOARD et : - SQL Server ; - les bases métiers ; - les partages de fichiers ; - les serveurs SMTP ; - les serveurs SFTP ; - les API ou applications externes éventuellement utilisées. ## Installer BiBOARD **⚠️** **Avant de lancer un MSI BiBOARD** Un serveur peut héberger plusieurs instances BiBOARD indépendantes : l'instance standard ainsi que les instances A, B, C, D et E. Avant de lancer un MSI sur un serveur où BiBOARD est déjà installé, vérifiez toujours **la version et l'instance concernées**. Si vous lancez le MSI d'une version supérieure correspondant à une instance déjà installée, le setup **met à jour cette instance** ; il ne crée pas une nouvelle installation en parallèle. **Exemple :** Instance B 18.0.7 + MSI Instance B 18.0.9 → mise à jour de l'instance B en 18.0.9. Cette mise à jour est réalisée **sans retour possible via le setup**. Effectuez donc les sauvegardes nécessaires avant toute mise à jour d'une instance existante. Dans le cadre d'une migration vers un nouveau serveur, l'instance n'étant normalement pas encore présente sur la nouvelle machine, le MSI réalise une nouvelle installation. L'installation de BiBOARD est réalisée à l'aide de deux packages correspondant à la version et à l'instance concernées. Respecter l'ordre suivant : 1. exécuter le **MSI principal BiBOARD** ; 2. suivre l'assistant d'installation et renseigner les paramètres demandés ; 3. terminer l'installation de BiBOARD ; 4. installer ensuite le **MSI des Addins** correspondant à la même version. Les versions de **BiBOARD et des Addins doivent correspondre**. Lors de l'installation principale, l'assistant crée notamment l'environnement Web BiBOARD dans IIS et demande plusieurs informations, par exemple : - le **nom du site Web** ; - le **port** utilisé ; - le **mode de cryptage** ; - les autres paramètres proposés selon la version et le type d'installation. Une fois l'installation terminée, effectuer un premier lancement de BiBOARD afin notamment de récupérer l'**ID du nouveau serveur** nécessaire à la génération de la licence. ## Demander la nouvelle licence La licence BiBOARD est liée au serveur. Le changement de serveur génère donc un **nouvel ID serveur BiBOARD** et nécessite une nouvelle licence. Après l'installation : 1. lancer BiBOARD afin d'obtenir le nouvel **ID serveur** ; 2. relever cet identifiant ; 3. créer une demande sur **support.biboard.fr** ; 4. indiquer l'ID du nouveau serveur et les informations nécessaires concernant l'instance ; 5. mettre en place la licence fournie. ## Restaurer le référentiel BiBOARD Restaurer sur le nouveau SQL Server la sauvegarde .bak du référentiel BiBOARD. Vérifier ensuite : - le nom de la base ; - les comptes SQL utilisés ; - les droits associés ; - les chemins des fichiers SQL ; - la connectivité depuis le serveur BiBOARD. Si le nom du serveur SQL, de l'instance ou du référentiel change, certains éléments de configuration devront être adaptés. Il faut également rechercher les éventuelles références directes à l'ancien nom de serveur ou à l'ancien nom de base. **Désactiver temporairement les lots actifs** Après restauration du référentiel, nous conseillons de **désactiver immédiatement les lots actifs sur le nouvel environnement**. Après une nouvelle installation, le service Windows **BiBOARD PowerSystem** est normalement configuré en **démarrage manuel** et n’est donc pas lancé automatiquement. La désactivation des lots constitue néanmoins une sécurité supplémentaire afin d’éviter leur exécution accidentelle pendant la préparation ou la recette du nouvel environnement. Tant que l’ancien serveur fonctionne encore, un même lot actif sur les deux environnements pourrait être exécuté deux fois. Les lots seront réactivés de manière contrôlée au moment de la mise en production. Voir également la partie **12. Configurer BiBOARD PowerSystem**. ## Recréer les ODBC Installer sur le nouveau serveur les mêmes pilotes que ceux nécessaires à l'environnement actuel, puis recréer les sources ODBC utilisées par BiBOARD. Pour chaque ODBC, vérifier notamment : - le nom du DSN ; - le pilote utilisé ; - le serveur cible ; - le port ; - la base ; - le compte utilisé ; - les paramètres spécifiques du pilote. Tester chaque connexion avant de poursuivre. ## Reprendre la configuration BiBOARD Reprendre les paramètres spécifiques de l'ancien environnement sur le nouveau serveur. Cela peut notamment concerner : - la connexion au référentiel ; - l'authentification ; - le thème ; - les statistiques ; - les chemins de sauvegarde ; - les chemins de fichiers ; - les paramètres SMTP ; - les paramètres de sécurité ; - les paramètres propres à l'installation. En cas de changement de version BiBOARD, il est préférable de repartir des **fichiers de configuration fournis avec la version cible** et d'y reporter les paramètres personnalisés plutôt que de recopier directement un ancien fichier de configuration. ## Vérifier et personnaliser le site Web et IIS **Le MSI principal BiBOARD crée automatiquement le site Web dans IIS** à partir des informations renseignées pendant l'installation, notamment le nom du site, le port et le mode de cryptage. Après l'installation, cette configuration peut toutefois devoir être complétée ou adaptée à l'environnement. **Configuration HTTPS et certificat SSL** Si le portail doit être publié en HTTPS : - installer ou importer le certificat SSL sur le nouveau serveur ; - ajouter ou modifier la liaison HTTPS du site IIS ; - sélectionner le certificat correspondant ; - vérifier le port utilisé, généralement 443 ; - vérifier le nom DNS utilisé par les utilisateurs. Il est également nécessaire de vérifier que les éventuels flux réseau ou règles de pare-feu autorisent l'accès au nouveau serveur. **Authentification** Selon la configuration utilisée, il peut être nécessaire d'adapter le mode d'authentification du site IIS. Par exemple : - authentification Windows ; - authentification anonyme ; - ou les paramètres nécessaires à un système d'authentification spécifique utilisé par l'environnement. La configuration doit être reprise en fonction de l'environnement BiBOARD existant et du mode d'accès souhaité sur le nouveau serveur. **Pool d'applications** Vérifier également les paramètres du pool d'applications associé au site BiBOARD, notamment : - le compte utilisé ; - les droits de ce compte ; - ses accès aux ressources réseau ; - les éventuels paramètres IIS personnalisés de l'ancien environnement. **Règles et personnalisations IIS** Certaines installations disposent de réglages IIS spécifiques qu'il faudra également reprendre, par exemple : - règles de réécriture ; - redirections HTTP/HTTPS ; - restrictions d'accès ; - en-têtes HTTP particuliers ; - paramètres d'authentification ; - limites ou paramètres spécifiques du site ; - configuration particulière du pool d'applications. Il est donc conseillé de **comparer la configuration IIS de l'ancien et du nouveau serveur** après l'installation. ## Reprendre les fichiers personnalisés Recopier sur le nouveau serveur les fichiers personnalisés sauvegardés précédemment. Vérifier ensuite que les tableaux de bord retrouvent correctement : - les images ; - les logos ; - les documents ; - les fichiers ; - les thèmes ; - les différentes ressources externes. **Attention aux chemins absolus** Le changement de serveur peut révéler des liens ou chemins qui avaient été enregistrés avec l'ancien nom du serveur ou un chemin local spécifique. Lorsque cela est possible, nous conseillons d'utiliser des **chemins relatifs** afin de faciliter les futures migrations. ## Configurer BiBOARD PowerSystem Reprendre la configuration du service **BiBOARD PowerSystem** en fonction de l’environnement existant : - compte utilisé par le service Windows ; - paramètres PowerSystem ; - chemins utilisés ; - accès aux ressources réseau ; - droits du compte de service ; - éventuels paramètres particuliers. Après avoir vérifié cette configuration : 1. vérifier que les lots du nouvel environnement devant rester neutralisés sont bien **désactivés** 2. démarrer le service Windows **BiBOARD PowerSystem** 3. vérifier que le service démarre correctement 4. configurer son **type de démarrage sur Automatique** afin qu’il soit relancé avec le serveur. **Attention à la double exécution des lots** Une attention particulière doit être portée aux lots lorsque l’ancien serveur et le nouveau serveur fonctionnent simultanément. Dès que le service **BiBOARD PowerSystem** est démarré sur le nouveau serveur, tout lot actif et planifié peut également s’y exécuter. Il pourrait alors y avoir : **Ancien serveur + nouveau serveur = deux exécutions du même traitement.** C’est pourquoi nous conseillons de **désactiver les lots sur le nouvel environnement dès la restauration du référentiel**, puis de les réactiver progressivement lors de la bascule. Une vigilance particulière est nécessaire pour les lots qui : - envoient des mails ; - génèrent, copient ou déplacent des fichiers ; - effectuent des imports ou des exports ; - déclenchent des traitements externes ; - alimentent ou modifient des bases de données. **Lots Datawarehouse en mode AJOUT** Les lots Datawarehouse fonctionnant en mode **AJOUT** doivent faire l’objet d’une attention particulière. À chaque exécution, ils peuvent **ajouter de nouvelles lignes dans les tables cibles**. Une exécution accidentelle ou une double exécution depuis l’ancien et le nouveau serveur peut donc créer des données supplémentaires qu’il peut ensuite être difficile d’identifier et de supprimer. Ces lots doivent rester désactivés pendant la phase de préparation et de recette, puis être **réactivés de manière contrôlée lors de la mise en production**. ## Tester le nouvel environnement Avant la mise en production, effectuer une recette du nouvel environnement. Nous conseillons de vérifier au minimum : - l'accès au portail Web ; - l'authentification des utilisateurs ; - les principales connexions ; - les ODBC ; - les principales requêtes ; - les Datasources ; - les principaux tableaux de bord ; - les images et ressources personnalisées ; - les exports ; - les envois de mails ; - les accès aux fichiers et partages réseau ; - les fonctionnalités utilisant des systèmes externes. Faire également vérifier les principaux tableaux de bord par quelques utilisateurs représentatifs. Les lots automatiques peuvent rester désactivés durant cette phase. ## Préparer la mise en production Entre le début des tests et la mise en production, le référentiel de production peut continuer à évoluer. Des utilisateurs peuvent par exemple : - modifier un tableau de bord ; - créer une requête ; - modifier une Datasource ; - modifier des droits ; - créer ou modifier un lot. Il faut donc définir comment seront reprises ces modifications. Pour une migration préparée plusieurs jours ou semaines à l'avance, une méthode courante consiste à : 1. effectuer une première restauration du référentiel pour préparer et tester le nouveau serveur ; 2. effectuer la recette ; 3. définir une période de gel des modifications ; 4. réaliser une nouvelle sauvegarde du référentiel de production ; 5. restaurer cette sauvegarde sur le nouveau serveur ; 6. effectuer les derniers contrôles ; 7. basculer les utilisateurs. Toute modification réalisée uniquement sur l'environnement de recette doit pouvoir être identifiée et reproduite après cette restauration finale. ## Effectuer la bascule Une fois le nouvel environnement validé : 1. effectuer si nécessaire la dernière sauvegarde du référentiel ; 2. restaurer la version définitive sur le nouveau serveur ; 3. effectuer les derniers contrôles ; 4. basculer l'URL ou le DNS vers le nouveau serveur ; 5. arrêter ou neutraliser PowerSystem sur l'ancien environnement ; 6. réactiver progressivement les lots sur le nouveau serveur ; 7. contrôler leurs premières exécutions. Pour les traitements sensibles, il est conseillé de vérifier leur première exécution individuellement. ## Conserver temporairement l'ancien environnement Il n'est généralement pas nécessaire de supprimer immédiatement l'ancien serveur. Nous conseillons de le conserver quelque temps arrêté (ou avec les services BiBOARD neutralisés). Cela permet de disposer d'un environnement de référence et facilite un éventuel retour arrière. Une fois le nouvel environnement considéré comme stable, l'ancien serveur pourra être décommissionné selon vos procédures habituelles. ## **Besoin d'accompagnement ?** Cette procédure permet de réaliser une migration d'environnement BiBOARD de manière autonome. Selon l'environnement concerné, certaines migrations peuvent toutefois nécessiter la reprise de nombreux ODBC, accès réseau, configurations spécifiques ou traitements automatiques. **Si vous souhaitez que nous réalisions la migration avec vous ou que nous vous accompagnions uniquement sur certaines étapes, vous pouvez nous contacter ou créer un ticket sur notre support.** Nous pourrons définir ensemble le niveau d'accompagnement adapté à votre environnement.