Cambiare fornitore, riprendere un software dopo la partenza di uno sviluppatore chiave o recuperare un'applicazione acquisita non consiste solo nel trasferire un repository Git. Un'applicazione in produzione dipende da un insieme molto più ampio: account cloud, certificati, attività pianificate, backup, servizi di terze parti, procedure operative, conoscenza aziendale e decisioni storiche.
Le prime settimane determinano la qualità della relazione futura. Un team che inizia subito a sviluppare nuove funzioni senza garantire questo ambiente rischia di scoprire le dipendenze nel momento meno favorevole: durante un incidente o un rilascio in produzione.
Il metodo dei 90 giorni mira a riprendere il controllo senza immobilizzare inutilmente il prodotto. Combina sicurezza, comprensione, stabilizzazione e costruzione di una roadmap.
Prima del trasferimento: definire ciò che deve effettivamente essere consegnato
La reversibilità deve essere preparata prima della data di passaggio. La prima lista riguarda gli asset: codice sorgente, cronologia, ticket, documentazione, schemi, file di progettazione, test, script di deployment, immagini dei container e licenze.
La seconda riguarda gli accessi: hosting, DNS, certificati, database, archiviazione, email transazionale, strumenti di supervisione, CDN, registri di pacchetti, account mobili, store di applicazioni, servizi di pagamento, piattaforme analitiche e backup. Per ogni accesso, è necessario conoscere il proprietario legale, gli amministratori, il metodo di recupero e il processo di rotazione.
La terza riguarda il funzionamento aziendale. Quali percorsi non possono essere interrotti? Quali operazioni richiedono un trattamento manuale? Quali scambi sono attesi dai partner? Quali incidenti si ripetono? Quali impegni sono stati presi verso gli utenti?
Un inventario incompleto non impedisce sempre la ripresa. Tuttavia trasforma le aree mancanti in rischi espliciti e in compiti prioritari.
Fase 1 — G0 a G15: garantire e rendere osservabile
Il primo passo non consiste a « pulire il codice ». Consiste ad assicurarsi che l'applicazione possa essere osservata, salvata e recuperata.
Il team conferma gli accessi, rimuove gli account obsoleti, attiva l'autenticazione rafforzata quando possibile e organizza la rotazione dei segreti. Verifica i backup, la loro conservazione e soprattutto la possibilità di ripristino. Elenca i certificati e gli abbonamenti che potrebbero scadere silenziosamente.
Parallelamente, ricostruisce il percorso di messa in produzione: costruzione, configurazione, migrazioni del database, deployment, pulizia delle cache, riavvio dei worker e rollback. Una prima esecuzione deve essere effettuata su un ambiente non produttivo. Se questo percorso non è riproducibile, ogni evoluzione è temporaneamente classificata come rischiosa.
La supervisione deve coprire i segnali essenziali: disponibilità, tasso di errore, tempo di risposta, saturazione, spazio su disco, code, fallimento dei compiti pianificati e salute dei backup. L’obiettivo non è installare immediatamente una piattaforma complessa, ma evitare che un incidente venga scoperto dal cliente finale.
Consegne della fase: inventario degli accessi, elenco dei rischi immediati, procedura di contatto, prova di backup, mappa semplificata dell'operazione e primo cruscotto.
Fase 2 — Dal giorno 15 al giorno 45: comprendere e documentare
Una volta assicurata la continuità minima, il team ricostruisce l'architettura e le principali regole di business. Installa il progetto su un ambiente pulito, esegue i test, osserva i log e segue alcune richieste reali dall'inizio alla fine.
Le interviste sono brevi e mirate. Il lavoro descrive le operazioni critiche e le eccezioni. Il vecchio fornitore, quando è disponibile, spiega le zone sensibili, le procedure non documentate e le scelte che sembrano strane senza il loro contesto. L'esercizio descrive gli incidenti ricorrenti e le manipolazioni manuali.
Il codice viene analizzato secondo le nove dimensioni di un audit tecnico: architettura, manutenibilità, dipendenze, sicurezza, dati, prestazioni, test, gestione e trasferibilità. L'obiettivo non è ancora correggere ogni difetto, ma sapere dove una modifica è sicura e dove richiede protezioni aggiuntive.
La documentazione prodotta deve essere immediatamente utile: avvio locale, architettura, flussi esterni, procedure di distribuzione, ripristino, attività programmate, matrice degli ambienti e glossario del settore. Una documentazione esaustiva ma mai riletta è meno utile di una guida breve verificata da una nuova persona.
Deliverables della fase: mappatura, guida all'uso, registro delle dipendenze, audit iniziale e elenco delle incognite rimanenti.
Fase 3 — G45 a G90: stabilizzare e ripristinare la capacità di evoluzione
La terza fase tratta i rischi che impediscono di lavorare normalmente. Le correzioni prioritarie riguardano generalmente i backup, i permessi, le dipendenze vulnerabili, gli errori silenziosi, le attività instabili e le procedure di distribuzione.
I percorsi professionali più delicati sono protetti da test di caratterizzazione. Questi test descrivono il comportamento attuale, anche quando il codice non è ancora ideale. Permettono poi di modificare progressivamente senza reinventare le regole.
Il team costruisce anche una strategia di aggiornamento. Le dipendenze sono classificate tra aggiornamenti semplici, migrazioni da preparare e componenti da sostituire. I miglioramenti delle prestazioni sono basati su misurazioni. Le richieste funzionali in sospeso vengono riclassificate alla luce dei nuovi vincoli tecnici.
Infine, le parti interessate convalidano una road map in tre orizzonti: sicurezza, modernizzazione ed evoluzione del prodotto. Ogni progetto specifica il suo beneficio, il suo rischio, le sue dipendenze e la sua portata.
Deliverables della fase: versione stabilizzata, copertura dei test prioritaria, pipeline di consegna affidabile, backlog classificato e roadmap arbitrabile.
Dopo 90 giorni: passare a una manutenzione controllata
La manutenzione corrente si basa su un quadro visibile. Le richieste sono qualificate, gli incidenti hanno una procedura, i cambiamenti sono tracciabili e le versioni sono soggette a una politica. Gli indicatori riguardano la qualità del servizio, non solo il numero di ticket chiusi.
Un funzionamento sano segue in particolare: disponibilità dei percorsi critici, tempo di rilevamento, tempo di ripristino, tasso di fallimento dei deployment, età delle dipendenze, copertura dei percorsi a rischio e volume di lavoro non pianificato.
La conoscenza deve rimanere distribuita. Le riviste, i resoconti, le procedure testate e le rotazioni di reperibilità evitano di ricreare una dipendenza da una sola persona presso il nuovo fornitore.
La cronologia inizia prima del trasferimento con l'inventario degli asset, degli accessi e delle regole di business. Da J0 a J15, la priorità è garantire la sicurezza degli accessi, dei backup, dei deployment e della supervisione. Da J15 a J45, il team ricostruisce l'architettura, documenta l'operatività e identifica gli elementi sconosciuti. Da J45 a J90, stabilizza i rischi prioritari, protegge i percorsi sensibili tramite test e costruisce la roadmap. Il regime corrente poi mantiene la qualità del servizio e la conoscenza condivisa.
Gli scenari difficili e la risposta adeguata
Il vecchio fornitore non collabora
Iniziate proteggendo ciò che appartiene al cliente: domini, account contrattuali, dati, depositi e backup. Documentate ogni elemento mancante e il suo impatto. Evitate accuse tecniche non verificate; concentrate gli scambi sui beni e sugli obblighi di reversibilità.
Il team di ripristino dovrà ricostruire una parte della conoscenza a partire dal codice, dalle configurazioni, dai registri e dagli utenti. Questo lavoro deve essere pianificato come tale, e non assorbito silenziosamente nella manutenzione.
Il codice non contiene alcun test
Sarebbe imprudente avviare immediatamente una rifattorizzazione generale. Identificate i percorsi ad alto impatto, catturate il loro comportamento attuale e aggiungete test attorno alle interfacce stabili. I registri, copie anonime dei dati e test end-to-end possono offrire una prima protezione prima di una copertura più dettagliata.
L'alloggio non è documentato
Stabilite una mappa dall'esterno verso l'interno: DNS, CDN, firewall, bilanciatori, server, container, database, storage, task e servizi esterni. Controllate le fatture e le console per individuare le risorse invisibili nel codice. Non cancellate nulla senza un periodo di osservazione e prova di inutilità.
L'applicazione sta già subendo degli incidenti
Separate il flusso « ripristinare il servizio » dal flusso « comprendere e modernizzare ». Mettete in atto una cellula di incidente, priorità temporanee e un congelamento dei cambiamenti non essenziali. Ogni incidente deve arricchire la mappatura e le protezioni piuttosto che scatenare una successione di correzioni isolate.
Ciò che il cliente deve conservare al termine del ritiro
Un ritorno riuscito non si misura solamente dal fatto che il nuovo fornitore sappia intervenire. Il cliente deve ritrovare il controllo dei propri beni e delle proprie decisioni. Deve disporre di un inventario dei conti, di una documentazione minima verificata, di una visibilità sui rischi, di una procedura di uscita e di un budget comprensibile.
Gli ambienti devono essere riproducibili, i backup ripristinabili, le messa in produzione tracciabili e gli accessi nominativi. Il backlog deve distinguere manutenzione correttiva, debito tecnico, sicurezza, evoluzioni e richieste di business.
Il valore di una ripresa progressiva
La tentazione è forte di approfittare del cambio di team per riscrivere tutto. Tuttavia, i primi 90 giorni rivelano spesso che alcune fondamenta sono affidabili, che le regole aziendali sono più complesse del previsto e che le urgenze non si trovano dove si pensava.
Una ripresa strutturata preserva ciò che funziona, riduce prima i rischi e crea le condizioni per una modernizzazione razionale. Partitech sa riprendere la manutenzione di progetti sviluppati da terzi e accompagnarne l’evoluzione nel tempo, dalla verifica all’hosting e alla gestione informatizzata.
Per inquadrare la transizione, iniziate con un audit tecnico completo dell'applicazione, poi scopri come preparare la reversibilità e il cambio del fornitore. L'offerta Manutenzione, evoluzioni e hosting e il nostro riferimento di piattaforma aziendale finanziaria accompagnata nel tempo completano questa procedura.
Riferimenti ufficiali
Riferimenti verificati il 17 agosto 2026 :