Migration

Oui. La migration assistée est incluse sur les plans Business et Pro : notre équipe transfère votre site sans interruption de service.

Oui. L'assistant de migration vous laisse regrouper le transfert de vos domaines (par code EPP) et de vos comptes cPanel en UNE seule commande guidée — idéal pour rapatrier tout un portefeuille. Pour chaque hébergement, choisissez la méthode : un lien de sauvegarde (.tar.gz) ou un transfert direct depuis votre ancien cPanel (avec vos identifiants, utilisés en vol et jamais enregistrés).

Non. Nous préparons le transfert sur nos serveurs puis basculons le DNS une fois tout vérifié, pour une transition sans coupure perceptible.

Nous transférons vos fichiers, vos bases de données et vos comptes email afin de reconstituer votre environnement à l'identique.

Une migration prend généralement de 24 à 72 heures selon la taille du site, propagation DNS comprise. Vous en suivez l'avancement dans votre espace client (journal du service concerné), et nous vous tenons informé à chaque étape.

Oui, nous prenons en charge la migration depuis la plupart des hébergeurs, en particulier ceux utilisant cPanel.

Elle est incluse sur les plans Business et Pro. Pour les autres cas, une prestation de migration assistée est proposée en option.

Oui, un changement d'IP d'envoi nécessite une phase de chauffe : commencez par de petits volumes (50 à 100 e-mails par jour la première semaine) pour bâtir progressivement la réputation de la nouvelle IP. Assurez-vous que SPF, DKIM et DMARC sont configurés correctement sur le nouveau serveur dès le premier envoi, puis surveillez les rapports DMARC pendant 2 à 4 semaines pour détecter toute anomalie. Notre équipe support est disponible à [email protected] pour vous accompagner.

La migration se déroule en quatre étapes : exportez vos images et volumes (`docker save`, `rsync` des données), préparez le VPS cible en installant Docker et en configurant vos variables d'environnement, transférez les données et démarrez les conteneurs, puis basculez le DNS uniquement après avoir validé le bon fonctionnement sur la cible. Pour les applications sensibles au temps d'arrêt, maintenez l'ancien serveur actif jusqu'à la propagation complète du DNS. Si vous avez besoin d'assistance, ouvrez un ticket depuis votre espace client.

WHM intègre un outil natif appelé Transfer Tool (Packages > Transfer Tool) qui permet de migrer l'ensemble des comptes cPanel d'un serveur WHM source vers votre nouveau serveur ServOrbit, en incluant les fichiers, les bases de données MySQL, les e-mails et les zones DNS. Vous renseignez l'adresse IP ou le hostname du WHM source, les identifiants root ou un token API, puis sélectionnez les comptes à transférer. La durée de migration dépend du volume total de données : comptez entre 30 minutes et plusieurs heures pour un revendeur de grande taille. Il est recommandé de laisser les DNS pointer vers l'ancien serveur pendant la migration, puis de les basculer une fois la vérification terminée pour minimiser l'interruption.

Exportez votre base avec `pg_dump`, transférez le fichier via `rsync` ou `scp` vers votre VPS ServOrbit, puis restaurez avec `pg_restore` ou `psql`. Vérifiez les versions de PostgreSQL avant la migration pour éviter les incompatibilités, et testez la connexion de votre application avant de basculer le DNS. Notre équipe support peut vous accompagner si vous rencontrez un blocage.

Oui. Ces forges Git sont des applications standard qui s'installent sur n'importe quel VPS Linux. Sauvegardez vos données (dépôts, configuration, base de données), transférez-les sur votre VPS ServOrbit, puis relancez l'application — la procédure est identique à une migration de serveur classique. Notre blog propose des guides détaillés pas à pas pour les principales forges.

Avant de migrer, exportez tous vos workflows depuis l'interface n8n (menu Settings → Import/Export) et notez vos variables d'environnement (clé de chiffrement, identifiants DB). Arrêtez le processus npm, installez Docker et Docker Compose sur votre VPS, puis utilisez la recette officielle n8n Docker en montant le même répertoire de données (~/.n8n) dans le volume du conteneur pour conserver vos workflows et credentials. La migration vers Docker est recommandée par l'équipe n8n avant la v3.0, qui abandonne le support de l'installation globale npm ; notre support peut vous accompagner via [email protected].

Oui, Docker v29 introduit plusieurs ruptures de compatibilité à anticiper : le réseau bridge par défaut a évolué, certaines options de `docker run` dépréciées depuis la v24 ont été supprimées, et le format des manifestes multi-arch a changé. Avant la migration, auditez vos `docker-compose.yml` et Dockerfiles pour repérer les options obsolètes, testez dans un environnement de qualification, puis basculez. Notre article de blog sur la migration Docker v29 détaille les étapes de vérification.

La procédure consiste à sauvegarder vos flux LangFlow (export JSON depuis l'interface) et vos modèles Ollama (dossier `~/.ollama/models`), puis à les transférer vers le nouveau VPS via `rsync` ou `scp`. Après réinstallation des services sur le nouveau VPS, réimportez vos flux et vérifiez les variables d'environnement (clés API, URLs). Prévoyez une fenêtre de maintenance courte pour le basculement DNS afin d'éviter toute interruption.

La migration depuis Oracle Cloud vers un VPS ServOrbit suit un schéma simple : exportez vos images Docker avec `docker save`, transférez-les via SSH ou un registre privé, puis recréez vos services avec vos fichiers `docker-compose.yml` existants. Pour les données persistantes, copiez vos volumes avec `rsync` ou `docker cp`. Il est conseillé de tester la configuration sur le nouveau serveur avant de couper le DNS, en conservant un TTL court (300 secondes) pour limiter la fenêtre de bascule. ServOrbit propose des VPS sous Debian ou Ubuntu, compatibles avec toutes les distributions d'images Docker standard. Un accès SSH root est disponible dès l'activation du serveur.

Oui, Mattermost propose un outil d'import natif compatible avec le format d'export Slack. La procédure consiste à exporter vos données depuis Slack (format ZIP fourni par leur interface d'administration), puis à les convertir et importer via la commande `mattermost import slack` ou l'outil `mmetl`. Les messages, canaux publics et pièces jointes sont généralement récupérés. Les messages directs et certains emojis personnalisés peuvent nécessiter un traitement supplémentaire selon la version. Il est recommandé d'effectuer un import de test sur une instance vierge avant la bascule définitive. L'opération se réalise entièrement depuis votre VPS ServOrbit, sans dépendance à un service tiers.

‎OpenProject dispose d'un ‎Jira ‎Migrator officiel disponible depuis la version 17.4 (bêta publiée en mai 2026). Il migre les projets, les ‎issues (titre, description, pièces jointes, date d'échéance, heures estimées), les identifiants d'‎issues, les champs personnalisés simples (texte, nombres, dates, listes déroulantes), les utilisateurs, les statuts, les types et les commentaires. Ce qui n'est PAS migré : les relations entre ‎issues, les assignments aux sprints, les workflows automatisés et les permissions complexes. Procédure : depuis votre instance ‎Jira, exportez un fichier ‎XML complet (‎Administration → ‎Système → ‎Sauvegarde). Dans ‎OpenProject, allez dans ‎Administration → ‎Importation → ‎Jira et chargez le fichier ‎XML. Le temps de migration dépend du volume — prévoyez 15 à 30 minutes pour moins de 10 000 ‎issues.

Gitea propose un outil de migration intégré (Administration → Dépôts → Migrer) qui importe un dépôt GitHub par URL, en préservant l'historique complet des commits, les branches et les tags via un `git clone --mirror`. Pour migrer plusieurs dépôts, utilisez l'API Gitea avec un script qui itère sur vos dépôts GitHub et déclenche la migration pour chacun. Une fois la migration terminée, mettez à jour vos remotes locaux avec `git remote set-url origin <nouvelle-url>`. Consultez notre page `/vps-cloud` pour déployer une instance Gitea sur votre VPS ServOrbit.

Gitea intègre une migration des issues et milestones depuis GitHub : lors de la création ou de la mise à jour du dépôt via l'outil de migration (ou l'API `POST /api/v1/repos/migrate`), activez les options `issues`, `milestones` et `labels`. Un token d'accès personnel GitHub avec la portée `repo` est requis pour contourner les limites de l'API et accéder aux dépôts privés. Les commentaires, assignés et étiquettes sont également importés. Pour les grandes bases d'issues, prévoyez un délai proportionnel au volume car Gitea respecte les limites de débit de l'API GitHub.

Oui, via l'import CSV natif de Plane : dans Linear, exportez vos issues au format CSV (Settings → Export), puis dans votre instance Plane, rendez-vous dans Paramètres → Importateurs → CSV et chargez le fichier. Les titres, descriptions, priorités et étiquettes sont importés ; les commentaires ne sont pas pris en charge par le format CSV de Linear — seul un export JSON complet via l'API Linear les préserve. Pour une migration complète avec historique de commentaires, notre équipe support peut vous accompagner ; contactez-nous via l'espace client.

Confluence Data Center atteint sa fin de vie le 28 mars 2029 et passe en lecture seule à cette date. Docmost est une alternative open-source qui supporte les espaces, les permissions et l'édition collaborative ; l'importeur natif Confluence (édition Enterprise) préserve la hiérarchie des espaces, les pièces jointes, les liens internes et les diagrammes draw.io. La migration passe par l'export espace par espace au format XML depuis Confluence (Administration → Backup Manager), puis l'import dans Docmost. Pour les instances sans édition Enterprise, la migration est manuelle (export HTML, recréation de structure et copier-coller de contenu). Commandez un VPS ServOrbit avec au moins 2 Go de RAM, déployez Docmost depuis le marketplace, et ouvrez un ticket support via l'espace client si vous avez besoin d'accompagnement.

Planka v2.2.0 (publiée le 9 août 2026) a retiré l'authentification SSO/OIDC de la Community Edition et déplacée vers Planka Pro. Les comptes qui s'authentifiaient exclusivement via SSO sont désactivés après la mise à jour. Planka ne propose pas d'export JSON ou CSV natif des tableaux (issues GitHub #22 et #670 non résolues) — la seule extraction fiable passe par un dump PostgreSQL (`pg_dump`). Pour migrer : (1) effectuez un snapshot complet de la base avant toute coupure, (2) installez Kaneo ou Vikunja sur un sous-domaine temporaire et faites tourner les deux instances en parallèle 1–2 semaines, (3) transférez manuellement les tableaux actifs, (4) basculez le DNS à J+7 et conservez le snapshot 90 jours. Kaneo (MIT, v2.16.2) maintient le SSO OIDC gratuit ; Vikunja (AGPL-3.0, v2.4.0) également — les deux sont disponibles sur le marketplace ServOrbit.

La mise à jour Immich v2→v3 supprime l'extension pgvecto.rs et la remplace par pgvector natif. Avant de lancer la mise à jour (à partir de la v1.132.3), sauvegardez l'intégralité du volume PostgreSQL avec `docker compose exec database pg_dumpall -U postgres > backup.sql`. Mettez à jour votre fichier `docker-compose.yml` vers l'image `ghcr.io/immich-app/immich-server:v1.132.3`, puis exécutez `docker compose pull && docker compose up -d` : la migration du schéma s'effectue automatiquement au démarrage. Vos photos, albums et partages ne sont pas affectés — contactez [email protected] si la migration échoue au démarrage.

Passbolt CE accepte les imports CSV et JSON (Admin > Import passwords). Depuis Bitwarden : exporter en CSV non chiffré. Depuis 1Password : exporter en format 1PUX puis adapter les colonnes selon le format attendu. Les mots de passe importés sont re-chiffrés avec les clés GPG des destinataires désignés.

Forgejo v16 a rompu la compatibilité ascendante directe avec Gitea : l'équipe a finalisé le pivot vers un schéma de base de données et des chemins de config indépendants. Pour migrer depuis Gitea, la voie recommandée est d'abord de passer par Forgejo v7 ou v8 (la dernière version encore profilée pour l'import Gitea), d'exécuter les migrations de schéma, puis de monter progressivement jusqu'à v16. Un dump `gitea dump` suivi d'un `forgejo admin` reste la méthode la plus propre pour les instances de taille modérée. Ouvrez un ticket depuis votre espace client si vous avez besoin d'un accompagnement pour l'opération sur votre VPS ServOrbit.

Supabase a remplacé Kong par Envoy Gateway comme proxy interne à partir d'août 2026 : les variables d'environnement de routage, les timeouts et la configuration des plugins diffèrent sensiblement. Avant de tirer la mise à jour (`docker compose pull`), vérifiez vos overrides personnalisés dans `docker-compose.override.yml` (routes Kong, plugins rate-limit, CORS), lisez les notes de version officielles pour les équivalents Envoy, et faites un snapshot de vos volumes Docker. Testez la mise à jour sur un VPS de préproduction avant d'appliquer en production, et contrôlez les logs Envoy au premier démarrage pour repérer les routes non migrées.

Installez le binaire Forgejo Runner sur votre VPS, enregistrez-le avec un token généré dans votre instance Forgejo (Paramètres → Actions → Runners), puis créez vos workflows `.forgejo/workflows/` avec la même syntaxe YAML que GitHub Actions. La plupart des étapes sont compatibles ; seuls les runners hébergés GitHub (`ubuntu-latest`) doivent être remplacés par le label de votre runner (`self-hosted`). Pour toute question sur le dimensionnement ou la configuration, ouvrez un ticket depuis votre espace client.

Une interruption brève (quelques minutes) est généralement inévitable lors d'une mise à jour majeure Chatwoot, car les migrations de base de données sont bloquantes. Pour minimiser l'impact : sauvegardez intégralement PostgreSQL et les volumes, testez la mise à jour sur un environnement de staging, puis planifiez la bascule en dehors des heures de pointe. Le canal de notification de Chatwoot reste accessible aux agents pendant la fenêtre de maintenance si vous diffusez un message d'état au préalable. Pour de l'aide sur la planification, ouvrez un ticket depuis votre espace client.

La migration d'un site WordPress peut se faire sans temps d'arrêt en suivant cette procédure : **Étape 1 : Sauvegarder l'ancien hébergeur** - Export de la base de données MySQL via phpMyAdmin ou `mysqldump` - Archive des fichiers WordPress (dossier `wp-content/` notamment) **Étape 2 : Créer l'environnement sur ServOrbit** - Créer un VPS avec Debian/Ubuntu et installer WordPress - Restaurer la base de données et les fichiers - Configurer `wp-config.php` avec les nouvelles informations de connexion **Étape 3 : Tester avant de couper** - Accéder au nouveau site via son IP (ou un fichier `/etc/hosts` local) avant de changer le DNS - Vérifier que toutes les pages, médias et fonctionnalités marchent **Étape 4 : Réduire le TTL DNS** - 24–48h avant la migration, réduire le TTL de vos DNS à 300 secondes **Étape 5 : Basculer le DNS** - Changer l'enregistrement A/AAAA vers la nouvelle IP - La propagation prendra 5 à 30 minutes avec un TTL bas L'ancien hébergeur reste actif pendant la propagation — aucun visiteur ne voit d'interruption.

Oui, le transfert d'un nom de domaine n'interrompt pas votre site si vous suivez la bonne procédure. **Principe clé :** le DNS et le registrar sont deux choses séparées. Votre site fonctionne tant que les serveurs DNS répondent correctement — indépendamment de qui détient le registrar. **Procédure sans interruption :** 1. **Avant de lancer le transfert**, vérifiez que vos DNS sont gérés chez un prestataire stable (Cloudflare, votre hébergeur actuel, etc.) — pas directement chez le registrar d'origine. 2. **Déverrouillez le domaine** chez l'ancien registrar et récupérez le code EPP/Auth. 3. **Initiez le transfert** chez ServOrbit (ou laissez vos DNS chez Cloudflare si vous y êtes déjà). 4. **Pendant le transfert** (5 à 7 jours pour les .com, .net ; 2 à 3 jours pour les .fr ; jusqu'à 7 jours pour les .ma), votre site continue de fonctionner — les DNS ne bougent pas. 5. **Après le transfert** : si vos DNS étaient gérés par l'ancien registrar, vous devrez les reconfigurer chez le nouveau. Planifiez cette étape à l'avance. **Important pour les .ma :** le transfert de noms .ma suit des règles spécifiques définies par l'ANRT et peut requérir des justificatifs supplémentaires.

Depuis Notion, rendez-vous dans Réglages → Espace de travail → Exporter le contenu et choisissez le format Markdown & CSV pour obtenir une archive de vos pages et bases de données. Cette archive sert de point de départ pour l'import dans Docmost (import Markdown) ou AppFlowy (import Notion). Pour un espace de travail volumineux, prévoyez quelques minutes d'attente avant que Notion envoie le lien de téléchargement par e-mail. Si vous avez besoin d'aide, contactez-nous à [email protected].

Plane propose un import natif depuis Jira : dans votre instance Plane, accédez à Paramètres → Importers → Jira, renseignez votre URL Jira et un token API, puis sélectionnez les projets à importer — les issues, assignations, labels et statuts sont transférés. Pour un projet Jira Data Center (non cloud), le connecteur d'import peut nécessiter un accès réseau direct à votre instance ; prévoyez un test sur un projet de petite taille avant la migration complète.

La méthode la plus sûre est un dump/restore : arrêtez vos services applicatifs, exportez la base avec `docker exec <pg15> pg_dumpall -U postgres > dump.sql`, puis lancez un nouveau conteneur PostgreSQL 17, importez le dump et vérifiez chaque base avec `pg_dump --schema-only` avant de couper l'ancien conteneur. Un VPS ServOrbit avec accès root vous laisse piloter entièrement la procédure et conserver les deux conteneurs le temps des tests. Consultez la page `/vps-cloud` pour choisir la configuration adaptée à la taille de vos bases.

Oui, ServOrbit propose un service de migration M365 vers Nextcloud couvrant les e-mails (IMAP-to-IMAP), les calendriers (CalDAV) et les contacts (CardDAV). La migration est réalisée en mode cutover ou delta selon le volume de boîtes, sans interruption de service perceptible pour vos utilisateurs. Les licences M365 peuvent être conservées temporairement en parallèle le temps de valider la migration, puis résiliées à votre rythme. Contactez notre support pour un audit préalable et un devis adapté à la taille de votre organisation.

La migration de Sentry vers GlitchTip repose sur un simple remplacement du DSN (Data Source Name) dans chaque application : GlitchTip expose une API compatible Sentry, il suffit de pointer votre variable d'environnement `SENTRY_DSN` vers le nouveau DSN GlitchTip sans modifier le SDK ni le code. Les règles d'alerte, équipes et projets doivent être recréés manuellement dans GlitchTip car aucun export automatique n'existe entre les deux plateformes. Nous recommandons une phase de double-envoi (conserver Sentry actif en parallèle quelques jours) pour valider que GlitchTip capte bien toutes les erreurs avant la coupure définitive.

Exporter les contacts depuis HubSpot via Settings > Data Management > Export > Contacts au format CSV. Dans Twenty CRM, utiliser People > Import > CSV pour charger le fichier ; les champs standard (prénom, nom, e-mail, téléphone) sont mappés automatiquement. Les propriétés personnalisées HubSpot sont à recréer manuellement dans Twenty avant l'import.

Stalwart inclut un outil de migration et un proxy de migration qui travaillent ensemble pour déplacer les comptes en continu : les utilisateurs continuent d'envoyer et de recevoir des emails pendant le transfert, compte par compte. Concrètement, pointez le proxy vers l'ancien serveur le temps que l'outil copie emails, dossiers, filtres Sieve, carnets d'adresses et calendriers ; une fois un compte migré, le proxy le redirige directement vers Stalwart. Avant de commuter le DNS, vérifiez les enregistrements SPF, DKIM et DMARC sur le nouveau VPS. Notre équipe peut vous accompagner via un ticket depuis votre espace client.

Avant toute migration, exportez vos données en passant par les formats ouverts : CSV ou JSON pour les bases, PDF pour les documents, ZIP pour les médias. Vérifiez que l'export est complet — certains SaaS n'exportent pas les pièces jointes ou l'historique. Conservez une copie hors du service (stockage local ou objet) avant de résilier : une fois le compte fermé, les données sont inaccessibles. Testez également l'import dans votre solution cible avant de couper l'ancien accès, pour éviter toute perte de données non détectée.

Commencez par auditer vos services actuels : listez ce que vous payez, les données associées et les intégrations critiques. Choisissez ensuite un équivalent open source et testez-le sur un VPS de développement avant toute bascule. Planifiez la migration en dehors des heures creuses, préparez un plan de rollback et exportez vos données au préalable. Migrez service par service plutôt que tout à la fois : cela limite les risques et facilite le diagnostic en cas de problème. Vérifiez les sauvegardes automatiques avant de résilier vos anciens abonnements.

Avant toute migration, réalisez une sauvegarde complète via la commande `bench backup` de Frappe — elle exporte la base de données et les fichiers en un seul archive. Sur le nouveau VPS ServOrbit, installez ERPNext via le template Marketplace ou manuellement, importez la sauvegarde avec `bench restore`, puis mettez à jour l'adresse du site dans `currentsite.txt`. Vérifiez les droits des fichiers uploadés et testez l'accès avant de couper le DNS de l'ancien serveur pour éviter toute interruption. Notre équipe peut vous accompagner dans cette migration via un ticket support.

Depuis GitLab, utilisez l'API REST (`/api/v4/projects?owned=true`) pour lister vos dépôts, puis clonez chacun avec `git clone --mirror`. Gitea propose un assistant d'import intégré (Administration → Migration) qui accepte une URL GitLab et crée automatiquement les dépôts, les issues et les pull requests. Pour les namespaces en lecture seule ou les groupes, exportez d'abord une archive tarball depuis GitLab (Paramètres → Général → Exporter le projet) puis importez-la dans Gitea via l'interface ou son API. Prévoyez un VPS avec au moins 2 Go de RAM pour une migration fluide.

Depuis Kommo, exportez vos contacts, entreprises et transactions au format CSV via le menu Paramètres → Exports. Importez ensuite ces fichiers dans Twenty depuis l'onglet Import de chaque objet (People, Companies, Opportunities). Pour les pièces jointes et l'historique des conversations, vérifiez les exports disponibles dans Kommo et conservez-les séparément. Notre équipe peut vous accompagner si vous avez besoin d'aide pour planifier la migration.

Jellyfin lit directement les mêmes dossiers de médias que Plex : il n'est pas nécessaire de copier ou de déplacer vos fichiers. Pointez les bibliothèques Jellyfin vers vos répertoires existants, laissez-le analyser et construire ses métadonnées. Vos listes de lecture et votre historique de lecture ne sont en revanche pas automatiquement transférés depuis Plex. Si votre instance tourne sur un VPS ServOrbit, l'espace de stockage attaché reste inchangé.