Il cambio di hosting è una di quelle cose che nessun imprenditore ha voglia di affrontare. Il sito funziona, più o meno, e l'idea di spostarlo evoca immagini di pagine bianche, mail che smettono di arrivare e clienti che chiamano per dire che il sito non si apre. Lo capisco, e in parte la paura è giustificata: ho visto migrazioni fatte male che hanno tenuto un'azienda offline per due giorni in piena stagione.
La buona notizia è che, fatta con metodo, una migrazione non si vede da fuori. Nei siti che ho spostato negli ultimi anni l'interruzione percepita dai visitatori è stata zero nella quasi totalità dei casi. Non perché io sia bravo, ma perché esiste un ordine delle operazioni che elimina i rischi grossi, e chi va in crisi di solito è perché ha saltato dei passaggi o ha fatto le cose in sequenza sbagliata.
Ti racconto come procedo, senza nascondere le parti che possono andare storte, così che se ti tocca farlo tu sappia cosa chiedere a chi te lo fa e come accorgerti in tempo che qualcosa non torna. Te lo scrivo pensando a un sito aziendale normale, con qualche decina di pagine, un modulo di contatto, magari un piccolo negozio. Per i siti enormi valgono gli stessi principi, ma con più precauzioni sui dati che cambiano in continuazione.
Prima di tutto: perché vuoi cambiare
Non parto mai dal come, parto dal perché, perché in un caso su tre scopro che il problema non è l'hosting. Mi chiamano dicendo che il sito è lento e che quindi bisogna cambiare server, e poi guardando trovo un tema pesantissimo, venti plugin attivi di cui metà inutilizzati e immagini caricate a piena risoluzione da tre megabyte l'una. In quella situazione puoi comprare il server più potente del mondo e il sito resta lento: cambiare hosting sarebbe spendere soldi per spostare il problema.
I motivi per cui invece il cambio ha senso li ho visti essere sostanzialmente questi. Il fornitore attuale non risponde quando c'è un problema, e per un sito che porta lavoro è un motivo sufficiente da solo. Il server è davvero sottodimensionato e si vede nei momenti di traffico. Il servizio è su una tecnologia vecchia che non supporta le versioni aggiornate del software, e questo prima o poi diventa un problema di sicurezza. Oppure il sito è in mano a un'agenzia che non collabora e vuoi riprenderti il controllo, che è la situazione più delicata di tutte.
Quest'ultimo caso merita una parentesi. Mi capita regolarmente che un'azienda voglia spostare il sito perché ha chiuso il rapporto con chi glielo gestiva. Prima ancora di parlare di tecnica, la domanda è: il dominio a nome di chi è registrato? Se è intestato all'agenzia e non a te, la migrazione diventa una trattativa prima che un lavoro tecnico. Controllalo adesso, anche se non hai nessuna intenzione di cambiare: è la cosa più importante che possiedi di tutto il progetto ed è quella che le aziende scoprono di non avere sempre nel momento peggiore.
La preparazione, che è il novanta per cento del lavoro
Prima di toccare qualsiasi cosa faccio un inventario, e lo faccio scritto. Serve a evitare le sorprese del giorno dopo, quelle in cui il sito funziona perfettamente ma un pezzo che nessuno ricordava è rimasto indietro. Le cose che metto sempre nella lista sono queste.
- Dove è registrato il dominio e chi ha le credenziali per modificarlo.
- Se le caselle di posta sono sullo stesso fornitore dell'hosting, perché in quel caso vanno spostate anche loro e sono la parte più delicata.
- Che versione del linguaggio e del database gira il sito oggi.
- Quali certificati di sicurezza sono attivi e come sono stati emessi.
- Quali servizi esterni si collegano al sito: gestionali, sistemi di prenotazione, fatturazione, sistemi di pagamento.
- Se ci sono attività pianificate che girano a orari fissi, tipo invii automatici o sincronizzazioni notturne.
- Quanto pesa il sito in totale e quanto è grande il database.
La voce che sottovalutano tutti è la posta. Molte aziende hanno le mail aziendali sullo stesso servizio dove sta il sito e non se ne rendono conto. Se sposti solo il sito cambiando l'indirizzamento del dominio senza occuparti della posta, la mattina dopo smettono di arrivare le mail e succede il finimondo. Il sito giù per un'ora è un fastidio, la posta persa per mezza giornata è un problema serio con clienti e fornitori. Quando il cliente ha la posta lì dentro, di solito consiglio di spostare prima la posta su un servizio dedicato, aspettare qualche giorno che tutto sia stabile, e solo dopo occuparsi del sito.
L'altra voce da controllare bene sono i servizi esterni collegati. Se il tuo negozio online parla con un gestionale, quasi sempre esiste un elenco di indirizzi autorizzati da aggiornare, altrimenti dopo lo spostamento la sincronizzazione si blocca in silenzio e te ne accorgi tre giorni dopo con il magazzino sballato. Stessa cosa per i sistemi di pagamento, che a volte hanno l'indirizzo del server memorizzato nelle impostazioni.
La sequenza che uso
Arriviamo al lavoro vero. L'idea di fondo è semplice: costruisco il sito nuovo sul server nuovo, lo provo per bene mentre il vecchio continua a funzionare normalmente, e solo alla fine sposto il traffico. Nessuno vede niente finche non sono sicuro.
- Copia completa di file e database dal vecchio server, verificata scaricandola in locale.
- Caricamento della copia sul nuovo server, con la stessa versione del linguaggio o una compatibile.
- Prova del sito nuovo tramite un indirizzo temporaneo o una modifica locale, senza toccare il dominio pubblico.
- Controllo pagina per pagina delle parti che possono rompersi: moduli, carrello, area riservata, pagine con mappe o integrazioni.
- Abbassamento del tempo di aggiornamento dei parametri del dominio, almeno ventiquattro ore prima del cambio.
- Blocco delle modifiche al sito vecchio nelle ore prima dello switch, per evitare disallineamenti.
- Sincronizzazione finale delle sole cose cambiate, tipicamente ordini e commenti recenti.
- Cambio dei parametri del dominio verso il nuovo server.
- Emissione del nuovo certificato di sicurezza e controllo che sia valido.
- Verifiche post cambio e sito vecchio lasciato acceso per almeno una settimana.
Il punto cinque è quello che la maggior parte delle persone salta e che invece fa la differenza tra una migrazione invisibile e una mezza giornata di panico. I parametri che dicono al mondo dove sta il tuo sito hanno un tempo di validità: se è impostato su ventiquattro ore, dopo il cambio ci sarà gente che per un giorno intero continuerà a vedere il sito vecchio. Abbassando quel valore a pochi minuti il giorno prima, il passaggio avviene in modo quasi istantaneo per tutti. È una cosa che si fa in due minuti e che quasi nessuno fa.
Il punto dieci è l'altro che conta: non spegnere mai il vecchio server subito. Costa pochi euro tenerlo acceso una o due settimane, ed è la tua rete di sicurezza. Se dopo tre giorni scopri che mancava una cartella di allegati, la vai a prendere. Se hai già chiuso il contratto, quella roba è persa. Ho recuperato più di un sito grazie a questa precauzione e ho visto disastri causati dalla fretta di disdire per risparmiare un mese di canone.
Cosa è andato storto, le volte che è andato storto
Le migrazioni difficili che ricordo hanno tutte una radice comune: qualcosa di cui nessuno mi aveva parlato. Non è mai stata la copia dei file a creare problemi, è sempre stato un pezzo nascosto del sistema.
Il primo caso è stato un sito con un modulo di preventivo che salvava i file caricati dai clienti in una cartella fuori dal percorso normale del sito, scelta fatta anni prima da un altro sviluppatore per motivi che nessuno ricordava. La copia standard non l'aveva presa e ce ne siamo accorti due giorni dopo, quando un cliente ha chiesto di riavere il suo disegno tecnico. Per fortuna il vecchio server era ancora acceso. Da quella volta, prima di ogni migrazione, cerco esplicitamente se ci sono percorsi fuori standard.
Il secondo è stato un negozio online con un plugin di fatturazione la cui licenza era legata all'indirizzo del server. Dopo lo spostamento si è disattivato e ha smesso di generare le fatture, senza avvisare nessuno. Lo abbiamo scoperto a fine mese quando il commercialista ha chiesto i documenti mancanti. Adesso, tra le cose che controllo prima, c'è sempre l'elenco delle licenze attive e le loro condizioni.
Il terzo è il più banale e anche il più frequente: il sito nuovo funzionava perfettamente ma continuava a mandare le mail dal server vecchio, o peggio non le mandava affatto perché il nuovo fornitore aveva regole diverse sull'invio. Il modulo contatti sembrava funzionare, diceva grazie del messaggio, e le richieste finivano nel vuoto. Per questo oggi la prova del modulo di contatto, fatta davvero inviando un messaggio e verificando che arrivi, è il primo controllo che faccio dopo ogni cambio.
I controlli del giorno dopo
Nelle ventiquattro ore successive al cambio faccio un giro di verifiche fisso. Lo faccio anche quando sono sicuro che sia andato tutto bene, perché i problemi delle migrazioni sono quasi sempre silenziosi: il sito si vede, quindi tutti pensano che vada tutto bene, e intanto qualcosa non funziona.
| Cosa controllo | Come lo verifico | Perché conta |
|---|---|---|
| Modulo di contatto | Invio un messaggio vero e aspetto che arrivi | È il guasto più frequente e il più invisibile |
| Certificato di sicurezza | Controllo che non compaia nessun avviso nel browser | Un avviso fa scappare le persone in due secondi |
| Pagine principali | Le apro una per una da telefono e da computer | Immagini o stili possono restare collegati al vecchio server |
| Area riservata o carrello | Faccio un ordine di prova o un accesso | Sono le parti che dipendono di più dalla configurazione |
| Invio mail automatiche | Verifico conferme d'ordine e notifiche | Cambiano le regole di invio da fornitore a fornitore |
| Indicizzazione | Controllo che il sito non sia rimasto bloccato ai motori | Sui server di prova spesso il blocco è attivo di default |
| Velocità | Confronto i tempi con quelli di prima | Serve a capire se il cambio è servito davvero |
L'ultima riga della tabella ha un'importanza che va oltre la tecnica: se hai speso soldi per cambiare, devi sapere se è servito. Misura la velocità prima e dopo, sulle stesse pagine e con lo stesso strumento. In diversi casi ho visto miglioramenti evidenti, in altri il cambio ha portato benefici sulla stabilità ma non sulla velocità, perché il collo di bottiglia era nel sito e non nel server. In entrambi i casi è meglio saperlo con un numero davanti che andare a sensazione.
Sull'indicizzazione aggiungo un avvertimento, perché è l'errore che ho visto fare più spesso da chi migra da solo. Quando costruisci il sito sul server nuovo, di solito lo tieni nascosto ai motori di ricerca, giustamente. Il problema è che quella spunta va tolta dopo il cambio, e se te ne dimentichi il sito resta invisibile su Google. Il sito funziona, i clienti che conoscono l'indirizzo lo aprono, e intanto per settimane non ti trova più nessuno. Mi è capitato di essere chiamato da un'azienda che aveva perso tre mesi di visibilità per una spunta rimasta attiva.
Quanto costa farlo fare e quanto costa farlo da soli
Una migrazione di un sito aziendale normale, fatta da un professionista, è un lavoro che sta nell'ordine di poche centinaia di euro, con variazioni in base alla complessità: un piccolo negozio con integrazioni costa di più, un sito vetrina di dieci pagine costa poco. Nella cifra dovrebbe essere compreso il controllo preventivo, la prova prima del cambio, l'assistenza nelle ore successive e il mantenimento del vecchio server per un periodo.
Farlo da soli è possibile e ci sono strumenti che automatizzano buona parte del lavoro, anche in modo affidabile. Se il sito è semplice, se la posta non è coinvolta e se hai accesso a tutto, è un lavoro da mezza giornata alla portata di una persona sveglia. Le situazioni in cui sconsiglio il fai da te sono tre: quando le caselle di posta aziendali sono sullo stesso fornitore, quando c'è un negozio con ordini che arrivano di continuo, e quando il dominio non è in mano tua. In quei casi il rischio di combinare un guaio costoso supera di parecchio il risparmio.
Le domande che mi fanno più spesso
Le domande che mi fanno sempre quando si parla di spostare un sito.
Il sito resterà offline durante il cambio?
Se la migrazione è fatta nell'ordine giusto, no, e questo sorprende sempre chi se lo immagina come un trasloco in cui la casa resta vuota per qualche ora. Il trucco è che il sito nuovo viene costruito e collaudato mentre il vecchio continua a funzionare normalmente: esistono nello stesso momento in due posti. Quando si cambia l'indirizzamento del dominio, chi arriva viene mandato sul nuovo, chi ha ancora in memoria il vecchio indirizzo vede il vecchio, che funziona ancora. Per questo si tiene acceso il vecchio server. L'unico momento davvero delicato è il caso di un negozio online, dove un ordine arrivato sul vecchio server dopo la copia rischia di non essere nel nuovo: si gestisce fermando gli ordini per una finestra breve, di solito di notte, oppure sincronizzando gli ultimi dati subito prima del passaggio.
Perdo posizionamento su Google?
Non dovresti perdere niente, perché il dominio resta lo stesso e gli indirizzi delle pagine anche: da fuori non cambia nulla, cambia solo il computer su cui sta il sito. Le uniche cose che possono creare un calo sono errori, non la migrazione in se. I due più comuni sono lasciare attivo il blocco ai motori di ricerca usato durante le prove, e cambiare gli indirizzi delle pagine approfittando dell'occasione senza impostare i reindirizzamenti. Il secondo caso è più frequente di quanto sembri, perché la tentazione di sistemare anche la struttura mentre si è lì dentro è forte. Il consiglio è di fare una cosa alla volta: prima sposti, verifichi che tutto sia stabile per qualche settimana, poi eventualmente riorganizzi.
Come faccio a sapere se il mio hosting attuale è adeguato?
I segnali concreti che guardo sono pochi. Il primo è il tempo di risposta del server, cioè quanto ci mette a iniziare a mandare la pagina: se è costantemente sopra il secondo anche su pagine semplici, qualcosa non va. Il secondo è il comportamento nei momenti di traffico: se il sito rallenta o va giù quando arrivano più visite del solito, sei sottodimensionato. Il terzo è la versione del linguaggio disponibile: se il fornitore non ti offre versioni aggiornate, è un servizio vecchio e prima o poi diventa un problema di sicurezza. Il quarto, meno tecnico ma decisivo, è l'assistenza: prova a scrivere un ticket e guarda quanto ci mettono a risponderti e se ti rispondono una persona o un messaggio automatico. Il giorno che il sito sarà giù, quella sarà l'unica cosa che conta davvero.
Posso spostare il sito e tenere le mail dove sono?
Sì, si può fare tranquillamente ed è anzi la soluzione che consiglio più spesso, perché separa due problemi che non hanno motivo di stare insieme. Si tratta di configurare i parametri del dominio in modo che il traffico del sito vada al nuovo server mentre quello della posta continui a essere gestito dove sta oggi. È un'operazione normale, che chi lo fa di mestiere sistema in pochi minuti, ma va detta prima e non scoperta dopo. Aggiungo una considerazione: se le tue mail aziendali stanno su un hosting economico insieme al sito, vale la pena valutare di spostarle su un servizio di posta dedicato. Costa qualche euro al mese per casella e ti risolve una quantità di problemi che oggi forse dai per normali, dalle mail che finiscono nella posta indesiderata allo spazio che si riempie.
Ogni quanto ha senso cambiare hosting?
Non esiste una scadenza e diffido di chi te lo propone come manutenzione periodica. Un buon hosting te lo tieni per anni e non ci pensi, che è esattamente quello che deve fare un servizio del genere. I momenti in cui ha senso rivalutare sono quando il sito cresce in modo significativo, quando cambi il tipo di sito, per esempio aggiungendo un negozio a quello che era un sito vetrina, quando il fornitore peggiora in modo evidente il servizio o l'assistenza, oppure quando cambi chi se ne occupa. Quest'ultimo caso è sensato più di quanto sembri: avere il sito su un'infrastruttura che chi lo mantiene conosce bene riduce i tempi di intervento quando c'è un problema, e quando il sito è giù la differenza tra venti minuti e tre ore la senti tutta.
In sintesi: una migrazione non è un'operazione rischiosa di per sé, è un'operazione che diventa rischiosa quando si fa di fretta e senza inventario. Se ti prendi il tempo di sapere cosa hai, provi tutto prima di spostare il traffico e tieni il vecchio server acceso per qualche giorno, è uno di quei lavori che passa senza che nessuno se ne accorga. Ed è esattamente così che dovrebbe andare: la miglior migrazione è quella di cui il giorno dopo nessuno parla.
Devi spostare il sito e preferisci non rischiare?
Scrivimi dicendomi dove sta oggi il sito, se le mail aziendali sono sullo stesso servizio e che tipo di sito è: ti dico come lo farei e cosa controllerei prima di toccare qualcosa.