Migrar un sitio Drupal desde Acquia Cloud sin olvidar lo importante

Desde hace algunos años trabajamos con Acquia Cloud. Ahora estamos evaluando alternativas más económicas, y eso me obligó a revisar con más cuidado qué implica sacar un sitio Drupal de ese entorno. Esta guía salió de esa revisión.

He migrado varias veces sitios a un entorno local con DDEV, pero siempre hay detalles que se pueden pasar por alto. Esta nota no pretende ser un manual definitivo. Es una guía de trabajo para no olvidar lo básico cuando toca mover un sitio Drupal fuera del ecosistema de Acquia.

Una cosa es decir “vamos a migrar el sitio”. Otra es revisar qué pasa con Site Studio, los archivos, las configuraciones de Acquia, el rendimiento que antes resolvía la plataforma y el flujo de despliegue que ya no viene armado.

El primer punto: entender de qué depende realmente el sitio

Cuando un sitio ha vivido mucho tiempo dentro de Acquia Cloud, el primer error es pensar que la migración consiste solo en mover código, base de datos y archivos. A veces basta con eso. Otras veces aparecen dependencias del ecosistema que cambian el alcance del trabajo.

En particular, si el sitio utiliza Acquia Site Studio -antes conocido como Cohesion-, hay que detenerse un momento. Site Studio agrega módulos propios, configuraciones y una forma muy particular de construir layouts y componentes visuales. Si el sitio se apoya mucho en eso, salir de Acquia deja de ser solo un cambio de infraestructura y empieza a tocar el modelo mismo de construcción del frontend.

Por eso, el primer paso no es exportar nada. Es evaluar el grado de dependencia.

Conviene revisar al menos esto:

• si el sitio usa módulos específicos como cohesion, cohesion_elements o similares;
• si depende de módulos propios de Acquia como acquia_connector o acquia_purge;
• qué versión de Drupal está corriendo;
• y qué versión de PHP y dependencias necesita para seguir funcionando igual fuera de la plataforma actual.

Ese diagnóstico cambia el tipo de migración que vas a enfrentar.

Site Studio: la pregunta incómoda que hay que responder temprano

Si el sitio usa Site Studio, hay una pregunta que conviene responder desde el comienzo: ¿quieres seguir usando Site Studio o también quieres salir de esa dependencia?

Ambas opciones son válidas, pero implican costos distintos.

Si decides mantener Site Studio, necesitarás considerar temas como licenciamiento, instalación de sus módulos en el nuevo entorno y restauración de las configuraciones exportadas. En ese escenario, la migración se parece más a una reubicación técnica.

Si decides abandonarlo, el trabajo ya no es solo técnico. También hay una capa de rediseño. Páginas, componentes y experiencias visuales que hoy dependen de Site Studio tendrían que pasar a otra lógica, por ejemplo:

• Layout Builder, si quieres quedarte más cerca del core de Drupal;
• Paragraphs, si prefieres una construcción basada en componentes de contenido;
• Gutenberg u otras alternativas, si buscas una edición más visual.

Esta decisión no debería quedar para el final. Afecta tiempos, prioridades y expectativas del proyecto.

Base de datos y archivos: lo que siempre parece fácil hasta que falla

Después de evaluar el código viene la parte clásica de toda migración: la base de datos y los archivos subidos. Suena rutinario, pero en Drupal conviene tratarlo con cuidado.

Desde Acquia, la base de datos del ambiente deseado puede exportarse con Drush o desde la propia plataforma. Lo importante no es solo sacar el dump, sino entender qué contiene. Si Site Studio está profundamente integrado, buena parte de su configuración vive ahí.

Un flujo básico sería:

drush sql-dump > backup.sql

Los archivos, por su parte, suelen requerir un tratamiento aparte. Multimedia, documentos y otros recursos normalmente viven en sites/default/files o en rutas configuradas de forma personalizada. Eso significa que no basta con un dump de base de datos. También hay que descargar ese volumen de archivos usando SFTP, rsync o el mecanismo que corresponda.

Aquí hay un detalle que siempre reviso: las rutas configuradas en settings.php y en la configuración de Drupal. Muchas veces una migración falla menos por el contenido que por una ruta mal resuelta o una referencia que seguía apuntando al entorno anterior.

El servidor nuevo no es Acquia, así que hay que reconstruir varias comodidades

Acquia Cloud resuelve varias cosas que, al pasar a un VPS o a un proveedor más económico, dejan de venir incluidas.

Drupal necesita una base razonable: servidor web, PHP, base de datos y memoria suficiente. Pero más allá de eso, Acquia suele aportar optimizaciones de infraestructura que luego hay que reconstruir manualmente.

Eso incluye, por ejemplo:

• caché a nivel de plataforma;
• integración más ordenada entre ambientes;
• herramientas de despliegue;
• ajustes de rendimiento;
• y parte de la seguridad operativa.

Si el nuevo destino es un servidor virtual, conviene pensar temprano en cómo suplir eso. En algunos casos bastará con una configuración simple y buen criterio técnico. En otros, quizá haya que incorporar componentes como:

• Redis o Memcached para mejorar caché;
• Cloudflare como CDN y capa de protección;
• mejores políticas de actualización del sistema operativo y de Drupal;
• y una vigilancia más consciente del consumo de memoria, especialmente si el sitio sigue usando Site Studio.

Migrar a una opción más barata no es solo bajar costos. También es asumir más responsabilidad operativa.

El flujo de despliegue también cambia

Cuando uno trabaja mucho tiempo con Acquia, se acostumbra a ciertos automatismos. Repositorio Git, ambientes más claros, despliegues relativamente estructurados. Al salir de ese entorno, hace falta reconstruir ese flujo.

Lo mínimo sería conservar el código en un repositorio propio y pensar cómo se hará el despliegue en adelante. Puede ser algo simple con scripts, o algo más ordenado con CI/CD en GitHub Actions, Jenkins o herramientas similares.

En cualquier caso, hay un conjunto de pasos que conviene recordar en cada despliegue:

composer install
drush updb
drush cr

Puede sonar obvio, pero en Drupal muchas veces lo importante no es solo copiar el código, sino asegurarse de que las dependencias se instalan correctamente, las actualizaciones de base de datos corren y la caché se reconstruye en el nuevo contexto.

DDEV: el espacio donde realmente pruebo antes de mover nada

Hay una parte de la historia que para mí es muy concreta: varias veces he hecho la migración a un entorno local usando DDEV. No es lo mismo que mover el sitio a un VPS final, pero sirve como laboratorio para comprobar si el sitio sobrevive fuera de Acquia.

Eso ayuda porque el entorno local obliga a enfrentar rápido varios problemas reales:

• módulos faltantes;
• configuraciones que dependían del hosting anterior;
• problemas con archivos o rutas;
• incompatibilidades de versión;
• y dependencias de servicios que antes venían resueltas por la plataforma.

Si tengo que recomendar un paso previo, sería este: hacer la migración local primero. DDEV, Lando o cualquier entorno equivalente convierte una migración teórica en una prueba concreta.

No se trata solo de ver si el sitio levanta. Se trata de validar si realmente funciona.

Qué conviene probar antes de pensar en producción

Una vez que el sitio arranca fuera de Acquia, empieza la parte que más tiempo ahorra después: las pruebas.

No basta con abrir la portada y ver que carga. Conviene revisar:

• páginas críticas;
• componentes visuales;
• formularios;
• buscadores;
• integraciones externas;
• comportamiento del sistema de archivos;
• y rendimiento general después de limpiar caché.

En esta etapa, un simple:

drush cr

puede destapar varias cosas que parecían funcionar solo porque todavía estaban servidas desde caché.

También conviene probar con mentalidad de producción: imaginar al usuario real, no al desarrollador que ya conoce el sitio. Porque muchos problemas de migración no aparecen en el código ni en la consola, sino en la experiencia final.

Una lista simple para no olvidar lo esencial

Para orientarme, resumiría la migración así:

1. Revisar dependencias de Site Studio y módulos específicos de Acquia.
2. Confirmar versiones de Drupal, PHP y Composer.
3. Exportar base de datos del ambiente correcto.
4. Copiar archivos subidos y verificar rutas.
5. Montar un entorno local con DDEV para validar la salida de Acquia.
6. Ajustar settings.php y credenciales de base de datos.
7. Ejecutar composer install, drush updb y drush cr.
8. Probar páginas, formularios, componentes e integraciones.
9. Definir caché, CDN y estrategia de rendimiento en el nuevo servidor.
10. Hacer backup completo antes del cambio de DNS.

No es una metodología cerrada. Es una secuencia para no improvisar.

La parte estratégica: por qué salir de Acquia no es solo un tema técnico

Esta guía salió por una razón concreta: estamos considerando alternativas más económicas. Eso obliga a mirar el sistema completo con otros ojos.

Acquia Cloud resuelve muchas cosas, pero también tiene un costo. Cuando uno empieza a evaluar otras opciones, descubre que el problema no es solamente “dónde alojar Drupal”, sino qué dependencias valen la pena mantener y cuáles ya conviene simplificar.

Migrar fuera de Acquia puede servir no solo para ahorrar, sino también para ordenar arquitectura, revisar dependencias heredadas y quedarse con un stack más sostenible.

Claro, eso exige más criterio técnico. Pero a veces ahí mismo está el valor.

Conclusión

Migrar un sitio Drupal alojado en Acquia Cloud es factible, pero no conviene tratarlo como una simple mudanza de hosting. Si el sitio usa Acquia Site Studio, la planificación tiene que ser más cuidadosa, porque la dependencia ya no es solo de infraestructura. También afecta la construcción visual y editorial.

En mi caso, esta guía nació para ordenar el proceso y no olvidar los puntos que siempre reaparecen, sobre todo cuando hago pruebas locales con DDEV. Más que un instructivo rígido, es un mapa de recordatorios.

Cada vez que reviso estos pasos vuelvo a la misma idea: una migración exitosa no depende de recordar un comando brillante, sino de no pasar por alto los detalles que parecen menores hasta que el sitio deja de funcionar.

Recursos

• Entorno local recomendado para pruebas: DDEV
• Herramienta de administración Drupal: Drush