Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Cuando toca XAMPP actualizar versión sin perder datos, la decisión real no es si hacer copia de seguridad (eso es obligatorio en ambos casos), sino cómo migras la carpeta htdocs y las bases de datos. Hay dos caminos que la gente usa de verdad: reinstalar encima conservando la carpeta antigua, o instalar la nueva versión en paralelo y mover los proyectos a mano. Gana la segunda, y no por elegancia, sino por algo muy concreto: si algo falla, tu entorno anterior sigue intacto y puedes volver a él en segundos.
Lo primero que conviene entender es qué se pierde cuando instalas una versión nueva de XAMPP. El instalador reemplaza archivos de Apache, PHP y MySQL/MariaDB. Tus proyectos en htdocs y tus bases de datos en mysql/data quedan donde estaban si no marcas la casilla de eliminar. El problema aparece cuando la versión de MariaDB salta de rama y el formato de datos cambia: ahí una carpeta copiada a mano deja de ser legible por el motor nuevo. Por eso la opción de reinstalar encima funciona a veces, pero no siempre.
He visto este escenario varias veces: alguien actualiza de una versión con MariaDB 10.4 a una con 10.6, arranca MySQL y el panel se queda en amarillo. Los datos siguen ahí, pero el servidor no los lee. Ese es el momento en que uno agradece haber hecho una instalación en paralelo en lugar de haber machacado la carpeta anterior.
Opción A: instalar encima y conservar carpetas
Consiste en ejecutar el instalador de la versión nueva sobre la ruta actual, desmarcando la eliminación de htdocs y de la carpeta de datos. Es rápido, no requiere reconfigurar el host virtual ni los puertos, y el Panel de Control sigue apuntando a los mismos servicios.
El fallo típico: el instalador sobrescribe php.ini y my.ini, así que pierdes extensiones activadas, límites de subida y configuraciones de zona horaria. Si tenías PHP con upload_max_filesize alto para un WordPress local, vuelves a 2M sin avisar. También se pierden los virtual hosts personalizados si tocaste httpd-vhosts.conf.
Otro detalle que casi nadie menciona: al actualizar XAMPP sin perder datos por esta vía, los módulos de Apache compilados para la versión anterior pueden quedar huérfanos. Apache arranca, pero con errores silenciosos en el log que solo notas cuando algo deja de responder.
Opción B: instalación paralela y migración manual
Descargas el instalador nuevo, lo colocas en una ruta distinta (por ejemplo C:xampp83 o /opt/lampp83), cambias los puertos para que no choquen con la instalación vieja y arrancas ambos entornos. Luego exportas bases de datos con mysqldump desde el viejo e importas en el nuevo, y copias las carpetas de proyecto de un htdocs a otro.
Esta opción gana por tres motivos concretos. Primero, puedes probar cada proyecto antes de dar el salto definitivo. Segundo, si un proyecto depende de una extensión PHP que ya no existe en la versión nueva (pasa con mcrypt o con versiones antiguas de gd), lo detectas con el entorno antiguo aún vivo. Tercero, la vuelta atrás es trivial: cierras la nueva instancia y sigues trabajando.
El coste es tiempo: hay que exportar, importar y revisar. En un equipo con cinco o seis proyectos locales, esa migración manual puede llevar una tarde. Con uno o dos proyectos, media hora.
Por qué la paralela se impone en la práctica
La razón de fondo no es técnica, es de riesgo. Actualizar XAMPP conservando datos con el instalador encima asume que el motor de base de datos nuevo leerá los archivos del viejo sin problema. Esa suposición falla cuando cambia la rama mayor de MariaDB o cuando hay tablas con motores antiguos. En cambio, con la instalación paralela, el mysqldump genera un volcado SQL que cualquier versión posterior puede importar, salvo incompatibilidades muy específicas de sintaxis.
Hay una excepción honesta: si tu XAMPP es reciente y solo saltas una versión menor, reinstalar encima probablemente funcione sin dramas. No hace falta montar dos entornos para un salto pequeño. La instalación paralela tiene sentido cuando cambias de rama de PHP o de MariaDB, o cuando tienes proyectos que no puedes permitirte romper.
Y un límite que conviene decir claro: este método no funciona bien con proyectos que guardan rutas absolutas en la base de datos, como instalaciones de WordPress con la URL del sitio hardcodeada. En esos casos, migrar el dump sin actualizar las URLs rompe enlaces internos. Hay que hacer un reemplazo controlado en el SQL antes de importar, o usar herramientas de migración específicas del CMS.
Qué hacer antes de tocar nada
Antes de cualquier actualización de XAMPP sin perder datos, dos acciones no negociables. Una: copiar la carpeta completa de XAMPP a otra ruta, incluida la de datos. Dos: exportar cada base de datos con mysqldump a un archivo .sql aparte. La copia de carpeta protege ante desastres; el volcado SQL protege ante incompatibilidades de formato.
Documentación oficial de Apache Friends y de MariaDB recogen las notas de compatibilidad entre versiones. Merece la pena leerlas antes de decidir si el salto es seguro. No hay garantía de que todo funcione a la primera, y quien diga lo contrario no ha migrado muchos entornos locales.
Mi recomendación personal: instalación paralela siempre que el salto implique cambio de rama mayor, y reinstalación encima solo para parches menores. La comodidad de tener dos entornos conviviendo unas horas compensa con creces el riesgo de perder un proyecto a medio terminar.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
