Migration

Oui. Notre assistant de migration est inclus sur toutes les offres, Start compris : il transfère vos domaines et restaure vos comptes cPanel en une seule commande, sans interruption de service. À partir de Business, la prise en charge de bout en bout par notre équipe est également incluse.

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.

Sa durée dépend de la taille du site et du volume de données. Elle se déroule en trois temps : transfert (domaines par code EPP, compte cPanel restauré depuis une sauvegarde ou par transfert direct), vérification du site sur nos serveurs, puis bascule DNS — votre site reste en ligne chez votre hébergeur actuel jusqu'à cette bascule. 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.

L'assistant de migration (transfert de vos domaines et restauration de vos comptes cPanel) est inclus sur toutes les offres, Start compris : vous ne payez que vos services. À partir de Business, la prise en charge de bout en bout par notre équipe est également incluse.

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, passez par l'API Linear : vous menez la migration vous-même, et le support répond à vos questions depuis 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. Vous menez cette migration vous-même ; le support répond à vos questions via un ticket.

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é.

ServOrbit propose une migration assistée qui copie vos fichiers et votre base de données sur nos serveurs avant toute modification DNS. Une fois les tests validés sur le nouvel hébergement, la bascule DNS est réalisée en quelques minutes, limitant l'interruption à la propagation du TTL. Contactez [email protected] pour planifier votre migration.

Nous n'annonçons pas de durée type : elle dépend du volume de données et du nombre de comptes à migrer. Le déroulé, lui, est toujours le même : transfert (domaines par code EPP, comptes cPanel restaurés depuis une sauvegarde ou par transfert direct), vérification sur nos serveurs, puis bascule DNS. Votre hébergement source n'est pas modifié : le site reste en ligne chez votre hébergeur actuel jusqu'à la bascule. L'assistant de migration est inclus sur toutes les offres, Start compris, et la prise en charge de bout en bout par notre équipe l'est à partir de Business. Pour un cas particulier, écrivez à [email protected].

La méthode recommandée consiste à exporter votre base via mysqldump sur l'ancien hébergement, à l'importer sur le VPS pendant que l'ancien reste actif, puis à basculer la configuration de votre application vers le nouveau serveur après un test de cohérence. ServOrbit peut coordonner cette opération pour vous ; contactez [email protected] pour planifier la migration en dehors des heures de pointe.

Oui, il est possible de migrer vos e-mails d'entreprise depuis un hébergement mutualisé vers un VPS ServOrbit. La migration comprend le transfert des boîtes mail, des contacts et de l'historique des messages via le protocole IMAP. Nous recommandons d'utiliser un outil comme imapsync pour éviter toute perte de données : vous menez la migration vous-même, et le support répond à vos questions. Prévoyez une fenêtre de bascule DNS adaptée et conservez l'accès à l'ancien hébergement pendant 48 à 72 heures pour garantir la continuité du service.

La migration depuis Odoo.sh ou le SaaS officiel vers un VPS autohébergé est techniquement faisable, mais elle implique plusieurs étapes. Il faut d'abord exporter le dump de la base de données PostgreSQL et le répertoire `filestore` depuis la plateforme source. Sur le VPS, une installation d'Odoo à la même version majeure est nécessaire avant d'importer les données. Les modules développés spécifiquement pour la plateforme cloud (intégrations Odoo.sh, modules Enterprise payants non inclus dans Community) doivent être identifiés et remplacés. Enfin, les certificats SSL, la configuration DNS et les accès SMTP doivent être reconfigurés sur le nouveau serveur avant le basculement du trafic.

La migration se fait en trois étapes : exportez votre contenu depuis Squarespace (outils → export), importez-le dans Ghost via son panneau d'administration, puis pointez votre domaine vers votre VPS ServOrbit. Ghost s'installe en quelques minutes sur un VPS via notre Marketplace ; prévoyez au moins 1 Go de RAM. Pour toute question, ouvrez un ticket depuis votre espace client en précisant votre calendrier de migration.

Oui, une migration Plex ou Jellyfin vers un VPS ServOrbit se fait en trois étapes : export de la base de données et du dossier de métadonnées depuis votre installation actuelle, transfert via rsync ou SCP vers votre nouveau VPS, puis réinstallation du serveur en pointant vers les mêmes chemins. Les métadonnées, listes de lecture et avancements de lecture sont conservés à condition que les chemins de bibliothèque restent identiques ou soient reconfigurés correctement. Nos VPS root vous laissent une liberté totale sur la structure des répertoires. Contactez [email protected] pour toute question sur le transfert de données.

Plane propose un importeur natif pour Asana accessible depuis les paramètres du workspace (Settings → Importers → Asana). Il importe les projets, les tâches, les sous-tâches, les assignés, les dates d'échéance et les commentaires. L'historique des activités (audit trail) est partiellement conservé : les commentaires datés et les changements de statut sont inclus, mais les pièces jointes volumineuses peuvent nécessiter un transfert manuel selon leur taille. Avant de lancer l'import, générez un token d'accès personnel Asana et accordez les droits de lecture sur les workspaces concernés. La migration ne supprime rien côté Asana : vous gardez les deux systèmes en parallèle le temps de valider. Une fois Plane installé sur votre VPS ServOrbit (il n'est pas encore proposé à la commande sur la Marketplace), l'importeur tourne directement dans l'interface web — aucune commande CLI n'est nécessaire. Pour les migrations de grande ampleur (plus de 10 000 tâches), effectuez l'import en dehors des heures de pointe pour éviter les timeouts.

La démarche suit toujours trois étapes : exporter vos données depuis la plateforme SaaS (tableau de bord ou API selon ce qu'elle propose), déployer l'application sur votre VPS ServOrbit, puis importer vos données. Certaines applications proposent un importeur natif intégré ; pour d'autres, le transfert passe par les fichiers ou la base de données. ServOrbit propose des templates VPS prêts à l'emploi sur la Marketplace pour les applications les plus courantes — le template inclut la configuration initiale et le reverse proxy. Ouvrez un ticket depuis votre espace client si vous avez besoin d'aide sur une migration spécifique.

La migration se fait en plusieurs étapes, que vous menez vous-même : exportez vos emails via Google Takeout (format MBOX), puis importez-les dans Nextcloud Mail ou Roundcube sur votre VPS ServOrbit. Pour les fichiers Google Drive, installez Nextcloud depuis la marketplace ServOrbit en un clic, puis utilisez l'outil de migration intégré (rclone ou le connecteur Nextcloud Google Drive). L'ensemble de la procédure est documentée dans notre guide de migration Google Workspace.

La méthode recommandée est de préparer l'environnement sur ServOrbit avant de basculer le DNS : dupliquez votre site sur le VPS ou l'hébergement cible, testez-le via le fichier hosts local, puis abaissez le TTL DNS à 300 secondes 48h avant la migration. Une fois le transfert validé, mettez à jour vos DNS chez ServOrbit. La propagation prend généralement moins de 15 minutes avec notre infrastructure Cloudflare. Notre équipe support peut accompagner cette bascule sur demande.

La migration de Bitwarden Cloud vers une instance Vaultwarden auto-hébergée se fait en trois étapes : exportez votre coffre depuis l'application Bitwarden (format JSON non chiffré ou chiffré), déployez Vaultwarden sur votre VPS ServOrbit via Docker, puis importez le fichier dans votre nouvelle instance. Vaultwarden est compatible avec le client officiel Bitwarden : aucune réinstallation de l'application n'est nécessaire, il suffit de pointer vers votre domaine. Notre article détaillé couvre chaque étape : Migrer de Bitwarden Cloud vers Vaultwarden sur VPS.

La migration d'un site e-commerce suit les mêmes grandes étapes qu'une migration classique, avec une attention particulière à la base de données : exportez une sauvegarde complète (fichiers + dump SQL) depuis votre hébergeur actuel, importez-la sur votre hébergement ServOrbit, puis testez votre site en modifiant localement votre fichier hosts avant tout changement de DNS — ainsi votre boutique en ligne reste accessible à vos clients pendant l'opération. Ajustez ensuite les paramètres de connexion à la base de données dans le fichier de configuration de votre application (wp-config.php pour WooCommerce, parameters.php ou .env pour PrestaShop). Une fois les tests validés, mettez à jour vos enregistrements DNS ; la propagation prend en général moins de 24 heures. Notre service de migration assistée peut prendre en charge l'ensemble du processus — contactez-nous via [email protected].

Oui, il est possible de migrer uniquement votre base de données (MySQL, MariaDB ou PostgreSQL) vers un VPS ServOrbit tout en gardant votre site sur un autre hébergeur, à condition que votre application puisse se connecter à une base distante. Vous devrez configurer les accès réseau (pare-feu, utilisateur MySQL distant) et mettre à jour les identifiants de connexion dans votre application. L'assistant de migration couvre les comptes cPanel complets qui arrivent sur un hébergement ; une base de données seule vers un VPS, vous la migrez vous-même, et le support répond à vos questions par ticket depuis votre espace client.

Oui, sous conditions. YNAB permet d'exporter vos transactions au format CSV depuis l'onglet « Reports ». Maybe.co (anciennement Maybe Finance) accepte l'import CSV de transactions. L'opération préserve les montants, dates et catégories, mais les règles de budget YNAB (enveloppes) ne se transfèrent pas nativement — il faudra les recréer manuellement dans Maybe. Faites d'abord un test sur un export partiel avant de migrer l'intégralité de votre historique.

Atlassian propose un outil officiel de migration Cloud-to-Server (ou Data Center) accessible depuis l'interface d'administration de votre instance Cloud ; il exporte projets, tickets, espaces et historique dans une archive importable sur votre nouveau VPS. Avant de lancer la migration, provisionnez un VPS avec au moins 4 Go de RAM, installez la même version majeure de Jira ou Confluence, et vérifiez que le serveur est joignable en HTTPS avec un certificat TLS valide. Notre équipe support répond à vos questions à [email protected] sur les étapes d'importation et la configuration DNS.

Le positionnement sur Google.ma dépend du ciblage géographique déclaré dans Google Search Console, pas de la localisation physique du serveur. Avant la migration, déclarez votre cible géographique Maroc dans Search Console, vérifiez que votre domaine .ma reste le canonique, et mettez en place des redirections 301 si vous changez d'URL. Vous copiez vous-même vos fichiers et bases de données sur le VPS, et le support répond à vos questions ; l'assistant présenté sur notre page migrations concerne les hébergements cPanel.

La migration zéro-interruption repose sur trois étapes : d'abord un dump logique initial avec `pg_dump` suivi d'une restauration sur votre VPS, puis la mise en place d'une réplication logique (slot de réplication PostgreSQL ≥ 10) pour rattraper les écritures en cours, et enfin un basculement de la chaîne de connexion de l'application lors d'une courte fenêtre planifiée. Il convient de tester la restauration et les performances sur votre VPS ServOrbit avant tout basculement, et de conserver l'instance RDS active en lecture seule pendant quelques heures après la migration pour permettre un retour arrière rapide. Consultez l'article dédié dans notre base de connaissance ou ouvrez un ticket à [email protected] pour un accompagnement personnalisé.

Oui : la liste d'abonnés s'exporte, généralement en CSV, depuis l'outil actuel et se réimporte dans le nouveau. Exportez aussi le statut de chaque contact (abonné, désabonné, adresse en échec) et réimportez les désabonnés comme tels, jamais comme actifs : leur réécrire provoque des plaintes qui abîment la réputation de votre domaine. Avant le premier envoi depuis le nouveau service, ajoutez à la zone DNS de votre domaine les enregistrements SPF et DKIM qu'il vous fournit, et réservez l'envoi en nombre à ce service plutôt qu'à votre boîte e-mail pro. Pour l'aide sur ces enregistrements DNS, ouvrez un ticket depuis votre espace client.

L'export de projet reprend le code, les tickets et les merge requests, mais pas les variables CI/CD, les webhooks, les jetons, les artefacts de jobs ni les images du registre de conteneurs. Faites l'inventaire de ces éléments avant la bascule et recréez-les à la main sur la nouvelle instance, en gardant l'ancien projet en lecture seule jusqu'à validation. ServOrbit fournit un guide pas à pas, mais ne réalise pas la migration à votre place.

Pendant la propagation DNS, certains visiteurs atteignent encore l'ancien serveur : tout ce qu'ils y écrivent n'arrive pas sur le nouveau. Abaissez le TTL à l'avance, faites une dernière synchronisation de la base et des fichiers juste avant la bascule, puis mettez l'ancien site en maintenance ou désactivez le paiement et les formulaires le temps de la transition. Gardez l'ancien hébergement actif ensuite et vérifiez qu'aucune commande ni aucun commentaire n'y est arrivé après la synchronisation avant de le résilier. Pour une boutique, la migration assistée peut vous accompagner : écrivez à [email protected].

Dupliquez les fichiers et la base sur un sous-domaine séparé, protégé par mot de passe et en noindex, puis remplacez l'adresse du site dans la base avec un outil qui gère les données sérialisées, pas avec un simple chercher-remplacer. Coupez sur la copie les envois d'e-mails, les paiements réels et les tâches planifiées, pour que le client ne reçoive rien. Validez la mise à jour sur la copie, puis refaites-la sur la production après une sauvegarde plutôt que de rapatrier la copie : elle écraserait les commandes et commentaires reçus entre-temps.

Évitez de faire les deux en même temps : si le site casse, vous ne saurez pas si la cause est le déplacement ou la mise à niveau. Migrez d'abord à l'identique, en choisissant dans cPanel la même version de PHP que sur l'ancien hébergement, et validez le site. Mettez ensuite à niveau sur une copie, testez, puis appliquez en production, sauvegarde fraîche à l'appui. Si la version actuelle n'est plus maintenue, planifiez la mise à niveau juste après la bascule plutôt que de la repousser.