Migrar PrestaShop sin perder ventas ni posicionamiento

Si has llegado hasta aquí es porque tienes que migrar PrestaShop y quieres hacerlo sin que el lunes te suene el móvil con la frase favorita de cualquier ecommerce manager: "la tienda no carga". Te lo voy a contar como lo hacemos en proyectos reales, con los matices que rara vez salen en los tutoriales de YouTube.

Tanto si vas a cambiar de hosting, fusionar dos tiendas, actualizar a PrestaShop 8 o simplemente mover el dominio, el proceso tiene varias capas: archivos, base de datos, configuración, módulos de pago, transportistas y, lo más delicado, el SEO. Saltarte una sola de ellas se traduce en pedidos perdidos, errores 500 y, con suerte, en una bronca del responsable de marketing.

He preparado una guía pensada para tiendas españolas con volúmenes reales — desde la PYME de 200 pedidos al mes hasta proyectos B2B con catálogos de 30.000 referencias. Vas a ver qué orden seguir, qué herramientas usar y dónde están las trampas que casi nadie cuenta.

Antes de migrar PrestaShop: lo que tienes que decidir

Antes de tocar nada conviene parar diez minutos y aclarar el alcance. No es lo mismo una migración prestashop a otro servidor manteniendo versión y dominio, que aprovechar el movimiento para subir de 1.7.8 a PrestaShop 8.x. Cada combinación tiene su propio nivel de riesgo.

Las cuatro preguntas que evitan disgustos

• ¿Vas a cambiar de versión? Si saltas de 1.7 a 8, no es migración, es proyecto. Implica revisar módulos uno a uno y, casi seguro, retocar el tema.
• ¿Cambias de dominio? Si sí, prepara las redirecciones 301 antes de tocar DNS.
• ¿El nuevo hosting soporta tu pila? PHP 8.1+, MySQL 5.7 o MariaDB 10.3+, extensiones GD, intl, zip, soap…
• ¿Tienes ventana de mantenimiento real? En B2C, las madrugadas de martes a jueves suelen ser las horas con menos pedidos. Los domingos, ojo, hay nichos que disparan ventas.

Una cosa que aprendes con los años es que la decisión sobre qué se migra y qué se queda atrás es tan importante como el cómo. Aprovecha el movimiento para limpiar productos descatalogados, categorías huérfanas y los 47 módulos que instalaste "para probar" y nadie ha vuelto a abrir. Cuanta menos paja arrastres, más rápido irá la nueva tienda.

Si el catálogo es enorme o tienes integraciones con ERP, conviene apoyarse en una agencia especializada en PrestaShop para el plan de corte y vuelta atrás. No es lo mismo improvisar con una tienda de 30 SKUs que con una de 30.000.

Backup completo: el seguro de vida del proceso

Esto es innegociable. Antes de mover PrestaShop de sitio necesitas dos copias completas guardadas en lugares distintos: una en tu ordenador y otra en almacenamiento externo (Drive, Dropbox empresarial, S3, lo que uses). Si algo se tuerce, esto es lo que te permite volver atrás sin llorar.

Qué debe incluir el backup

1. Archivos completos de la raíz: /admin, /modules, /themes, /img, /upload, /download y los archivos de configuración (app/config/parameters.php o el viejo config/settings.inc.php según versión).
2. Volcado SQL de la base de datos, comprimido. Si pesa mucho, usa mysqldump por SSH en lugar de phpMyAdmin, que se te queda colgado con catálogos grandes.
3. Listado de módulos activos y sus versiones. Una captura del back office sirve.
4. Configuración del servidor: versión de PHP, límites (memory_limit, max_execution_time, upload_max_filesize), cron jobs y reglas .htaccess personalizadas.

El backup que no se ha probado restaurando no es un backup, es un archivo grande que ocupa sitio.

Te recomiendo restaurar la copia en un entorno de staging antes de seguir. Si la tienda arranca en staging con los datos del backup, ya sabes que la copia es válida. Si no arranca, mejor descubrirlo ahora y no a las tres de la mañana del día de la migración.

Preparar el nuevo servidor y mover los archivos

Con el backup en la mano, llega el momento de preparar el destino. Si vas a cambiar hosting PrestaShop, asegúrate de que el nuevo proveedor permite acceso SSH, cron jobs y que su panel no te bloquea funciones de PHP que PrestaShop necesita (exec, shell_exec en algunos casos para tareas de mantenimiento).

Subida eficiente de archivos

Olvídate de subir 12 GB por FTP archivo a archivo. Comprime todo en un único .tar.gz por SSH en el origen, transfiérelo con rsync o scp al nuevo servidor y descomprime allí. Tarda minutos en lugar de horas, y te ahorra los típicos archivos corruptos por timeouts.

Permisos y propietario

Una vez descomprimido, ajusta permisos. La regla habitual: 755 para carpetas, 644 para ficheros, y el propietario el usuario del servicio web (suele ser www-data o el usuario del cPanel). Si te saltas este paso, vas a ver errores de "no se puede escribir en /var/cache" durante días.

Base de datos

Crea la nueva BBDD vacía, importa el SQL y actualiza las credenciales en app/config/parameters.php (PrestaShop 1.7+) o config/settings.inc.php (1.6). Si cambias de dominio, hay que actualizar las URL en las tablas ps_shop_url y ps_configuration (claves PS_SHOP_DOMAIN y PS_SHOP_DOMAIN_SSL). Un UPDATE mal hecho aquí deja la tienda inaccesible, así que ojo con el WHERE.

Mi recomendación: trabaja contra un subdominio temporal tipo nueva.tutienda.es hasta que todo funcione, y solo entonces apunta el dominio real.

Módulos, pasarelas de pago y los problemas que nadie te avisa

Aquí es donde la mayoría de migraciones empiezan a chirriar. Los módulos de PrestaShop son su mayor virtud y su mayor dolor de cabeza. En una tienda media te puedes encontrar entre 40 y 80 instalados, y al menos un 20% son incompatibles, abandonados o de pago caducado.

El orden que funciona

1. Limpia la caché completa desde el back office del nuevo entorno (Parámetros avanzados > Rendimiento).
2. Revisa el listado de módulos y desactiva los que no uses. Cada módulo activo es un punto potencial de fallo.
3. Reinstala los módulos críticos uno a uno: pasarela de pago (Redsys, Stripe, Bizum), transportistas (SEUR, MRW, GLS, Correos Express), conectores con ERP o factura electrónica.
4. Verifica licencias. Algunos módulos premium se atan a dominio o IP, y al mover el sitio dejan de funcionar hasta que pides reactivación al desarrollador.

Pasarelas de pago: el punto más delicado

Si trabajas con Redsys, el TPV virtual suele estar vinculado a la URL de respuesta. Cuando cambias de servidor o dominio, hay que avisar al banco para que actualice la URL de notificación, o las confirmaciones de pago no llegarán y los pedidos quedarán en "pago pendiente" eternamente. Stripe y PayPal son más flexibles, pero igual hay que repasar los webhooks.

Otro detalle: con la entrada plena de Veri*Factu en España, asegúrate de que tu módulo de facturación sigue siendo compatible tras la migración. Algunos módulos legacy generan facturas que ya no cumplen los nuevos requisitos de la AEAT, y eso es un problema para cualquier autónomo o SL que venda online.

Migrar PrestaShop sin perder SEO: redirecciones, sitemap y Search Console

El apartado SEO es el que más ventas se carga si lo descuidas. He visto tiendas perder un 40% del tráfico orgánico en dos semanas por no preparar las redirecciones. Y recuperarlo lleva meses.

Si mantienes dominio y estructura de URLs

Felicidades, este bloque es casi un trámite. Repasa que las URL amigables están activadas (Parámetros de tráfico > SEO & URLs), regenera el .htaccess y comprueba que un puñado de URL aleatorias del antiguo sitio devuelven 200 en el nuevo.

Si cambias de dominio o de estructura

Aquí toca trabajo fino. Necesitas un mapa de redirecciones 301 antiguo → nuevo. Exporta el listado completo de URL de Search Console y Screaming Frog, monta el mapeo en una hoja de cálculo y genera las reglas RewriteRule en .htaccess o, mejor, un módulo dedicado como "301 Redirects" para no tocar el htaccess a mano.

Checklist SEO post-migración

• Sitemap XML regenerado y enviado a Search Console.
• Robots.txt revisado (cuidado con que no quede el Disallow: / del staging).
• Canonicals apuntando al dominio correcto.
• Datos estructurados (Producto, Breadcrumb) validados con Rich Results Test.
• Velocidad medida con PageSpeed Insights antes y después.
• Verificación del dominio en Search Console y Bing Webmaster Tools.

Una migración sin plan de redirecciones es como mudarte sin avisar a Correos: el cartero (Google) sigue llamando a la puerta vieja durante meses.

Si el proyecto va más allá de un cambio de hosting y estás planteando rehacer la tienda, te interesa leer cómo enfocamos una migración de ecommerce completa, con auditoría SEO previa y plan de contenidos. No es lo mismo mover archivos que reconstruir la arquitectura.

Validación final, puesta en producción y monitorización

Llegados a este punto tienes la tienda funcionando en el nuevo servidor sobre subdominio temporal o IP. Antes de apuntar el dominio definitivo, dedica un par de horas a probar todo el flujo como si fueras un cliente real.

Pruebas que no puedes saltarte

1. Compra completa con cada método de pago activo, usando importes pequeños reales (1 €, 2 €). No vale el modo test si no lo configuras igual que producción.
2. Cálculo de portes a varias provincias, incluyendo Canarias, Baleares, Ceuta y Melilla, que tienen sus propias reglas fiscales.
3. Generación de factura y verificación de que cumple los requisitos vigentes (Veri*Factu si aplica).
4. Envío de emails transaccionales: confirmación de pedido, cambio de estado, recuperación de contraseña.
5. Back office: login de empleados, gestión de pedidos, exportación de informes.

El cambio de DNS

Cuando todo funciona, baja el TTL de los DNS a 300 segundos unas 24-48 horas antes del cambio. Así la propagación es casi instantánea. Activa el modo mantenimiento en la tienda antigua, haz un último volcado de pedidos generados durante la ventana, impórtalos en la nueva y apunta DNS.

Durante las primeras 72 horas, monitoriza con lupa: logs de error de PHP, errores 404 en Search Console, ratio de conversión en Analytics 4 y, sobre todo, los pedidos por hora comparados con la semana anterior. Si algo cae de golpe, es la pista de que algún módulo o redirección no está bien.

Para tiendas que han crecido y se les ha quedado pequeño PrestaShop, esta también es una buena ocasión para replantear la plataforma. Hablamos a fondo del tema en nuestra sección de comercio electrónico, donde comparamos PrestaShop con otras opciones según el modelo de negocio.

Errores típicos y cómo no caer en ellos

Para cerrar, te dejo el resumen mental de los tropiezos que más vemos. Algunos parecen de Perogrullo, pero te aseguro que los he vivido más de una vez incluso con equipos técnicos solventes.

• Migrar sin actualizar versión de PHP cuando toca. PrestaShop 8 no funciona con PHP 7.4, pero hay módulos viejos que petan en PHP 8.2. Verifica la matriz de compatibilidad antes.
• Olvidar la carpeta /img. Pesa mucho y a veces se omite por error. Resultado: catálogo sin fotos.
• No regenerar miniaturas tras el cambio. Las imágenes salen pixeladas o no aparecen en categorías.
• Dejar el dominio del staging en algún campo de configuración o en plantillas de email. Tus clientes reciben enlaces a nueva.tutienda.es que no existe.
• No avisar a Redsys / pasarela del cambio de URL de notificación.
• Olvidar los cron jobs en el nuevo servidor: indexación, limpieza de carritos abandonados, sincronización con ERP.
• Comerse el RGPD: si cambias de proveedor de hosting, actualiza el registro de actividades de tratamiento y, si procede, el aviso legal y la política de privacidad.

En mi experiencia, las migraciones de PrestaShop salen mal por exceso de confianza más que por falta de conocimientos. Es un proceso largo, pesado y aburrido en buena parte, y el cerebro tiende a saltarse pasos cuando ya llevas seis horas con el portátil. Por eso un checklist físico, impreso, marcado con bolígrafo, sigue siendo la herramienta más eficaz que conozco.

Migrar PrestaShop bien hecho es invisible: el cliente no se entera, los pedidos siguen entrando y el SEO se mantiene. Mal hecho, es un fin de semana de horas extra, llamadas al banco y disculpas a clientes que no pueden pagar. La diferencia rara vez está en la habilidad técnica, sino en la planificación previa y en respetar el orden de pasos.

Si tu tienda factura lo suficiente como para que un día de caída duela de verdad, plantea la migración con calma, ventana de mantenimiento clara y un plan B por escrito. Y si ves que el alcance se te va de las manos — versiones que saltar, integraciones con ERP, catálogo enorme — apóyate en gente que haya hecho esto decenas de veces. Sale más barato que reconstruir lo que se rompe.