Una delle cose che mi danno più soddisfazione è far risparmiare le persone. Quando sposti un dominio da un’agenzia che chiede una marea di soldi a un provider dove paga direttamente il cliente, di solito sono contento.
Quella volta no. È stata critica. E il nome del provider era OVH Cloud.
Il punto di partenza
L’agenzia aveva fatto comprare alla cliente il dominio su OVH; il sito, però, stava sui loro server. La mossa «semplice» sembrava: prendere spazio anche su OVH e copiarci il sito, così nome e hosting tornavano sotto lo stesso tetto.
Sembrava.
In queste operazioni il sito si clona di solito su un dominio temporaneo. Fin qui niente di strano: la copia andò a buon fine.
Il guaio è iniziato quando abbiamo dovuto collegare il dominio vero al sito.
Su Aruba è un tasto. Qui no
Premessa onesta: Aruba ha difetti seri — pannello affollato, rinnovi, limiti sullo shared — e ne ho scritto senza fare il tifo cieco. Ma su questa operazione (agganciare dominio e hosting nello stesso ecosistema) da loro è spesso un percorso chiaro, a volte un tasto.
Su OVH Cloud, in quel caso: l’assistenza manda un link a una guida nebulosa e dice apertamente che non forniscono quel tipo di servizio.
Intanto il sito era offline.
Guide, MFA e tre giorni (anzi cinque)
Seguo la guida. Niente.
Riscrivo all’assistenza. Ah, dimenticavo: l’account OVH era della cliente, con l’autenticazione a due fattori sul suo telefono. Per entrare nel pannello o per aprire/seguire un ticket dovevo far sbloccare lei il login (o passarmi il codice) ogni volta. Non una volta sola: a ogni messaggio, a ogni tentativo. Lei aveva pagato uno spostamento di sito/dominio, non un contratto in cui gestivo io l’account in modo continuativo — quindi ogni «serve di nuovo il 2FA» era un disturbo in più, mentre il sito restava spento.
L’assistenza, dal canto suo, non entra nel merito operativo: non può (o non vuole) fare lo switch al posto tuo. Ti manda le guide. Erano diventate due. La seconda nebulosa come la prima — sembrava tradotta male, forse dall’IA.
Ancora niente. Il sito finiva sull’Index of: cartella sbagliata sul server (document root / path non allineati al dominio).
Terza guida. Ne mancava un pezzo; bisognava notare un particolare sulle immagini dello screenshot. Il sito va online… con l’indirizzo sbagliato: quello del dominio provvisorio, non il dominio della cliente.
Quarta guida. Alla fine il sito funziona sul nome giusto.
Totale: tre giorni lavorativi più sabato e domenica. Circa cinque giorni di sito offline — tra guide incomplete e il continuo dover richiamare la cliente per lo sblocco 2FA.
Ne ho parlato anche nei commenti sotto questo post su LinkedIn.
Perché lo eviterei
Morale per me, dopo quella epopea: per il lavoro che faccio io — siti WordPress, migrazioni, clienti che devono poter pagare e capire — OVH Cloud lo eviterei, almeno come «casa semplice» dove copiare un sito e sperare che il dominio si aggancia da solo. Non perché «non esiste chi ci sta bene». Perché quando va male, il costo non è la tariffa: sono i giorni di sito spento e le guide che non chiudono il cerchio.
Se stai uscendo da un’agenzia e il dominio è già su OVH, valuta se conviene davvero restare lì solo per non cambiare registrar, o se paghi meno (in tempo e nervi) spostando nome e spazio dove l’aggancio è un percorso umano. Ne ho scritto anche in chiave pratica su trasferimento di dominio (migrazione).
Hai un sito bloccato su OVH (o un dominio lì e l’hosting altrove) e non vuoi altri cinque giorni offline? Scrivimi dalla pagina contatti — si capisce in poco tempo se conviene restare o migrare.