# Trasferire un server a un'altra organizzazione

> Sposta un server con i suoi siti e database in un'altra organizzazione: invia il trasferimento via email, accettalo e scopri cosa si sposta con il server.

Un trasferimento sposta un server, con i suoi siti, i database e tutto ciò che contiene, da un'organizzazione di Vimonto Deploy a un'altra. Offri il server a qualcuno via email; questa persona lo accetta in una delle sue organizzazioni e da quel momento è suo. Sul server non cambia nulla: continua a funzionare e i suoi siti restano online.

Usalo per consegnare un server a un cliente, per spostarlo nell'organizzazione di un collega o per spostarlo tra due delle tue organizzazioni.

![La pagina in cui il nuovo proprietario accetta un trasferimento, con il server, il suo indirizzo IP, il numero di siti e l'organizzazione di destinazione](https://ops.vimonto.com/docs-media/it/server-transfer.webp?v=161e760d "Accettare un trasferimento di server")

## Chi può trasferire un server?

- **Inviare un trasferimento** richiede il permesso di eliminare server nell'organizzazione attuale: il ruolo **Proprietario**, **Amministratore** o **Manager**. Vedi [membri e ruoli](https://ops.vimonto.com/docs/it/organization/members-and-roles).
- **Accettare un trasferimento** richiede un account Vimonto Deploy con l'indirizzo email a cui è stato inviato, e il permesso di creare server nell'organizzazione di destinazione: anche qui **Proprietario**, **Amministratore** o **Manager**.

Il destinatario non deve essere membro della tua organizzazione. Se non ha ancora un account, può crearne uno dal link nell'email.

## Inviare un trasferimento

1. Apri il server e scegli **Impostazioni** nella barra laterale.
2. In **Zona pericolosa**, fai clic su **Trasferisci server**.
3. Inserisci l'**Indirizzo email del nuovo proprietario** e fai clic su **Invia il trasferimento**.

Il destinatario riceve un'email con il pulsante **Vedi il trasferimento**. Finché non accetta, non cambia nulla: il server resta nella tua organizzazione e funziona come prima. La **Zona pericolosa** mostra a chi è offerto il server e fino a quando.

Alcune regole:

- Puoi inviare un trasferimento solo quando sul server non è in corso nessuna attività, come un deployment o il provisioning.
- Un server ha un solo trasferimento aperto alla volta. Inviarne uno nuovo sostituisce l'offerta precedente, e il vecchio link smette di funzionare.
- Puoi inviare un trasferimento al tuo indirizzo email solo se sei membro di un'altra organizzazione, per spostarci il server.
- Quando il trasferimento viene accettato, la tua organizzazione perde l'accesso: le chiavi SSH della tua organizzazione e dei suoi membri vengono rimosse dal server, e cambiano la password sudo del server e gli URL di deploy dei siti. Vedi *Come perde l'accesso la vecchia organizzazione?* più sotto.

## Per quanto tempo vale un trasferimento?

Sette giorni. Dopo, il link non funziona più e, se serve, invii un nuovo trasferimento. Il link smette di funzionare anche quando il trasferimento è stato accettato o annullato, o quando il server non è più nell'organizzazione da cui è stato offerto.

Per ritirare un'offerta, fai clic su **Annulla il trasferimento** nella **Zona pericolosa** delle impostazioni del server. I trasferimenti scaduti vengono eliminati automaticamente.

## Accettare un trasferimento

1. Apri il link nell'email. Se non hai effettuato l'accesso, scegli **Accedi** o **Crea account** con l'indirizzo email a cui è stato inviato il trasferimento; poi torni al trasferimento.
2. La pagina **Prendi in carico …** mostra il server, il suo indirizzo IP e il numero di siti. In **Prima di accettare** elenca per questo server **Cosa facciamo noi per te** e **Da fare ancora tu** (vedi sotto), poi cosa resta indietro.
3. In **Nell'organizzazione**, scegli l'organizzazione in cui spostare il server. Compaiono solo le organizzazioni in cui puoi creare server.
4. Fai clic su **Accetta il server**.

Il server e i suoi siti contano per il [piano](https://ops.vimonto.com/docs/it/organization/billing) dell'organizzazione in cui lo sposti: con il piano gratuito l'accettazione viene rifiutata se non ci stanno.

Il server viene spostato subito e la sua pagina si apre nella tua organizzazione. Se sul server è ancora in corso qualcosa, aspetta un minuto e riprova. Se non hai un'organizzazione che può ricevere il server, creane prima una (vedi [organizzazioni](https://ops.vimonto.com/docs/it/organization/organizations)).

Subito dopo l'accettazione ricevi un'email, **… ora è tuo: cosa fare adesso**, con le stesse due liste e un pulsante **Visualizza server**. La nuova password sudo non c'è: arriva in un'email separata appena viene impostata.

## Cosa si sposta con il server?

Si sposta tutto ciò che si trova sul server: i siti con i loro domini, certificati, environment, script di deploy e cronologia dei deployment, i database e gli utenti del database, le versioni di PHP, i [processi](https://ops.vimonto.com/docs/it/servers/processes), i [job pianificati](https://ops.vimonto.com/docs/it/servers/scheduler), le regole del firewall, il monitoraggio e le sue impostazioni. Le chiavi SSH non si spostano, tranne quelle della tua organizzazione e dei suoi membri (vedi sotto).

Si spostano anche la coppia di chiavi del server e la sua chiave host SSH, quindi Vimonto Deploy continua a collegarsi come prima.

## Cosa resta nella vecchia organizzazione?

Ciò che appartiene all'organizzazione e non al server non si sposta:

| Cosa | Cosa succede |
| --- | --- |
| **Account del provider** | Il server non è più collegato all'account cloud con cui è stato creato. Continua a funzionare lì e viene ancora fatturato a quell'account: spostalo tu dal provider se serve. Dalla nuova organizzazione, eliminarlo interrompe solo la gestione; la macchina presso il provider non può più essere eliminata. |
| **Connessioni Git** | I siti perdono la loro connessione [Git](https://ops.vimonto.com/docs/it/connections/source-control), e il **Quick deploy** viene disattivato. |
| **Backup** | Le pianificazioni dei backup e il loro elenco di backup vengono rimossi. I file di backup restano nello storage della vecchia organizzazione. |
| **Team** | Il server viene tolto dai [team](https://ops.vimonto.com/docs/it/organization/teams) della vecchia organizzazione. |
| **Load balancer** | I collegamenti tra questo server e i load balancer della vecchia organizzazione vengono rimossi in entrambe le direzioni, e la configurazione Nginx dei siti interessati viene riscritta. Vedi [bilanciamento del carico](https://ops.vimonto.com/docs/it/sites/load-balancing). |

Il trasferimento viene registrato nel [registro di audit](https://ops.vimonto.com/docs/it/organization/audit-log) di entrambe le organizzazioni: l'invio, l'annullamento e l'accettazione.

## Come perde l'accesso la vecchia organizzazione?

Nel momento in cui il server si sposta, e in un'attività subito dopo, Vimonto Deploy toglie l'accesso che la vecchia organizzazione ha ancora:

| Cosa | Cosa succede |
| --- | --- |
| **URL di deploy** | Ogni sito riceve subito un nuovo URL di deploy. Il vecchio URL non funziona più, quindi la vecchia organizzazione non può più avviare deployment dalla sua CI o dal suo webhook Git. |
| **Chiavi SSH** | L'attività **Proteggi** *server* **dopo il trasferimento** rimuove ogni chiave che Vimonto Deploy ha messo sul server e che non è una chiave della nuova organizzazione o una chiave dell'account di uno dei suoi membri: le chiavi della vecchia organizzazione, quelle dei suoi membri e le chiavi aggiunte nella pagina **Chiavi SSH** del server. Poi aggiunge le [chiavi SSH](https://ops.vimonto.com/docs/it/connections/ssh-keys) della nuova organizzazione. |
| **Password sudo** | La stessa attività dà all'utente di sistema una nuova password sudo. Solo chi ha accettato la vede, una volta, nella finestra **Password di** *server* della panoramica, e ne riceve una copia via email. Vedi [impostazioni del server](https://ops.vimonto.com/docs/it/servers/server-settings). |
| **Avvisi** | [Monitor e heartbeat](https://ops.vimonto.com/docs/it/servers/monitoring) scrivono da quel momento a chi ha accettato invece che ai vecchi indirizzi. |
| **Comando di collegamento** | Un VPS personalizzato che aspettava ancora il suo comando di collegamento ne riceve uno nuovo; quello vecchio non funziona più. |

Nella panoramica il nuovo proprietario vede **Questo server ti è stato trasferito**, con cosa è stato fatto e cosa resta da fare. Se l'attività non è riuscita, per esempio perché il server non era raggiungibile, fai clic su **Riprova**. Fai clic su **Ho capito** per nascondere l'avviso.

Vimonto Deploy non cambia ciò che metterebbe offline i tuoi siti o ciò che non conosce: la password del database (i siti la leggono dal loro ambiente), i segreti nell'ambiente dei siti come `APP_KEY` e gli accessi configurati sul server al di fuori di Vimonto Deploy. Anche gli URL di ping degli heartbeat restano gli stessi, perché li chiamano i job pianificati sul server, e le deploy key dei siti possono ancora leggere i repository della vecchia organizzazione finché questa non le rimuove dal suo host Git.

## Dopo l'accettazione: cosa deve fare il nuovo proprietario?

La lista **Da fare ancora tu** nella pagina di accettazione, nell'email e nell'avviso della panoramica mostra i punti qui sotto che valgono per il tuo server.

- **Ricollega Git.** Collega i siti a una tua connessione Git e riattiva il **Quick deploy** dove lo vuoi. Vedi [deployment](https://ops.vimonto.com/docs/it/sites/deployments). La deploy key dei siti può ancora leggere il repository della vecchia organizzazione finché non la rimuove dal suo host Git.
- **Salva la nuova password sudo** dalla finestra **Password di** *server* nella panoramica, poi fai clic su **Le ho salvate**. Accettando diventi il creatore del server nella panoramica, quindi solo tu la vedi lì (**Mostra una volta**).
- **Aggiorna la tua CI.** Ogni sito ha un nuovo URL di deploy: copialo dalla pagina **Deployment** del sito nella tua CI.
- **Pianifica i backup** verso il tuo storage nella pagina [backup](https://ops.vimonto.com/docs/it/servers/backups).
- **Cambia la password del database** se il server ha un database: nella pagina **Database** fai clic su **Cambia password** sull'utente di sistema, poi inserisci la nuova password nel `.env` dei siti che la usano. Vimonto Deploy non la cambia per te, perché i siti la leggono dal loro `.env` e andrebbero offline. Cambia anche gli altri segreti che il vecchio proprietario conosce, come `APP_KEY` e le chiavi API.
- **Ricrea gli heartbeat se i loro URL devono restare segreti.** Gli URL di ping degli [heartbeat](https://ops.vimonto.com/docs/it/servers/monitoring) restano gli stessi, perché li chiamano i job pianificati sul server; quindi la vecchia organizzazione li conosce. Elimina gli heartbeat nella pagina **Monitoring**, aggiungili di nuovo e inserisci i nuovi URL nei tuoi job.
- **Controlla gli accessi al di fuori di Vimonto Deploy.** Le chiavi aggiunte a mano in `authorized_keys` e gli utenti Linux in più non sono noti a Vimonto Deploy e restano. Rimuovili se serve.
- **Aggiungilo ai tuoi team** se i membri della tua organizzazione vedono solo i server dei loro team. Fino ad allora lo vedono solo i membri che vedono tutti i server.
- **Configura di nuovo il bilanciamento del carico** se il server era dietro un load balancer.

## Domande frequenti

### Il server va offline durante un trasferimento?

No. Un trasferimento cambia solo l'organizzazione che gestisce il server in Vimonto Deploy. Sul server non viene eseguito nulla e i suoi siti continuano a servire i visitatori.

### Posso spostare un server tra le mie organizzazioni?

Sì. Invia il trasferimento al tuo indirizzo email, apri il link e scegli l'altra organizzazione in **Nell'organizzazione**. Ti serve il permesso di eliminare server nella prima organizzazione e di crearne nella seconda.

### La vecchia organizzazione può ancora accedere al server?

Non tramite Vimonto Deploy: i suoi URL di deploy smettono subito di funzionare, e le sue chiavi SSH e la vecchia password sudo vengono rimosse dal server subito dopo. Restano come prima solo ciò che è stato configurato al di fuori di Vimonto Deploy e la password del database; cambiali tu. Finché la macchina è nel loro account del provider, la vecchia organizzazione può ancora gestirla lì. Anche gli URL di ping degli heartbeat restano gli stessi, finché non ricrei gli heartbeat.

### Anche la fatturazione presso il provider cloud si sposta?

No. Il server resta nell'account del provider in cui è stato creato, che continua a fatturarlo. Per spostarlo su un altro account del provider, usa la funzione di trasferimento del provider; dopo viene gestito in Vimonto Deploy come un [VPS personale](https://ops.vimonto.com/docs/it/servers/custom-vps).

### E se il destinatario non accetta mai?

Allora non succede nulla. Il trasferimento scade dopo sette giorni e il server resta dov'è. Puoi anche annullarlo prima con **Annulla il trasferimento**.