Migrazione al cloud

Ultima chiamata per l'on-premise.
Primo giorno nel cloud.

Portiamo la sua infrastruttura da una sala server ormai datata ad AWS, GCP, Azure o a un modello ibrido: per fasi, in sicurezza e con il rollback sempre pronto. Non una semplice copia virtualizzata, ma vere opportunità cloud-native, costi ridotti con la disciplina FinOps e un piano di cutover a zero downtime.

Chi dice «facciamo lift-and-shift, così si fa prima» si ritrova la fattura raddoppiata al sesto mese. L'ordine giusto: prima l'assessment, poi l'architettura, solo alla fine la migrazione. Noi questa sequenza non la saltiamo mai.

Richieda un piano di migrazione Scopra il processo

Migrazione live RUN-1

Data center on-premise

CAPEX elevato

erp-svc

api-gw

postgres-db

queue-worker

analytics-job

Cloud

AWS GCP AZ

ec2 / gke

rds / aurora

s3 / gcs

eks / aks

OPEX flessibile

Scoprire

Valutare

Piano

Pilota

Migrare

Ottimizzare

Gestire

Zero downtime

Perché la migrazione fai-da-te fallisce?

Migrare al cloud non è un «copia e incolla». Una migrazione sbagliata ingigantisce i problemi e glieli presenta in fattura.

Il 70% delle aziende che spostano i propri server su macchine virtuali così come sono e dichiarano «siamo passati al cloud» scopre, dopo il primo anno, che l'OPEX supera il CAPEX on-premise. I motivi sono diversi: il lift-and-shift non coglie le opportunità cloud-native, un'esecuzione in parallelo troppo lunga raddoppia i costi, le dipendenze non mappate causano interruzioni a catena e le policy di sicurezza, che non si possono copiare così come sono, aprono una nuova superficie di attacco. Sono trappole note, ma senza un approccio disciplinato ci si cade dentro una dopo l'altra.

Il lift-and-shift non fa risparmiare

Copiare una macchina virtuale nel cloud significa pagare ogni mese un server delle stesse dimensioni. Senza servizi cloud-native (database gestiti, serverless, auto-scaling) sta pagando la vecchia fattura in un nuovo formato.

L'esecuzione in parallelo è un'emorragia

Se on-premise e cloud restano in parallelo per mesi, significa due fatture e due team operativi. Senza un piano quel periodo passa da 3 a 18 mesi: il budget finisce e il cutover slitta.

Dipendenze non individuate

Un cron dimenticato su un vecchio sistema, un percorso di file condiviso, un client legato a un IP fisso: dopo la migrazione la catena si spezza. Se si salta la fase di discovery, le dipendenze crollano in produzione.

La sicurezza non si trasferisce 1:1

Le regole del firewall on-premise vanno convertite in una combinazione di security group cloud, IAM e KMS. Una copia diretta produce permessi troppo ampi e, insieme, protezioni mancanti.

Rete e DNS calcolati male

Traffico cross-AZ, NAT gateway, VPC peering, dati in uscita (egress): sono voci di costo che emergono in fattura. Con un'architettura sbagliata, la fattura mensile arriva a 3-5 volte il previsto.

Nessun piano di rollback

Se il giorno del cutover emerge un imprevisto, con quale passaggio si torna all'on-premise? Chi risponde «non si può» si assume un grosso rischio: noi teniamo aperta la strada del rollback in ogni fase.

Dashboard visiva della migrazione

Monitoraggio trasparente: dove si trova ogni carico di lavoro, la curva dei costi, ogni decisione 6R.

Kanban — flusso dei carichi di lavoro

Ogni carico di lavoro è una scheda a sé.

On-premise

REHOST
legacy-erp

RETAIN
tape-backup

In migrazione

REPLATFORM
order-api

REHOST
billing-svc

REFACTOR
checkout-fn

Pronto per il cloud

DONE
auth-svc

DONE
cdn-edge

DONE
events-bus

Passaggio da CAPEX a OPEX

Il capitale immobilizzato diventa operatività fluida.

CAPEX

−68%

OPEX

+42%

Netto

−31%

Mappa delle 6 R

Scegliamo la strategia giusta per ogni carico di lavoro — non migriamo alla cieca.

Rehost

Migrare così com'è. Lift-and-shift: il più veloce, il minor vantaggio. Il processo migliora, ma il costo resta uguale.

Replatform

Migrare con piccole modifiche. Database gestito, backup automatici. Impegno medio, risparmio reale.

Refactor

Riscrivere. Serverless, microservizi, architettura event-driven. Impegno elevato, massimo risparmio.

Repurchase

Passare al SaaS. Sostituire il vecchio software su misura con un SaaS standard. Processo breve, cambia il modello.

Retire

Dismettere. I vecchi servizi che nessuno usa si spengono senza migrarli.

Retain

Mantenere on-premise. Normative, latenza, investimenti in hardware — alcune cose non si spostano.

Per chi è?

Otto situazioni tipiche in cui la scelta del cloud acquista senso «adesso».

Rinnovo dell'hardware aziendale

Server di 5-7 anni, garanzia scaduta, preventivo di rinnovo sul tavolo. È il momento giusto per trasformare la stessa spesa in un impegno cloud di 3 anni.

SaaS cresciuto oltre la colocation

I clienti aumentano, i rack sono pieni, aprire un'altra colocation è un errore di scala. Il cloud multi-regione è la soluzione giusta.

E-commerce al limite dell'hardware

Il Black Friday e i picchi delle campagne mettono sotto sforzo l'hardware; senza auto-scaling si perdono clienti.

Consolidamento dopo fusioni e acquisizioni

Due aziende, tre data center, quattro stack diversi. Il cloud è la base per unificare tutto in un'unica infrastruttura di destinazione.

Settori regolamentati e localizzazione dei dati

KVKK (legge turca n. 6698 sulla protezione dei dati personali), BDDK (autorità bancaria turca), finanza, sanità: localizzazione dei dati e tracciabilità degli audit sono obbligatorie. Il cloud, con la regione giusta, semplifica la conformità.

Startup che supera il PaaS

Ha superato i limiti di Heroku, Render o Vercel e le serve un vero controllo dell'architettura. Cloud e infrastructure as code (IaC) sono il salto di qualità.

Modernizzazione di PA e istruzione

L'on-premise è obsoleto, ma il budget di investimento è limitato: modello OPEX e capacità flessibile sono l'unica via d'uscita.

Manifattura e dati IoT

I dati dei sensori in arrivo dalla fabbrica richiedono un'architettura a livelli edge e cloud. L'on-premise da solo non basta.

10 discipline, un solo team

Migrazione, architettura, FinOps, sicurezza — stessa stanza, stesso sprint.

Dividere la migrazione al cloud tra più fornitori significa disperdere le responsabilità e lasciare che i rischi cadano nel vuoto. Con un solo team e una sola roadmap, ogni fase sostiene la successiva e la lentezza decisionale scompare.

Discovery e assessment

Inventario automatico, mappatura delle dipendenze, profili di utilizzo. Quale carico di lavoro rientra in quale categoria 6R.

Modellazione del TCO e business case

Costo totale di proprietà (TCO) a 3 e 5 anni; combinazioni Reserved/Savings/Spot; business case pronto per il consiglio di amministrazione.

Progettazione dell'architettura di destinazione

Multi-AZ, multi-regione, well-architected; failover, disaster recovery, obiettivi RTO/RPO.

Migrazione pilota

Due carichi di lavoro a basso rischio per acquisire competenza e fiducia; un riferimento per le ondate successive.

Migrazione dei database

PostgreSQL, MySQL, Oracle, SQL Server, MongoDB — cutover con interruzione minima.

Rete e VPN

VPN site-to-site, Direct Connect/ExpressRoute, VPC peering, DNS ibrido.

Mappatura delle policy di sicurezza

Firewall on-premise, AD e GPO → IAM, SCP, KMS e audit. Nessun permesso va perso.

Ottimizzazione dei costi (FinOps)

Right-sizing, scheduling, pianificazione RI/SP, rilevamento delle anomalie, showback/chargeback.

Runbook e passaggio operativo

Procedure operative, set di allarmi, formazione per il servizio on-call; un sistema consegnato al suo team.

Ottimizzazione post-migrazione

Tuning di costi e prestazioni nei primi 90 giorni; ciclo di miglioramento continuo.

Processo

Dalla discovery all'operatività stabile: un passaggio graduale in 6 fasi.

01

Settimane 1-3 · Discovery e assessment

Scansione automatica e workshop in sede; tutti i carichi di lavoro, le dipendenze e i profili di utilizzo.
02

Settimane 3-6 · Piano e TCO

Architettura di destinazione, decisioni 6R, piano delle ondate, TCO a 3-5 anni, percorso di rollback.
03

Settimane 6-10 · Pilota

2 carichi di lavoro a basso rischio; si testano landing zone, IaC, monitoraggio e bozze dei runbook.
04

Settimane 10-26 · Ondate di migrazione

Migrazione in ondate di 2-3 settimane; ogni ondata si chiude con il test di accettazione e il rollback pronto.
05

Settimane 26-32 · Ottimizzazione

Right-sizing, acquisto di RI/SP, scheduling automatico, rilevamento delle anomalie.
06

Settimana 32+ · Gestione e passaggio di consegne

Runbook, allarmi, formazione, passaggio di consegne; miglioramento continuo e revisione FinOps mensile.

Strumenti che utilizziamo

Discovery, migrazione, automazione, FinOps — standard di settore.

AWS Migration Hub Azure Migrate GCP Migration Center CloudEndure Carbonite Migrate Velostrata Terraform Ansible Datadog CloudHealth Apptio

Storie di clienti

Settori diversi, stessa disciplina, risultati misurabili.

Manifatturiero Data center −47%

Azienda manifatturiera multisede

2 data center e 180 server migrati su AWS. Dopo 14 mesi il costo dei data center è sceso del 47%; budget per il rinnovo dell'hardware cancellato del tutto.

SaaS 8 settimane

SaaS B2B — 200 servizi

200 microservizi migrati su EKS in 8 settimane; tempo medio di rilascio da 42 min a 6 min.

E-commerce MTTR −73%

E-commerce ad alto traffico

Cloud multi-regione e cache edge; MTTR da 4 ore a 65 minuti; zero interruzioni nel giorno della campagna.

Fintech PCI ✓

Piattaforma di pagamento

Landing zone conforme a PCI-DSS e modello ibrido; processo di audit avviato mantenendo la localizzazione dei dati.

Media −58% / 3×

Piattaforma editoriale

Transcodifica video su istanze spot e Lambda; fattura mensile giù del 58%, throughput triplicato.

Logistica Tempo reale

Spedizioni e tracciamento

Tracciamento in tempo reale con Kinesis e DynamoDB; sistema batch on-premise dismesso.

Domande frequenti

Le 8 domande più frequenti dei clienti

Non esiste un'unica risposta giusta: decidiamo carico per carico. Se ha una scadenza rigida per chiudere un data center e il servizio trarrebbe poco vantaggio dalle funzionalità cloud-native (per esempio uno strumento interno usato di rado), il lift-and-shift ha senso. Per i componenti critici del prodotto (API ad alto traffico, database principale, infrastruttura delle code), invece, il replatform o il refactoring riducono i costi del 30-60% già dal primo anno. L'approccio corretto: analizzare ogni carico di lavoro con il modello 6R, poi procedere con ondate miste. Una strategia ibrida è sempre più realistica di una pura. Evitiamo anche le migrazioni «tutto o niente»: un lift-and-improve per fasi protegge tempi e budget.

AWS ha il catalogo di servizi più ampio e l'ecosistema più diffuso: nella maggior parte dei casi è una scelta iniziale sicura. GCP spicca nei carichi di dati e ML e su Kubernetes (GKE), con un'architettura di rete più pulita. Azure è la scelta preferita dalle aziende legate allo stack Microsoft (AD, .NET, SQL Server, M365) grazie alla stretta integrazione. Il multi-cloud non è necessario e aggiunge complessità inutile. Consigliamo invece di partire da livelli indipendenti dal cloud (Kubernetes, Terraform), così resta la flessibilità di migrare in futuro. A determinare la scelta sono l'esperienza del suo team, il mercato di riferimento, le normative e gli accordi già in essere.

Dipende dalle dimensioni. Un'infrastruttura di medie dimensioni, da 20 a 50 server, richiede da 3 a 6 mesi; un ambiente aziendale con 100-300 server e diversi database da 6 a 12 mesi; un grande portafoglio multisede può arrivare a 12-24 mesi. Più della durata totale conta il ritmo delle ondate: migriamo in ondate di 2-3 settimane, con 5-15 carichi di lavoro ciascuna. Così il rischio si distribuisce, il suo team impara e il rollback resta sempre possibile. Non facciamo migrazioni big-bang, per un motivo semplice: quel giorno anche un piccolo errore può trasformarsi in una grande crisi. L'approccio graduale è sempre più sicuro.

Se il progetto è corretto, sì: un risparmio netto del 20-50% è normale. Se è sbagliato, il cloud costa di più. Le fonti di risparmio: spegnimento automatico nelle ore di inattività, sconti del 40-65% con Reserved Instance e Savings Plan, del 70-90% con le istanze spot per i carichi batch, minori costi del team operativo grazie ai servizi gestiti. Le voci che fanno salire i costi: traffico cross-AZ, trasferimento dati in uscita (egress), istanze sovradimensionate, ambienti di test non monitorati. Per questo la disciplina FinOps è indispensabile: analisi mensile dell'utilizzo, rilevamento delle anomalie, raccomandazioni di right-sizing. L'88% dei nostri clienti opera al di sotto del TCO precedente entro i primi 12 mesi.

Il nostro obiettivo è un'interruzione di 0-30 minuti per carico di lavoro. Le applicazioni web stateless possono arrivare a zero downtime con il rilascio blue-green. Per i database ci sono due approcci: (1) replica continua con strumenti come AWS DMS, Google DMS o Azure DMS: al momento del cutover attendiamo 1-5 minuti di lag e poi commutiamo il DNS; (2) interruzione pianificata in una finestra di manutenzione, di solito una fascia notturna di 2-6 ore. Scegliamo in base alle esigenze del business. Ogni cutover viene provato in staging, così in produzione non ci sono sorprese. Se un problema supera il tempo previsto, il rollback già pronto riporta tutto on-premise.

In genere sì, ma vanno convertiti. I backup basati su VMware o Hyper-V si convertono nei formati AWS, GCP o Azure e si avviano: per questo, come primo pilota, si ripristina una copia nel cloud per testare dati e compatibilità. Un backup però non è una migrazione: la configurazione può essere datata, le licenze possono funzionare diversamente e la rete va rifatta. I backup restano comunque un grande acceleratore iniziale. Insieme alla migrazione impostiamo anche una strategia di backup cloud-native: automazione degli snapshot, replica tra regioni, backup immutabili, resistenti perfino al ransomware.

Per i clienti con sede in Turchia si possono usare la regione AWS di Istanbul, la regione Microsoft Azure Turchia o partner hyperscaler turchi. Per le attività con sede nell'UE consigliamo regioni europee come Francoforte, Amsterdam o Dublino, con una landing zone conforme al GDPR. I controlli critici per KVKK (legge turca n. 6698 sulla protezione dei dati personali) e GDPR: scelta di regioni con residenza dei dati garantita, cifratura a riposo e in transito, conservazione dei log di audit per 7 anni, accesso basato sui ruoli con IAM, report mensile di conformità per il DPO. Sono possibili anche modelli ibridi che tengono in locale i carichi sensibili e spostano il resto nel cloud pubblico. Prepariamo la matrice di conformità insieme al suo team legale.

Sì, lo pianifichiamo in ogni fase. I primi 90 giorni sono il periodo in cui il rollback è più semplice: il sistema on-premise è ancora attivo e basta invertire la modifica del DNS per riportare il traffico. Tra 90 e 180 giorni l'on-premise comincia a spegnersi: per tornare servono nuovi contratti hardware, ma è possibile perché i dati restano sincronizzati. Dopo 12 mesi un ritorno completo non è pratico, ma resta sempre possibile passare a un modello ibrido e riportare alcuni carichi critici in un data center privato. L'idea che la scelta del cloud sia irreversibile è sbagliata: con il piano giusto la flessibilità si conserva. Per ridurre al minimo il vendor lock-in costruiamo livelli indipendenti dal cloud (Kubernetes, Terraform, standard aperti).

Dal peso dell'on-premise a un cloud disciplinato.

In un incontro gratuito di 30 minuti valutiamo insieme la sua infrastruttura attuale, la data di rinnovo dell'hardware e gli scenari di migrazione al cloud — e ne esce con una roadmap chiara in 3 passi.

Fissi un appuntamento Ci contatti

Ultima chiamata per l'on-premise. Primo giorno nel cloud.