Misurare il vendor lock-in in giorni-uomo: la metodologia che il tuo CFO capirà

In ogni gara enterprise IT degli ultimi cinque anni, almeno una slide dello sponsor interno conteneva la formula “consolidare sul fornitore X ci dà economie di scala e riduce la complessità”. In ogni board review post-firma di tre anni dopo, almeno una slide conteneva “il costo di uscita dal fornitore X è ora prohibitivo, dobbiamo valutare una proroga”. Le due slide vengono di solito firmate dalla stessa persona, intervallate da una promozione.

Il vendor lock-in non è un dilemma morale: è una variabile economica. Il problema è che non viene mai misurata prima di firmare. Si misura dopo, quando lo sconto è ormai incassato e i tre anni di build-up tecnico-organizzativo sono spesi. Questa metodologia esiste per anticipare quella misurazione di 36 mesi.

Perché il “rischio lock-in” non funziona come argomento

Il primo problema dell’argomento “attenzione al lock-in” è che è generico. Il CIO che sta valutando un rinnovo pluriennale di AWS sa benissimo che il lock-in esiste. Il CFO che firma l’assegno chiede: “quanto costa effettivamente uscirne se servisse?”. Senza un numero, la discussione si sposta sul costo immediato dello sconto (20-30% biennale è tipico) — e quello c’è in slide.

Il secondo problema è che “lock-in” è un termine ombrello che copre cose molto diverse: lock-in tecnologico (API proprietarie), lock-in di dati (formati esportabili o no), lock-in di competenze (skill rare sul mercato), lock-in contrattuale (penali di uscita), lock-in di processo (workflow integrati). Sommarli in una valutazione qualitativa “alto/medio/basso” è inutile per chi deve decidere.

La metodologia proposta qui trasforma le 5 dimensioni in giorni-uomo equivalenti. Si moltiplicano per il costo medio interno (€800/giorno per un tecnico senior italiano, conservativamente €1200/giorno se sotto consulenza), si ottiene un numero in euro. Questo numero si confronta con il TCO biennale per ottenere un Exit Cost Index percentuale. Sopra il 30% del TCO, il lock-in è materiale e va deciso esplicitamente; sotto il 15% è normale rumore di fondo.

Le 5 dimensioni dell’Exit Cost Index

Dimensione 1 — Data egress (estrazione dati)

Quanti giorni-uomo servono per estrarre tutti i dati operativi dal fornitore in un formato utilizzabile altrove. Include:

• volume dati totale (GB/TB)
• costo dell’egress fee del fornitore (AWS S3 egress fee verso internet: ~$0.09/GB sotto i 10TB, scende ma resta significativo sopra)
• tempo di trasferimento alla banda disponibile
• conversione formati (es. RDS → Postgres standalone, DynamoDB → Postgres con re-modeling)
• validazione post-estrazione

Benchmark realistici 2026 per un workload medio (10TB OLTP + 50TB object storage + warehouse 200TB):

• AWS → fornitore neutro: 25-40 giorni-uomo + €4.500-€8.000 di egress fee
• Azure: simile ad AWS (gli annunci di “free egress” hanno limiti pratici)
• GCP: simile, leggermente più aggressivo sul fronte gratuità con egress promozionali
• OVHcloud → Hetzner (entrambi europei): 10-15 giorni-uomo, egress fee zero o trascurabile

Dimensione 2 — Refactoring application

Quante linee di codice / servizi dipendono da API proprietarie del fornitore. Le candidate tipiche al refactoring:

• Identity providers proprietari (Cognito → Keycloak o Auth0)
• Message queues proprietarie (SQS → RabbitMQ o NATS, Service Bus → equivalent)
• NoSQL proprietari (DynamoDB, Cosmos DB, Bigtable → modeling completo su Postgres o ScyllaDB)
• Managed AI (Bedrock, Vertex AI, Azure OpenAI → API equivalent o self-host)
• Identity-aware proxies, service meshes proprietari
• Serverless framework proprietari (Lambda + Step Functions → container orchestration)

Benchmark per un’app aziendale media (50 microservizi, 200k LOC):

• Refactor 20-30% dei microservizi che usano API proprietarie: 80-150 giorni-uomo
• Re-modeling NoSQL → SQL: 30-60 giorni-uomo per ogni datamodel non triviale
• Refactor IAM proprietario → standard OIDC: 15-25 giorni-uomo

Dimensione 3 — Re-training del team

Quante persone hanno competenze profonde sul fornitore di destinazione vs quello attuale. Le competenze cloud non sono fungibili come si pensa.

• Un sysadmin AWS senior non è automaticamente un sysadmin Azure senior. Migrazione efficace richiede 2-4 mesi di build-up + esperienza di un primo deploy reale.
• Il pricing model cambia (Azure ha logiche diverse da AWS), e l’optimization passa attraverso comprensione contestuale.
• Le best practices SRE differiscono (per esempio, CloudWatch e Application Insights hanno paradigmi diversi)

Benchmark per un team SRE/DevOps medio (8-12 persone):

• Re-training da AWS a Azure/GCP: 6-9 mesi per arrivare a velocità operativa simile, di cui i primi 3 mesi di -30/-50% di produttività
• Re-training da hyperscaler a OVHcloud/Hetzner: meno (la pila tecnologica è più “classica”, molto Linux+Postgres+Nginx), 2-4 mesi

Per la metodologia, considerare 60 giorni-uomo per la formazione di un team di 8 persone (10 giorni a testa effettivi, distribuiti su 4-6 mesi).

Dimensione 4 — Contratti dipendenti

I contratti SaaS satelliti spesso hanno integrazione esplicita con il provider cloud principale. Esempi:

• Single Sign-On enterprise di terze parti che integra solo certi IdP
• SaaS di monitoring (Datadog, New Relic) con pricing basato sull’host count, da rinegoziare se cambi cloud
• Backup as a service (Veeam, Druva) con licenze legate alla piattaforma
• Security tools con integrazione AWS Security Hub / Azure Sentinel, da migrare

Benchmark: per ogni rinegoziazione contrattuale complessa attendere 3-10 giorni-uomo di legale interno + IT, per 5-15 contratti tipici di un’azienda media → 15-150 giorni-uomo in totale, con varianza grossa in funzione della maturità contrattuale.

Dimensione 5 — Migration window e operational risk

La migrazione vera richiede una finestra in cui due ambienti coesistono (legacy in produzione, nuovo in build/test/canary). Durante questa finestra:

• doppi costi infrastrutturali (3-9 mesi)
• rischio operativo elevato (rollback necessari, possibili downtime)
• attenzione manageriale concentrata su migrazione vs business as usual

Benchmark:

• Doppio cost infrastrutturale: 3-6 mesi a 70-100% (40-60% sull’infra legacy, 60-80% sulla nuova)
• Effort di project management e coordinamento: 40-80 giorni-uomo
• Rischio operativo: si quantifica come 0,5-2% extra disponibilità del team SRE allocato

L’Exit Cost Index in formula

Exit Cost (in giorni-uomo) =
    DataEgress (D1) +
    Refactor (D2) +
    Retraining (D3) +
    Renegotiation (D4) +
    Migration overhead (D5)

Exit Cost (in euro) = Exit Cost (giorni) × €/giorno medio team
                    + Egress fee €
                    + Doppio cost infra €

Exit Cost Index (%) = Exit Cost € / TCO biennale del fornitore corrente × 100

Un esempio numerico per un’azienda media (TCO biennale AWS: €600k):

Dimensione	Giorni	Note
D1 — Data egress	35	+€6.000 egress fee
D2 — Refactor	120	(20% microservizi proprietari)
D3 — Retraining	60	(team di 8)
D4 — Contratti	50	(10 contratti)
D5 — Migration	60	+ doppio costo infra ~€90k 4 mesi
Totale	325 giorni-uomo
In €	€325k	(@€1000/giorno)
+ extra	€96k	(egress + dual run)
Exit Cost €	€421k
TCO biennale	€600k
ECI	70%	LOCK-IN MATERIALE

Sotto il 30%, si va avanti senza pensarci. Tra 30% e 50%, è una decisione consapevole. Sopra il 50%, la decisione esce dal perimetro IT e diventa una decisione strategica del board.

Tre errori sistematici nella stima

Gli errori più frequenti quando la formula viene applicata davvero:

1. Sottostimare D2 (refactor). La tendenza è “i microservizi sono containerizzati, basta cambiare orchestrator”. No: ogni dipendenza implicita su un servizio managed proprietario è un refactor. CloudWatch alerts, IAM roles, S3 lifecycle policies, KMS keys con CMK proprietarie — tutti diventano lavoro.

2. Ignorare D3 (retraining) per il team interno. “I nostri ragazzi sono bravi, imparano in fretta”. Vero, ma il “in fretta” è 4 mesi, non 4 settimane. Sottostimare retraining produce timeline di migrazione fantasy e demoralizzazione del team.

3. Pensare che D5 (doppio costo) sia “solo per un mese”. In progetti reali medi, il dual run dura 4-6 mesi. La pressione per accelerare il decom del legacy genera rollback malposizionati.

Quando l’ECI alto è OK

Un Exit Cost Index del 60% non significa che il contratto è da rifiutare. Significa che hai una decisione consapevole da fare e da documentare. Casi in cui un ECI alto è perfettamente accettabile:

• Fornitore con SLA enterprise impeccabili e roadmap che si allinea perfettamente con i tuoi 3-5 anni
• Niente alternative commerciali realistiche (sì, succede: alcuni workload sono difficili da spostare su provider Cat. C europei senza perdita di feature)
• ECI calcolato e accettato dal board come parte di un risk register

Quando l’ECI alto non è OK:

• Sponsor interno che firma senza far passare il numero per il risk committee
• ECI > 80% (sei in captive completo)
• ECI alto su un fornitore con problemi noti di SLA, pricing aggressivo, roadmap divergente dai tuoi bisogni

Cosa fare lunedì mattina

Prendi il tuo contratto cloud principale in scadenza nei prossimi 12 mesi. Compila la tabella ECI sopra in 3 ore di lavoro con il tuo tech lead. Porta il numero al prossimo risk committee con due slide: ECI calcolato + scenario di uscita stimato. Se il numero è sopra il 50%, hai aperto la conversazione che andava aperta tre anni fa. Se è sotto, sei tranquillo ma hai documentato la tranquillità. In entrambi i casi, hai trasformato il “lock-in” da concetto vago a numero in slide. Te lo dico io.