Se la tua azienda vuole cambiare fornitore cloud, c’è una data da segnare: dal 12 gennaio 2027 il Data Act europeo vieta ai provider di addebitare i costi di switching, compresi quelli di uscita dei dati (data egress), ai clienti che passano a un altro fornitore o a un’infrastruttura propria. Mancano tre mesi. È il momento giusto per preparare la migrazione: la legge toglie il costo del trasferimento, ma il lavoro tecnico resta tutto da fare.
In questo articolo spiego cosa cambia davvero, cosa invece non cambia, e il metodo che uso per spostare servizi web su VPS gestiti con Docker, Portainer e HestiaCP, senza fermare l’operatività.
Cosa cambia dal 12 gennaio 2027
Il Regolamento (UE) 2023/2854, noto come Data Act, contiene una parte dedicata al passaggio tra servizi di elaborazione dati: IaaS, PaaS, SaaS. Dopo un periodo transitorio in cui i provider potevano addebitare solo i costi effettivamente sostenuti, dal 12 gennaio 2027 le tariffe di switching e di egress legate al cambio vengono eliminate. Lo riassumono bene sia Tom’s Hardware sia, con un taglio più orientato ai portafogli cloud, Digital Chiefs (in inglese).
Il regolamento prevede anche obblighi contrattuali sul supporto alla migrazione: preavvisi massimi, un periodo di transizione e la possibilità di recuperare i propri dati in formati utilizzabili. I dettagli applicabili al tuo contratto vanno però letti nel contratto stesso, possibilmente con un consulente legale.
Cosa non cambia
Due punti che spesso vengono fraintesi:
- Le penali per recesso anticipato restano ammesse. Se hai firmato un impegno triennale con sconto, uscire prima può comunque costare.
- I canoni ordinari restano dovuti fino alla fine del rapporto, compreso il periodo in cui i due sistemi convivono.
In pratica: gratis è il trasferimento, non l’uscita da qualsiasi vincolo. Prima di pianificare, guarda la scadenza del contratto e le clausole di recesso.
Prima di tutto: l’inventario reale
Nessuna migrazione fallisce per il trasferimento dei file. Fallisce per le cose che nessuno sapeva di avere. Il primo documento che preparo è un inventario completo:
- Servizi attivi: sito, web app, posta, file sharing, gestionali SaaS, backup.
- Dati: database, file caricati dagli utenti, allegati, log che devi conservare per obblighi di legge.
- Dipendenze nascoste: cron job, webhook verso altri sistemi, servizi gestiti del provider (code, storage a oggetti, funzioni serverless) che non hanno un equivalente uno a uno.
- DNS e certificati: chi gestisce il dominio, dove puntano i record, come si rinnovano gli SSL.
- Accessi: credenziali, chiavi API, account di servizio. Ne ho parlato nell’articolo sulla gestione dei secrets nelle web app.
Le dipendenze da servizi proprietari sono il vero lock-in. Il Data Act riduce il lock-in economico, non quello tecnico: se la tua applicazione usa API esclusive di un provider, va riscritta quella parte. Lo stesso ragionamento vale per i fornitori AI, come spiegato in vendor lock-in AI.
Dove andare: tre destinazioni realistiche per una PMI
Un altro cloud pubblico
Ha senso se usi servizi gestiti che non vuoi amministrare. Il Data Act rende più semplice anche questo passaggio, ma il rischio è ricreare la stessa dipendenza altrove.
VPS con Docker e Portainer
È la soluzione che uso più spesso per web app e strumenti interni. Ogni servizio vive in un container con i suoi volumi dati e un file di configurazione versionato. Spostarlo significa copiare volumi e configurazione e riavviarlo su un altro server, indipendentemente da chi fornisce la macchina. Ho descritto l’impostazione in Docker e Portainer per aziende.
Hosting gestito con HestiaCP
Per siti WordPress, posta e domini multipli preferisco un pannello come HestiaCP: backup per utente, SSL automatici, gestione DNS. È la base che uso per siti su misura come lapidari.it e opticagheller.it, di cui curo anche hosting e manutenzione.
Il piano di migrazione passo per passo
- Verifica contrattuale: scadenza, penali, preavviso, modalità di export previste dal provider.
- Inventario e mappa delle dipendenze, come sopra.
- Preparazione della destinazione: server, firewall, utenti, backup configurati prima di spostare un solo byte.
- Riduzione del TTL DNS qualche giorno prima, così il cambio di puntamento si propaga in fretta.
- Prima copia dei dati e avvio dei servizi sul nuovo ambiente, raggiungibili su un dominio di test.
- Test funzionali: login, upload, invio email, pagamenti, integrazioni. Con una checklist scritta, non a sensazione.
- Sincronizzazione finale e cutover: breve finestra in sola lettura, ultima copia differenziale, cambio DNS.
- Convivenza e verifica: il vecchio ambiente resta disponibile qualche giorno come rete di sicurezza, poi si chiede la cancellazione dei dati al vecchio provider.
Il cutover è la parte delicata. Il metodo che uso per i siti è descritto in migrazione sito web senza downtime: vale anche per web app più complesse, con qualche attenzione in più sul database.
Due esempi concreti: file e documenti
Prendo come riferimento due servizi che gestisco direttamente.
cloud.cornelcaba.com è un’istanza Nextcloud. Spostare un Nextcloud significa portare tre cose coerenti tra loro: la directory dei dati, il database e il file di configurazione. Se si copia il database in un momento e i file in un altro, si ottengono file “fantasma” o mancanti. Per questo si attiva la modalità manutenzione, si fa il dump del database, si sincronizzano i file e si aggiorna la configurazione con il nuovo dominio. Prima di aprire agli utenti, una scansione dei file conferma che archivio e database coincidono.
pdf.cornelcaba.com è un toolkit PDF self-hosted. Qui la situazione è opposta: lo strumento elabora documenti ma non deve conservarli, quindi i dati persistenti sono minimi. Migrarlo vuol dire soprattutto ricreare container e configurazione sul nuovo server e aggiornare il reverse proxy. È un buon promemoria: non tutti i servizi pesano uguale, e l’inventario serve proprio a capire dove concentrare il tempo.
Errori da evitare
- Aspettare il 12 gennaio per iniziare: la scadenza riguarda i costi, non i tempi tecnici. Prepararsi prima permette di migrare appena conviene.
- Dimenticare la posta: record MX, SPF, DKIM e DMARC vanno replicati, altrimenti le email finiscono in spam o si perdono.
- Non provare il ripristino: un backup mai ripristinato non è un backup.
- Cancellare il vecchio ambiente subito: tienilo finché i test in produzione non sono conclusi.
- Ignorare il GDPR: cambia il luogo del trattamento, quindi aggiorna registro dei trattamenti e nomine dei responsabili esterni.
FAQ
Dal 2027 posso disdire il cloud quando voglio senza pagare nulla?
No. Spariscono i costi legati al passaggio e all’uscita dei dati, ma penali per recesso anticipato e canoni contrattuali restano ammessi. Controlla durata e clausole del tuo contratto.
Il Data Act vale anche per i software SaaS, non solo per i server?
Sì, il regolamento copre i servizi di elaborazione dati in senso ampio, inclusi i SaaS. Resta il problema pratico del formato: un export completo non garantisce che un altro software sappia importarlo senza conversioni.
Quanto dura una migrazione per una PMI?
Dipende dal numero di servizi e dalle dipendenze. Un sito WordPress si sposta in tempi brevi; una web app con integrazioni, posta e storage richiede più giorni tra preparazione, test e convivenza dei due ambienti. L’inventario iniziale è ciò che permette una stima onesta.
Conviene passare al self-hosting o a un altro cloud?
Se usi molti servizi gestiti proprietari, un altro cloud può essere più semplice nel breve periodo. Se vuoi controllo su dati e costi, un VPS con container o un hosting gestito con HestiaCP riducono la dipendenza da un singolo fornitore.
Prepararsi adesso
Il Data Act toglie una barriera economica, ma la migrazione resta un progetto tecnico: inventario, destinazione, test, cutover. Sviluppo e gestisco web app, siti e servizi self-hosted end-to-end, dall’infrastruttura al codice, e posso aiutarti a capire cosa spostare, dove e con quale ordine. Se vuoi valutare il tuo caso, contattami per un primo confronto.
