Caso di studio sulla migrazione di un SaaS a un VPS per passaggi di consegne più sicuri

Pubblicato il 28 settembre 2026

Il database di produzione stava superando i limiti del suo ambiente condiviso molto prima di guastarsi effettivamente. I tempi di risposta aumentavano nei periodi di maggiore affluenza, le finestre di distribuzione sembravano rischiose e il team non disponeva di una procedura di ripristino affidabile nel caso in cui un aggiornamento di un plugin o un problema del database fossero andati storti. Questo caso di studio sulla migrazione di un SaaS a un VPS segue un fornitore di software B2B composito che ha spostato la propria applicazione su un VPS gestito senza trasformare la notte della migrazione in una scommessa.

L'azienda disponeva di un portale clienti, un'API, processi worker, un database PostgreSQL e processi email in background eseguiti in un ambiente di hosting diventato troppo affollato per quel carico di lavoro. Non era la storia di un'interruzione drammatica. Sono raramente le storie più utili. Era una storia di gestione del rischio: effettuare lo spostamento prima che la crescita normale si trasformasse in un incidente.

Il punto di partenza: uno stack SaaS con poco margine

Il fornitore SaaS serviva circa 3.500 utenti attivi, con il traffico concentrato durante l'orario lavorativo negli Stati Uniti. La sua applicazione funzionava su uno stack web convenzionale: Nginx, PHP-FPM, PostgreSQL, Redis e diversi processi worker pianificati. Il team disponeva del controllo del codice sorgente e di script di distribuzione, ma l'infrastruttura si era accumulata nel consueto modo pratico: un servizio dopo l'altro, finché nessuno voleva più toccare il server di venerdì.

La pressione immediata riguardava le prestazioni del database. L'utilizzo della CPU non era costantemente elevato, ma brevi picchi facevano accumulare query lente. La contesa sull'I/O del disco compariva ogni volta che i backup venivano eseguiti in prossimità dei processi di reporting. L'applicazione riusciva generalmente a riprendersi, ma «generalmente» non è un obiettivo di ripristino.

Il team aveva inoltre bisogno di un maggiore controllo sulle versioni di PHP, sulla configurazione dei servizi, sulle regole del firewall e sul monitoraggio. L'hosting condiviso era stato utile nella fase iniziale, ma aveva raggiunto il suo limite naturale. Un VPS offriva risorse allocate dedicate e un controllo a livello root senza richiedere all'azienda di gestire hardware fisico.

C'era un vincolo che influenzava ogni decisione: le sessioni dei clienti e i flussi di lavoro a pagamento non potevano essere interrotti a lungo. Una migrazione con ore di indisponibilità era tecnicamente possibile, ma commercialmente poco allettante.

Cosa è stato verificato prima della migrazione al VPS

Prima di predisporre il nuovo ambiente, il piano di migrazione ha separato il sistema in componenti che potevano essere spostati indipendentemente da quelli che richiedevano un passaggio di consegne finale. I file statici dell'applicazione, le immagini dei container e la maggior parte della configurazione potevano essere copiati in anticipo. Il database richiedeva maggiore attenzione perché continuava a cambiare fino al passaggio di consegne finale.

Il team ha innanzitutto misurato l'utilizzo effettivo, invece di scegliere un piano VPS basandosi sull'ottimismo. Ha esaminato il picco della CPU, il consumo di RAM, le dimensioni del database, la crescita dello storage, il comportamento degli IOPS, il trasferimento di rete e il numero di processi worker simultanei. Il VPS risultante è stato dimensionato con margine per i picchi di traffico e la manutenzione, non solo con la capacità sufficiente a riprodurre le medie attuali.

È stato scelto un VPS gestito perché il team di sviluppo interno poteva occuparsi dell'applicazione, ma non voleva diventare il punto di escalation notturno per ogni avviso del sistema operativo. Vale la pena dirlo chiaramente: l'hosting VPS non gestito può costare meno sulla carta, ma trasferisce l'applicazione delle patch, il monitoraggio, la convalida dei backup e il triage degli incidenti sulle proprie persone. Per i team con personale dedicato all'infrastruttura, può essere una scelta sensata. Per un piccolo team SaaS, spesso diventa una distrazione costosa con il prezzo mensile ridotto come unica attrattiva.

Il nuovo VPS è stato sottoposto a hardening prima dell'arrivo dei dati dell'applicazione. L'accesso è stato limitato alle chiavi SSH, i servizi non necessari sono stati rimossi, le regole del firewall consentivano solo il traffico richiesto e gli aggiornamenti di sicurezza automatici sono stati verificati per la compatibilità con lo stack. Sono stati creati utenti di sistema separati per la distribuzione e i processi dei servizi. I segreti sono stati spostati fuori dalla base di codice e inseriti in file di configurazione protetti.

I backup sono stati configurati in due forme: backup fuori server pianificati per il ripristino in caso di perdita del server e backup specifici del database per un ripristino più rapido dei dati. Un backup che non è mai stato ripristinato è solo un file basato sulla speranza. Il team ha ripristinato un backup del database in un database di test isolato e ha verificato che l'applicazione potesse leggerlo correttamente.

Il piano di migrazione ha utilizzato un passaggio di consegne graduale

L'applicazione è stata distribuita sul nuovo VPS diversi giorni prima della notte della migrazione. Questo ha dato al team il tempo di confrontare il comportamento sotto un carico realistico e risolvere piccole differenze nelle estensioni PHP, nei permessi dei file, nell'esecuzione dei cron, nella configurazione di Redis e nella distribuzione delle email. Questi dettagli sono noiosi, finché non lo diventano.

Per i test end-to-end è stato utilizzato un hostname di staging. Il personale interno ha verificato l'accesso, la creazione degli account, i callback di fatturazione, il caricamento dei file, i report pianificati, l'autenticazione dell'API e il portale amministrativo. Ha inoltre testato il percorso di rollback. Questa è la parte che molte migrazioni saltano perché la pianificazione del rollback sembra pessimistica. In realtà è ciò che consente di prendere una decisione serena durante un problema.

Il passaggio di consegne finale prevedeva quattro fasi operative:

• Ridurre in anticipo il TTL del DNS affinché le modifiche ai record si propagassero più rapidamente.
• Eseguire una sincronizzazione iniziale del database mentre la vecchia piattaforma rimaneva attiva.
• Mettere le funzioni con molte operazioni di scrittura in modalità di manutenzione per la breve sincronizzazione finale.
• Aggiornare il DNS, verificare il traffico di produzione e mantenere disponibile il vecchio ambiente finché il nuovo servizio non fosse stato confermato stabile.

Il trasferimento iniziale dei dati ha spostato la maggior parte del database senza influire sugli utenti. All'orario di manutenzione concordato, il team ha sospeso le nuove scritture, eseguito una sincronizzazione incrementale finale e avviato i servizi di produzione sul VPS. La sospensione delle scritture è durata 11 minuti. Gli utenti che stavano già navigando potevano continuare a leggere la maggior parte delle pagine pubbliche e degli account, mentre azioni come l'aggiornamento dei dati di fatturazione o l'invio di nuovi record mostravano un breve avviso di manutenzione.

Questo approccio non era completamente privo di compromessi. Una migrazione con tempi di inattività quasi nulli, utilizzando la replica del database, può ridurre ulteriormente la finestra di manutenzione, ma aggiunge complessità e richiede una maggiore preparazione anticipata. Per questo fornitore SaaS, una sospensione controllata delle scritture di 11 minuti era più sicura che creare una progettazione di replica che il team non era preparato a gestire in seguito. Una buona infrastruttura non è sempre l'infrastruttura più complessa.

Cosa è successo durante il passaggio di consegne

Il record DNS è stato aggiornato dopo il controllo finale del database. Il team di migrazione ha monitorato i log di accesso, i log degli errori, le connessioni PostgreSQL, l'attività dei worker PHP-FPM, i tempi di risposta e la profondità della coda in background quando il traffico ha raggiunto il nuovo VPS.

Nella prima ora sono comparsi due problemi. Un processo di report pianificato utilizzava un percorso codificato direttamente dal vecchio server e un provider di API esterno aveva inserito nella allowlist l'indirizzo IP in uscita precedente. Nessuno dei due problemi ha richiesto un rollback. Il percorso del processo di report è stato corretto e la allowlist del fornitore è stata aggiornata utilizzando il nuovo indirizzo VPS. I log ora raccontavano la stessa storia.

Il team ha mantenuto intatto il vecchio ambiente, disabilitandovi però le scritture pubbliche. Questo ha creato un'opzione di rollback protetta, impedendo al contempo la suddivisione dei dati tra due sistemi. Dopo 24 ore di comportamento stabile dell'applicazione, backup riusciti e normale elaborazione delle code, il vecchio ambiente è stato ritirato dall'uso in produzione.

Risultati dopo il passaggio al VPS

Il vantaggio immediato è stato la costanza. Il tempo di risposta mediano dell'applicazione è migliorato perché il database e i worker web non competevano più con tenant non correlati per le risorse. Più utile del miglioramento della velocità è stata la visibilità: il team poteva vedere CPU, RAM, disco, rete, stato dei servizi e comportamento del database in un'unica vista operativa.

Il fornitore SaaS ha inoltre ottenuto una procedura di manutenzione più ordinata. Gli aggiornamenti potevano essere testati in staging prima della produzione, i backup venivano eseguiti al di fuori delle ore di punta dei report e gli avvisi avevano responsabili definiti. Grazie al supporto operativo gestito e al monitoraggio attivo di kodu.cloud, il team interno disponeva di un percorso di escalation più chiaro quando era necessario prestare attenzione al comportamento dell'infrastruttura.

La migrazione non ha eliminato ogni responsabilità. Il cliente restava responsabile dei rilasci dell'applicazione, della correttezza dei dati, dei permessi degli utenti e delle integrazioni con i fornitori. Il livello di hosting poteva essere monitorato, aggiornato con patch, sottoposto a backup e supportato, ma nessun provider può determinare se una funzionalità appena distribuita contiene un errore nella logica di business. Confini di responsabilità chiari fanno parte di una configurazione sana.

Lezioni per i team SaaS che pianificano il passaggio a un VPS

La lezione principale è che la qualità della migrazione viene determinata prima della finestra del passaggio di consegne. Il momento migliore per scoprire un cron job non documentato, una credenziale API scaduta o una tabella del database troppo grande è durante lo staging, non quando i clienti aggiornano il browser.

Iniziate misurando l'utilizzo delle risorse, poi lasciate spazio alla crescita. Predisponete il nuovo server abbastanza presto da poter testare flussi di lavoro reali. Confermate i backup ripristinandoli. Definite cosa attiva il rollback e chi può prendere questa decisione. Infine, monitorate il servizio dopo le modifiche al DNS invece di dichiarare la vittoria quando il comando di distribuzione termina.

Una migrazione VPS dovrebbe lasciare al team maggiore controllo e meno congetture a tarda notte. Se il piano include un ripristino testato, un trasferimento graduale e persone che monitorano il server dopo l'arrivo del traffico, il servizio può tornare a essere tranquillo.

Andres Saar Ingegnere del supporto clienti