Cambio fornitore sito web: checklist di migrazione prima del supporto

Quando cambi fornitore per un sito web, il rischio piu comune e trattare tutto come se bastasse aprire un nuovo canale di supporto. In realta il cambio fornitore e una migrazione: sposta accessi, responsabilita, strumenti e continuita operativa. Se questa fase resta implicita, il progetto entra subito in una zona grigia.

La checklist piu utile parte dagli asset critici. Dominio, DNS, hosting, CMS, repository, backup, analytics, form, email collegate, account pubblicitari, tag manager e servizi terzi dovrebbero avere proprieta e accessi leggibili prima della presa in carico. Se uno di questi blocchi resta opaco, non stai ancora comprando supporto. Stai ancora mettendo in sicurezza il passaggio.

Il secondo controllo riguarda la migrazione tecnica vera. Conviene chiarire dove vive oggi il sito, come viene pubblicato, quali dipendenze usa, se esistono ambienti separati, quali plugin o librerie sono davvero indispensabili e quale finestra di intervento riduce il rischio di blocchi. Senza questa lettura una migrazione puo sembrare semplice e poi spostare il problema sul primo mese di canone.

Il terzo controllo riguarda continuita e rollback. Prima di cambiare fornitore dovresti sapere che cosa succede se un form smette di funzionare, se un DNS propaga male, se un deploy rompe una parte del funnel o se manca ancora un accesso. Una migrazione seria non promette solo passaggio. Prevede anche un piano di ritorno o almeno una sequenza di ripristino minima.

Poi c e la parte commerciale, che spesso viene trascurata. Se il sito eredita CTA deboli, tracciamento incompleto, contenuti datati o un backlog mai chiuso, il nuovo fornitore rischia di ricevere richieste che sembrano supporto ma appartengono ancora al riordino iniziale. Separare migrazione, backlog e presidio continuativo rende il preventivo molto piu onesto.

Per questo una checklist di cambio fornitore dovrebbe chiarire almeno sei punti. Primo: quali asset passano davvero di mano. Secondo: quali accessi mancano. Terzo: quali criticita tecniche vanno risolte prima della messa sotto controllo. Quarto: quale finestra di migrazione e realistica. Quinto: quale piano di rollback esiste. Sesto: che cosa, solo dopo questo passaggio, puo diventare ticket, manutenzione o supporto evolutivo.

Se oggi stai uscendo da un rapporto poco leggibile con il vecchio fornitore, il passo corretto non e quasi mai comprare un mensile alla cieca. Conviene prima nominare bene la migrazione, definire deliverable iniziali e chiudere il perimetro del subentro. Solo dopo ha senso decidere se il sito richiede audit, ticket, manutenzione tecnica o un supporto piu continuo.

La domanda utile quindi non e solo chi prendera in mano il sito. La domanda utile e se il cambio fornitore ha gia una checklist abbastanza concreta da evitare che ownership, backlog e rischi operativi finiscano nascosti dentro un canone generico.