MySQL 8.0 fin de vida: la guía de migración 2026
MySQL 8.0 llegó a su fin de vida (EOL) el 30 de abril de 2026. Es la versión que importa: viene siendo el default desde 2018, así que una porción enorme de las bases de datos en producción dejó de recibir parches de seguridad de Oracle. Si tenés 8.0 en cualquier parte de tu stack, hoy corrés software sin soporte.
El MySQL 8.0 fin de vida es el corte de soporte oficial de Oracle para la rama 8.0: a partir del 30 de abril de 2026 no llegan más parches de seguridad ni correcciones para esa versión. La ruta recomendada por Oracle es migrar a MySQL 8.4, la versión LTS con soporte garantizado hasta 2032. EOL no rompe la base, pero la deja expuesta a vulnerabilidades que ya nadie va a parchear.
En 30 segundos
- MySQL 8.0 quedó EOL el 30 de abril de 2026: cero parches de seguridad nuevos de Oracle.
- El camino oficial es 8.0 → 8.4 LTS, soportada hasta 2032. Es una actualización in-place.
- Cuidado con la trampa LTS vs Innovation: un número más alto (9.0, 9.2) no significa más soporte. 9.0 ya está EOL desde octubre de 2024.
- Si estás en 5.7 (EOL desde octubre de 2023), usá 8.0 como checkpoint de validación, no como destino.
- Antes de tocar producción, corré
util.checkForServerUpgrade()contra un staging.
¿Cuáles son las fechas de soporte de cada versión de MySQL?
Acá viene lo bueno: la tabla de abajo te muestra el timeline completo para que ubiques dónde estás parado. El dato que tenés que internalizar es que 8.0 fue el default durante casi ocho años, así que las chances de que lo tengas corriendo son altísimas.
| Versión | Tipo | EOL | EOL Risk Score |
|---|---|---|---|
| MySQL 5.7 | Legacy | Octubre 2023 | Crítico |
| MySQL 8.0 | Default histórico | 30 de abril de 2026 | Alto |
| MySQL 8.4 | LTS | Soporte hasta 2032 | Bajo |
| MySQL 9.0 | Innovation | Octubre 2024 | Crítico |
| MySQL 9.2 | Innovation | Pocos meses post-lanzamiento | Crítico |
Fijate el detalle raro: 9.2 tiene un número más alto que 8.4, pero 8.4 está soportada hasta 2032 y 9.2 ya quedó afuera. Eso no es un error de la tabla. Es exactamente la trampa que explico más abajo. Cubrimos ese tema en detalle en pipelines CI/CD modernos con versiones actuales.
¿Qué significa EOL y por qué dejar MySQL 8.0 sin soporte es crítico?
EOL (End-of-Life) es el momento en que el fabricante deja de mantener una versión. En el caso de MySQL 8.0, desde el 30 de abril de 2026 Oracle no publica más parches de seguridad para esa rama. La base sigue arrancando, sigue respondiendo queries, todo “normal”. Ese es el problema.
Ponele que mañana se descubre una vulnerabilidad grave en el motor. En 8.4 te llega el parche. En 8.0 te quedás mirando el CVE sin fix oficial, esperando que tu proveedor de cloud invente algún mitigante. El riesgo no es que se rompa hoy: es que crece cada semana que pasa, porque la lista de agujeros conocidos y sin tapar se va acumulando.
Por eso el Risk Score de 8.0 quedó en una categoría alta según el relevamiento de EndOfLife. No es rojo absoluto, pero es la categoría de “esto hay que resolverlo ya, no el trimestre que viene”.
¿Por qué Oracle dividió MySQL en LTS e Innovation?
En 2023 Oracle partió MySQL en dos carriles de release, y desde entonces el número de versión ya no te dice cuánto soporte tenés. Esta es la parte que agarra a todo el mundo desprevenido.
- LTS (Long-Term Support): versiones como 8.4 que reciben alrededor de 8 años de soporte. Es lo que ponés en producción y te olvidás.
- Innovation: 8.1, 8.2, 8.3 y toda la serie 9.x. Salen cada tres meses con features nuevas, pero el soporte dura solo hasta que aparece la siguiente release. O sea, unos tres meses cada una.
¿La consecuencia práctica? MySQL 9.0 llegó a EOL en octubre de 2024. 9.2 duró pocos meses. Si en algún momento adoptaste una 9.x pensando “más nuevo es mejor” y no la venís actualizando cada trimestre religiosamente, ya estás corriendo un build EOL con perfil de riesgo crítico. Lo explicamos a fondo en herramientas de automatización contemporáneas.
La regla de oro la dice el propio Oracle: salvo que la actualización trimestral sea parte real de tu modelo de operaciones, quedate en la LTS (8.4) y dejá que las features nuevas lleguen con la próxima LTS. Para la mayoría de los equipos, Innovation es una mala idea.
¿Cuál es el camino recomendado para actualizar desde MySQL 8.0?
Si estás en 8.0, la respuesta es corta: actualizá a 8.4 LTS. Es la ruta in-place que Oracle diseñó justamente para esta transición, y te deja con soporte hasta 2032.
Evitá las versiones Innovation (8.1, 8.2, 8.3, 9.x) salvo que estés comprometido de verdad a actualizar cada trimestre. No es un consejo de manual: es la diferencia entre tener soporte por años o quedar EOL en tres meses sin enterarte.
Si tu base corre en un VPS o servidor propio, este es buen momento para revisar también dónde está alojada y si el plan te da margen para staging. En donweb.com tenés hosting y servidores en Argentina donde podés montar un entorno de prueba sin meterte con producción.
¿Qué cambios rompen en MySQL 8.4 que debo revisar antes de migrar?
Subís la versión, lo probás en local, anda bárbaro, lo mandás a producción y de golpe las apps no se pueden autenticar contra la base, los scripts viejos tiran errores de SQL mode y el equipo te pregunta qué pasó. Pasa por no leer los breaking changes. Estos son los que más muerden:
caching_sha2_passwordcomo default: reemplaza amysql_native_password. Clientes y drivers viejos que no lo soportan dejan de conectar. Es el problema número uno post-migración.- Cambios en SQL mode: queries que antes pasaban ahora pueden fallar por modos más estrictos. Revisá tus inserts y tus reportes legacy.
- Migración del data dictionary: el salto desde 5.7 implica una conversión del diccionario de datos. Hacerlo sin validar previo es jugar con fuego.
- Cambios de collation: defaults distintos pueden afectar ordenamientos y comparaciones de strings. Ojo si tenés índices que dependen de eso.
Ignorar estos puntos no es un detalle estético. Puede causar fallos en la migración o, peor, comportamiento raro que descubrís semanas después en producción. Más contexto en estrategia de múltiples versiones.
¿Cómo valido si mi servidor está listo con util.checkForServerUpgrade()?
MySQL Shell trae una utilidad oficial y gratis para esto. Antes de tocar producción, abrís mysqlsh y corrés util.checkForServerUpgrade() contra un servidor de staging. El comando te escupe un reporte con todo lo que puede romperse.
¿Qué detecta? Incompatibilidades en tipos de datos, variables de configuración que fueron removidas, defaults que cambiaron entre versiones. Es la red de seguridad que te evita el “lo subimos y vemos qué pasa”. La doc completa está en la guía de MySQL Shell.
Regla simple: ningún upgrade va a producción sin pasar antes por este chequeo en staging. Es gratis, es oficial, y te ahorra el dolor de cabeza.
¿Qué hago si todavía estoy en MySQL 5.7?
MySQL 5.7 está EOL desde octubre de 2023, así que ya venís en deuda. El tema es que no podés saltar directo a 8.4: el salto es grande y conviene escalonarlo.
La ruta es 5.7 → 8.0 (validando compatibilidad en staging) → 8.4. Acá 8.0 no es tu destino final, es un checkpoint de validación. Oracle lo diseñó exactamente para esto: que uses 8.0 como puente para chequear que tus datos y tu schema sobreviven la conversión antes de llegar a la LTS. Complementá con soluciones de infraestructura local.
¿Tenés presupuesto y querés ahorrarte un paso? Hay herramientas de migración (como las de Google Cloud o AWS) que permiten saltar más directo. Pero para la mayoría, el camino escalonado con validación en cada etapa es el más seguro.
Errores comunes al planear la migración
- Creer que un número más alto es más seguro: instalar 9.0 pensando que es “lo último” cuando ya está EOL desde octubre de 2024. Más nuevo no es más soportado. Quedate en LTS.
- Migrar sin correr el upgrade checker: saltarse
util.checkForServerUpgrade()y descubrir los problemas recién en producción. El reporte tarda minutos y te muestra todo. - No probar la autenticación de los clientes: el cambio a
caching_sha2_passworddeja afuera a drivers viejos. Si no lo probás antes, tus apps no conectan el día del switch. - Saltar de 5.7 directo a 8.4 sin checkpoint: la migración del data dictionary necesita validación intermedia. Usar 8.0 como puente no es opcional para esa ruta.
Preguntas Frecuentes
¿Cuándo es el fin de vida de MySQL 8.0?
El 30 de abril de 2026. Desde esa fecha Oracle dejó de publicar parches de seguridad y correcciones para la rama 8.0, que venía siendo el default desde 2018.
¿Qué debo hacer si tengo MySQL 8.0 en producción?
Planificá la actualización a MySQL 8.4 LTS, la ruta in-place oficial con soporte hasta 2032. Antes de tocar producción, validá en staging con util.checkForServerUpgrade() y revisá el cambio de default a caching_sha2_password.
¿Cuál es la diferencia entre MySQL LTS e Innovation?
LTS (como 8.4) recibe unos 8 años de soporte y es para producción. Innovation (8.1, 8.2, 8.3 y la serie 9.x) sale cada tres meses y solo tiene soporte hasta que aparece la siguiente release, o sea unos tres meses.
¿Cuánto tiempo tiene soporte MySQL 8.4?
MySQL 8.4 es una versión LTS con soporte garantizado hasta 2032. Es la versión recomendada por Oracle para producción y la que te evita tener que estar actualizando cada trimestre.
¿Cómo migro de MySQL 5.7 a 8.4?
De forma escalonada: 5.7 → 8.0 (como checkpoint de validación en staging) → 8.4. No saltes directo, porque la migración del data dictionary necesita validación intermedia. Corré el upgrade checker en cada etapa.
Conclusión
El 30 de abril de 2026 cambió el status de millones de instalaciones: 8.0 dejó de recibir parches y pasó a ser software sin soporte. Si lo tenés en producción, la jugada no es esperar a que algo se rompa, es planificar la migración a 8.4 LTS ahora, mientras el riesgo todavía es manejable.
Lo que tenés que llevarte: quedate en LTS, ignorá la tentación de los números altos de Innovation, validá en staging con util.checkForServerUpgrade() antes de cualquier movimiento, y prestale atención al cambio de autenticación que rompe drivers viejos. Hacer esto ordenado te lleva una tarde. Hacerlo apurado después de un incidente de seguridad te lleva mucho más.
