# Transférer un serveur vers une autre organisation

> Déplacez un serveur avec ses sites et bases de données vers une autre organisation : envoi du transfert par e-mail, acceptation et ce qui suit le serveur.

Un transfert de serveur déplace un serveur, avec ses sites, ses bases de données et tout ce qui s'y trouve, d'une organisation de Vimonto Deploy vers une autre. Vous proposez le serveur à quelqu'un par e-mail ; cette personne l'accepte dans l'une de ses organisations, et à partir de là il lui appartient. Rien ne change sur le serveur lui-même : il continue de tourner et ses sites restent en ligne.

Utilisez-le pour remettre un serveur à un client, pour le déplacer vers l'organisation d'un collègue ou pour le faire passer d'une de vos organisations à une autre.

![La page sur laquelle le nouveau propriétaire accepte un transfert de serveur, avec le serveur, son adresse IP, le nombre de sites et l'organisation de destination](https://ops.vimonto.com/docs-media/fr/server-transfer.webp?v=161e760d "Accepter un transfert de serveur")

## Qui peut transférer un serveur ?

- **Envoyer un transfert** demande le droit de supprimer des serveurs dans l'organisation actuelle : le rôle **Propriétaire**, **Administrateur** ou **Manager**. Voir [membres et rôles](https://ops.vimonto.com/docs/fr/organization/members-and-roles).
- **Accepter un transfert** demande un compte Vimonto Deploy avec l'adresse e-mail à laquelle le transfert a été envoyé, et le droit de créer des serveurs dans l'organisation de destination : là aussi **Propriétaire**, **Administrateur** ou **Manager**.

Le destinataire n'a pas besoin d'être membre de votre organisation. S'il n'a pas encore de compte, il peut en créer un depuis le lien de l'e-mail.

## Envoyer un transfert

1. Ouvrez le serveur et choisissez **Paramètres** dans la barre latérale.
2. Sous **Zone de danger**, cliquez sur **Transférer le serveur**.
3. Saisissez l'**Adresse e-mail du nouveau propriétaire** et cliquez sur **Envoyer le transfert**.

Le destinataire reçoit un e-mail avec un bouton **Voir le transfert**. Tant qu'il n'a pas accepté, rien ne change : le serveur reste dans votre organisation et fonctionne comme avant. La **Zone de danger** indique à qui le serveur est proposé et jusqu'à quand.

Quelques règles :

- Vous ne pouvez envoyer un transfert que lorsqu'aucune tâche ne tourne sur le serveur, comme un déploiement ou le provisionnement.
- Un serveur n'a qu'un seul transfert en cours à la fois. En envoyer un nouveau remplace l'offre précédente, et l'ancien lien ne fonctionne plus.
- Vous ne pouvez envoyer un transfert à votre propre adresse e-mail que si vous êtes membre d'une autre organisation, pour y déplacer le serveur.
- Dès que le transfert est accepté, votre organisation perd son accès : les clés SSH de votre organisation et de ses membres sont retirées du serveur, et le mot de passe sudo du serveur ainsi que les URL de déploiement des sites changent. Voir *Comment l'ancienne organisation perd-elle son accès ?* ci-dessous.

## Combien de temps un transfert est-il valable ?

Sept jours. Ensuite, le lien ne fonctionne plus et vous envoyez un nouveau transfert si nécessaire. Le lien cesse aussi de fonctionner dès que le transfert est accepté ou annulé, ou lorsque le serveur n'est plus dans l'organisation depuis laquelle il a été proposé.

Pour retirer une offre, cliquez sur **Annuler le transfert** dans la **Zone de danger** des paramètres du serveur. Les transferts expirés sont supprimés automatiquement.

## Accepter un transfert

1. Ouvrez le lien de l'e-mail. Si vous n'êtes pas connecté, choisissez **Se connecter** ou **Créer le compte** avec l'adresse e-mail à laquelle le transfert a été envoyé ; vous revenez ensuite au transfert.
2. La page **Reprendre …** affiche le serveur, son adresse IP et le nombre de sites qu'il héberge. Sous **Avant d'accepter**, elle liste pour ce serveur **Ce que nous faisons pour vous** et **Il vous reste à faire** (voir plus bas), puis ce qui reste en arrière.
3. Sous **Dans l'organisation**, choisissez l'organisation qui reçoit le serveur. Seules les organisations dans lesquelles vous pouvez créer des serveurs sont proposées.
4. Cliquez sur **Accepter le serveur**.

Le serveur et ses sites comptent dans l'[offre](https://ops.vimonto.com/docs/fr/organization/billing) de l'organisation qui le reçoit : avec l'offre gratuite, l'acceptation est refusée s'ils n'y tiennent pas.

Le serveur est déplacé immédiatement et sa page s'ouvre dans votre organisation. Si une tâche tourne encore sur le serveur, attendez une minute et réessayez. Si aucune de vos organisations ne peut recevoir le serveur, créez-en d'abord une (voir [organisations](https://ops.vimonto.com/docs/fr/organization/organizations)).

Juste après l'acceptation, vous recevez un e-mail, **… est désormais à vous : ce qu'il reste à faire**, avec les deux mêmes listes et un bouton **Voir le serveur**. Le nouveau mot de passe sudo n'y figure pas : il arrive dans un e-mail séparé dès qu'il est défini.

## Qu'est-ce qui suit le serveur ?

Tout ce qui se trouve sur le serveur le suit : ses sites avec leurs domaines, certificats, environnement, scripts de déploiement et historique des déploiements, les bases de données et leurs utilisateurs, les versions de PHP, les [processus](https://ops.vimonto.com/docs/fr/servers/processes), les [tâches planifiées](https://ops.vimonto.com/docs/fr/servers/scheduler), les règles de pare-feu, la supervision et ses paramètres. Les clés SSH ne suivent pas, sauf celles de votre propre organisation et de ses membres (voir ci-dessous).

La paire de clés propre au serveur et sa clé d'hôte SSH le suivent aussi, si bien que Vimonto Deploy continue de s'y connecter comme avant.

## Qu'est-ce qui reste dans l'ancienne organisation ?

Ce qui appartient à l'organisation et non au serveur ne le suit pas :

| Quoi | Ce qui se passe |
| --- | --- |
| **Compte fournisseur** | Le serveur n'est plus lié au compte cloud avec lequel il a été créé. Il continue d'y tourner et reste facturé à ce compte : déplacez-le vous-même chez le fournisseur si nécessaire. Depuis la nouvelle organisation, supprimer le serveur arrête seulement sa gestion ; la machine ne peut plus être supprimée chez le fournisseur. |
| **Connexions Git** | Les sites perdent leur connexion [Git](https://ops.vimonto.com/docs/fr/connections/source-control), et le **Déploiement rapide** est désactivé. |
| **Sauvegardes** | Les planifications de sauvegarde et leur liste de sauvegardes sont supprimées. Les fichiers de sauvegarde restent dans le stockage de l'ancienne organisation. |
| **Équipes** | Le serveur est retiré des [équipes](https://ops.vimonto.com/docs/fr/organization/teams) de l'ancienne organisation. |
| **Load balancers** | Les liens entre ce serveur et les load balancers de l'ancienne organisation sont supprimés dans les deux sens, et la configuration Nginx des sites concernés est réécrite. Voir [répartition de charge](https://ops.vimonto.com/docs/fr/sites/load-balancing). |

Le transfert est enregistré dans le [journal d'audit](https://ops.vimonto.com/docs/fr/organization/audit-log) des deux organisations : l'envoi, l'annulation et l'acceptation.

## Comment l'ancienne organisation perd-elle son accès ?

Au moment où le serveur change d'organisation, et dans une tâche juste après, Vimonto Deploy retire l'accès que l'ancienne organisation a encore :

| Quoi | Ce qui se passe |
| --- | --- |
| **URL de déploiement** | Chaque site reçoit immédiatement une nouvelle URL de déploiement. L'ancienne URL ne fonctionne plus : l'ancienne organisation ne peut plus lancer de déploiements depuis sa CI ou son webhook Git. |
| **Clés SSH** | La tâche **Sécuriser** *serveur* **après le transfert** retire chaque clé que Vimonto Deploy a placée sur le serveur et qui n'est ni une clé de la nouvelle organisation ni une clé de compte d'un de ses membres : les clés de l'ancienne organisation, celles de ses membres et les clés ajoutées sur la page **Clés SSH** du serveur. Elle ajoute ensuite les [clés SSH](https://ops.vimonto.com/docs/fr/connections/ssh-keys) de la nouvelle organisation. |
| **Mot de passe sudo** | La même tâche donne un nouveau mot de passe sudo à l'utilisateur système. Seule la personne qui a accepté le voit, une fois, dans la fenêtre **Mots de passe de** *serveur* de la vue d'ensemble, et en reçoit une copie par e-mail. Voir [paramètres du serveur](https://ops.vimonto.com/docs/fr/servers/server-settings). |
| **Alertes** | Les [moniteurs et heartbeats](https://ops.vimonto.com/docs/fr/servers/monitoring) écrivent désormais à la personne qui a accepté au lieu des anciennes adresses. |
| **Commande de connexion** | Un VPS personnalisé qui attendait encore sa commande de connexion en reçoit une nouvelle ; l'ancienne ne fonctionne plus. |

La vue d'ensemble du nouveau propriétaire affiche **Ce serveur vous a été transféré**, avec ce qui a été fait et ce qu'il reste à faire. Si la tâche a échoué, par exemple parce que le serveur était injoignable, cliquez sur **Réessayer**. Cliquez sur **Compris** pour masquer l'avis.

Vimonto Deploy ne change rien qui mettrait vos sites hors ligne ni ce qu'il ne connaît pas : le mot de passe de la base de données (les sites le lisent dans leur environnement), les secrets de l'environnement des sites comme `APP_KEY`, et les accès mis en place sur le serveur en dehors de Vimonto Deploy. Les URL de ping des heartbeats restent aussi les mêmes, car les tâches planifiées du serveur les appellent, et les clés de déploiement des sites peuvent encore lire les dépôts de l'ancienne organisation jusqu'à ce qu'elle les retire chez son hébergeur Git.

## Après l'acceptation : que doit faire le nouveau propriétaire ?

La liste **Il vous reste à faire** de la page d'acceptation, de l'e-mail et de l'avis de la vue d'ensemble reprend les points ci-dessous qui concernent votre serveur.

- **Reconnecter Git.** Reliez les sites à une connexion Git à vous et réactivez le **Déploiement rapide** là où vous le souhaitez. Voir [déploiements](https://ops.vimonto.com/docs/fr/sites/deployments). La clé de déploiement des sites peut encore lire le dépôt de l'ancienne organisation jusqu'à ce qu'elle la retire chez son hébergeur Git.
- **Conserver le nouveau mot de passe sudo** depuis la fenêtre **Mots de passe de** *serveur* de la vue d'ensemble, puis cliquer sur **Je les ai enregistrés**. En acceptant, vous devenez le créateur du serveur dans la vue d'ensemble : vous seul le voyez donc (**Afficher une seule fois**).
- **Mettre à jour votre CI.** Chaque site a une nouvelle URL de déploiement : copiez-la depuis la page **Déploiements** du site dans votre CI.
- **Planifier des sauvegardes** vers votre propre stockage sur la page [sauvegardes](https://ops.vimonto.com/docs/fr/servers/backups).
- **Changer le mot de passe de la base de données** si le serveur en a une : sur la page **Bases de données**, cliquez sur **Changer le mot de passe** pour l'utilisateur système, puis mettez le nouveau mot de passe dans le `.env` des sites qui l'utilisent. Vimonto Deploy ne le change pas pour vous, car les sites le lisent dans leur `.env` et seraient hors ligne. Changez aussi les autres secrets que l'ancien propriétaire connaît, comme `APP_KEY` et les clés d'API.
- **Recréer les heartbeats si leurs URL doivent rester secrètes.** Les URL de ping des [heartbeats](https://ops.vimonto.com/docs/fr/servers/monitoring) restent les mêmes, car les tâches planifiées du serveur les appellent ; l'ancienne organisation les connaît donc. Supprimez les heartbeats sur la page **Monitoring**, ajoutez-les à nouveau et mettez les nouvelles URL dans vos tâches.
- **Vérifier les accès hors de Vimonto Deploy.** Les clés ajoutées à la main dans `authorized_keys` et les utilisateurs Linux supplémentaires sont inconnus de Vimonto Deploy et restent en place. Retirez-les si nécessaire.
- **L'ajouter à vos équipes** si les membres de votre organisation ne voient que les serveurs de leurs équipes. D'ici là, seuls les membres qui voient tous les serveurs le voient.
- **Remettre en place la répartition de charge** si le serveur se trouvait derrière un load balancer.

## Questions fréquentes

### Le serveur est-il hors ligne pendant un transfert ?

Non. Un transfert change seulement l'organisation qui gère le serveur dans Vimonto Deploy. Rien ne s'exécute sur le serveur, et ses sites continuent de servir les visiteurs.

### Puis-je déplacer un serveur entre mes propres organisations ?

Oui. Envoyez le transfert à votre propre adresse e-mail, ouvrez le lien et choisissez l'autre organisation sous **Dans l'organisation**. Il vous faut le droit de supprimer des serveurs dans la première organisation et d'en créer dans la seconde.

### L'ancienne organisation peut-elle encore accéder au serveur ?

Pas via Vimonto Deploy : ses URL de déploiement cessent de fonctionner immédiatement, et ses clés SSH ainsi que l'ancien mot de passe sudo sont retirés du serveur juste après. Seuls ce qui a été mis en place en dehors de Vimonto Deploy et le mot de passe de la base de données restent tels quels ; changez-les vous-même. Tant que la machine se trouve dans son compte fournisseur, l'ancienne organisation peut encore la gérer là-bas. Les URL de ping des heartbeats restent aussi les mêmes, jusqu'à ce que vous recréiez les heartbeats.

### La facturation chez le fournisseur cloud suit-elle aussi ?

Non. Le serveur reste dans le compte fournisseur où il a été créé, qui continue de le facturer. Pour le déplacer vers un autre compte, utilisez la fonction de transfert du fournisseur ; ensuite, il est géré dans Vimonto Deploy comme un [VPS personnel](https://ops.vimonto.com/docs/fr/servers/custom-vps).

### Et si le destinataire n'accepte jamais ?

Alors rien ne se passe. Le transfert expire après sept jours et le serveur reste où il est. Vous pouvez aussi l'annuler plus tôt avec **Annuler le transfert**.