Por qué la calculadora de migración del vendor te miente (y cómo leerla igual)

Cada hyperscaler te ofrece su "calculadora TCO". Metes la cantidad de VMs, le das Calcular, y un banner verde te promete 40% de ahorro contra tu cloud actual. Los equipos de ventas imprimen esos PDFs. Los CFOs firman planes de migración basados en ellos.

La mayoría de esos números están mal. No por mala fe — están incompletos. Después de modelar miles de workloads entre AWS, GCP, Azure y OCI, aprendimos que una estimación de migración vale lo mismo que las suposiciones que está dispuesta a mostrar. Esta es la versión corta del framework que ya viene incorporado en el Migration Analyzer de Lumicost.

Qué se le escapa a la calculadora del vendor

1. Ignora los commitments que ya pagaste

Si compraste una Reserved Instance a 3 años, un Savings Plan o un Committed Use Discount, el precio "actual" on-demand no es lo que realmente pagas. Una calculadora que compare tu rate efectivo contra el on-demand del destino va a inflar el ahorro. Una que ignore la amortización pendiente de tus commitments te va a decir que dejes plata que ya gastaste arriba de la mesa.

Un análisis serio tiene que responder dos preguntas en paralelo:

• ¿Cuánto cuesta este workload en el cloud destino a precio de lista?
• ¿Cuánto cuesta cuando metés en la cuenta tus commitments existentes, incluyendo los meses que les quedan?

Si la diferencia entre esos dos números es más grande que el ahorro titular, no estás migrando — estás comprando la salida de un contrato.

2. Asume que existe un shape match exacto

m5.2xlarge no es lo mismo que n2-standard-8. Las generaciones de CPU difieren. La proporción de memoria difiere. El throughput sostenido difiere. Cuando el cloud destino no tiene un match uno a uno, la calculadora elige la siguiente talla — en silencio. Pagás 20% más desde el día uno y no te enterás hasta que llega la factura.

La solución es exponer el shape match score (qué tan cerca está la forma destino de la origen) y marcar cualquier caso en el que el analyzer haya tenido que redondear hacia arriba.

3. Trata el egress como nota al pie

Acá es donde sangran las migraciones. Los primeros 90 días post-migración se ven brillantes porque las apps siguen hablando con los datos, servicios y stack de observabilidad del cloud viejo. Después alguien mueve la palanca, el tráfico fluye al revés, y tu factura de egress estalla.

Un workload que parece 35% más barato en compute puede terminar siendo más caro en total apenas considerás el egress. Lumicost tiene un risk flag específico para esto — EGRESS_FLIPS_SAVINGS — porque pasa lo suficientemente seguido como para merecer nombre propio.

4. Esconde la frescura de su data de precios

El pricing en cloud cambia. Los pools de spot se mueven. Salen familias de instancias nuevas. Las calculadoras que tiran un número plano rara vez te dicen cuándo se refrescó la última vez su snapshot de precios. Si la data tiene más de 30 días, el análisis es una corazonada disfrazada de cotización.

Cómo puntuamos una migración en Lumicost

Nunca damos un número solo. Damos un tier de confianza y una lista de risk flags. Tres tiers:

• HIGH — shape match ≥ 0.85, pricing reciente, sin conflictos de commitments, egress modesto.
• MEDIUM — shape match entre 0.6 y 0.85, o un risk flag activo.
• LOW — shape match bajo 0.6, o pricing viejo, o el egress da vuelta el ahorro, o hardware especializado.

Once flags pueden dispararse en un workload. Entre los más comunes:

• CROSS_REGION_LATENCY — la región destino está lejos de tus datos, esperá impacto en P95
• NO_EXACT_SHAPE_MATCH — la forma más cercana es más grande; revisá el costo del redondeo
• EGRESS_HEAVY — el workload mueve más de 1 TB / mes hacia afuera del cloud
• EGRESS_FLIPS_SAVINGS — el egress solo se come el ahorro de compute
• COMMITMENT_AMORTIZATION_UNKNOWN — todavía no cargaste tus commitments
• COMMITMENT_EXPIRES_SOON — el commitment del cloud origen expira en menos de 90 días, recalculá entonces
• PRICE_DATA_STALE — el snapshot de pricing tiene más de 30 días
• SPECIALISED_HARDWARE — GPU, FPGA, silicio custom o licencia atada — el destino tiene menos opciones
• STORAGE_TIER_UNPRICED — el tier destino existe pero no logramos costearlo
• LARGE_MIGRATION_TRANSFER — mover el dataset cuesta más que un año de ahorro de compute
• EGRESS_VOLUME_ASSUMED — estimamos el egress; cargá flow logs reales para un número más fino

Un workload con tier HIGH y cero flags es candidato. Uno con tier LOW y tres flags es una reunión, no una migración.

Una guía corta para leer la próxima calculadora

Cuando alguien te pase una estimación de migración — vendor, consultor u open-source — hacé las mismas cinco preguntas:

1. ¿Se incluyeron mis commitments existentes, con los meses que les quedan?
2. ¿La forma destino fue match exacto, o se redondeó hacia arriba?
3. ¿Cuál es el supuesto de egress, y sale de flow logs reales o es un guess?
4. ¿Qué tan fresca es la data de pricing?
5. ¿Cuál es el tier de confianza, y qué risk flags se dispararon?

Si la respuesta a alguna es "eso no lo modelamos", tenés un PDF de marketing, no un plan de migración.

---

Dónde encaja Lumicost

El Migration Analyzer de Lumicost es opinado exactamente sobre esto: tier de confianza en lugar de un número solo, once risk flags explícitos, tus RIs / SPs / CUDs existentes incluidos en la cuenta, cuatro clouds con pricing real (AWS, GCP, Azure, OCI), y un honesty banner permanente en la página para que nadie confunda el análisis con una respuesta final.

Tomá el número como punto de partida. Después andá a negociar.