Migrar un sitio Drupal desde Acquia Cloud sin olvidar lo importante

Desde ya hace unos años trabajamos con Acquia Cloud. Ahora estamos evaluando migrar hacia alternativas más económicas, y eso me llevó a revisar con más cuidado todo lo que una migración de este tipo implica. Como parte de esa investigación fui armando esta guía para orientarme.

He realizado varias veces la migración a un entorno local usando DDEV, pero siempre hay puntos que conviene recordar. Justamente de ahí nace esta nota: no tanto como un manual definitivo, sino como una guía de trabajo para no olvidar lo esencial cuando toca mover un sitio Drupal fuera del ecosistema de Acquia.

Porque una cosa es decir “vamos a migrar el sitio”, y otra muy distinta es recordar qué pasa con Site Studio, con los archivos, con las configuraciones específicas de Acquia, con el rendimiento que antes resolvía la plataforma y con el flujo de despliegue que ya no viene dado automáticamente.

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

Cuando un sitio ha vivido bastante tiempo dentro de Acquia Cloud, el primer error sería pensar que la migración consiste solo en mover código, base de datos y archivos. A veces sí, pero otras veces no. Y ahí suele aparecer la parte más delicada: las dependencias del ecosistema.

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 real 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 inicial cambia completamente 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 quieres salir también 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.

Mi impresión es que esta decisión no se debería tomar al final, sino al principio. Porque afecta tiempos, prioridades y expectativas del proyecto.

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

Después de la evaluación del código, viene la parte clásica de toda migración: la base de datos y los archivos subidos. Y aunque esto suena rutinario, 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.

Y aquí está uno de esos detalles que siempre vale la pena revisar: las rutas configuradas en settings.php y en la propia 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

Uno de los grandes beneficios de Acquia Cloud es que resuelve una serie de cosas que, cuando uno se va a un VPS o a otro 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.

En otras palabras, 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. Y aunque no es exactamente lo mismo que mover el sitio a un VPS final, sí me sirve como laboratorio muy práctico para comprobar si el sitio realmente sobrevive fuera de Acquia.

Eso tiene bastante valor porque el entorno local obliga a enfrentar rápido varios de los 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.

Por eso, si tengo que recomendar un paso previo claro, sería este: hacer la migración local primero. DDEV, Lando o cualquier entorno equivalente sirve para convertir una migración teórica en una prueba más concreta.

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

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 suele ahorrar a largo plazo: 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

Si tuviera que resumir la migración en una lista breve para orientarme, sería algo 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, pero sí una secuencia bastante útil para no improvisar.

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

En el fondo, esta guía salió por una razón bastante concreta: estamos considerando alternativas más económicas. Y 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.

Por eso, migrar fuera de Acquia puede ser una oportunidad. 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 justamente ahí está el valor.

Conclusión

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

En mi caso, esta guía nació para orientarme en ese proceso y para 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 importantes.

Y si algo me deja claro cada vez que reviso estos pasos, es esto: 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