Subentro sito web: cosa deve includere il passaggio da un altro fornitore

Il subentro di un sito web viene spesso raccontato come se bastasse cambiare referente. In realta il passaggio da un altro fornitore e una fase operativa precisa, con asset da recuperare, responsabilita da chiarire e rischi da ridurre prima di parlare di manutenzione o supporto continuativo.

La prima parte del passaggio riguarda controllo e proprieta. Dominio, DNS, hosting, CMS, repository, backup, analytics, account email collegati, tool pubblicitari e servizi terzi non dovrebbero restare distribuiti tra accessi incompleti o account personali del vecchio fornitore. Se questo punto non e chiuso, il subentro non e ancora finito.

La seconda parte riguarda lo stato reale del progetto. Versioni, plugin, dipendenze, automazioni, form, tracking, integrazioni e logica dei deploy vanno letti per distinguere cio che e sano da cio che richiede riordino. Il nuovo fornitore non dovrebbe ereditare un problema opaco dentro un canone mensile generico.

C e poi il backlog, che spesso pesa piu dei singoli bug. Molti passaggi ereditano richieste lasciate a meta, pagine mai completate, CTA incoerenti, automazioni interrotte, micro fix rinviati e attivita che nessuno ha piu ricontestualizzato. Se questo backlog non viene nominato e separato, il supporto ricorrente parte gia fuori fuoco.

Un subentro serio dovrebbe quindi chiarire almeno cinque blocchi. Primo: che cosa viene trasferito davvero. Secondo: quali accessi mancano o vanno rigenerati. Terzo: quali criticita richiedono intervento immediato. Quarto: quale backlog resta aperto dopo la presa in carico iniziale. Quinto: quali attivita, solo dopo questo passaggio, possono diventare manutenzione, ticket o supporto evolutivo.

Qui serve anche una distinzione commerciale pulita. La presa in carico iniziale non coincide con il supporto mensile. Il primo blocco serve a mettere sotto controllo il progetto e togliere ambiguita. Il secondo ha senso solo quando il sito e gia abbastanza leggibile da sostenere continuita ordinaria, richieste operative o miglioramenti progressivi.

Per questo il subentro non va venduto come formula rassicurante buona per tutto. Va trattato come una fase con deliverable chiari: mappa accessi, verifica asset, lettura rischi, backlog iniziale e proposta di next step. Solo dopo si decide se il progetto richiede audit, ticket, manutenzione tecnica, SLA o supporto evolutivo.

La domanda utile quindi non e solo chi prende in mano il sito. La domanda utile e che cosa viene davvero rimesso sotto controllo nel passaggio e quale parte del lavoro resta fuori dal ricorrente per non trasformare il subentro in un canone che assorbe problemi vecchi senza renderli leggibili.