“Otro cliente llamando porque su web está caída. Es el tercero esta semana.”
Así empezó la conversación con Estudio Digital Norte, una agencia web de Bilbao con 47 sitios WordPress bajo gestión. Llevaban dos años con hosting compartido y el modelo se había quedado pequeño.
Este caso de estudio documenta cómo migraron toda su infraestructura a un VPS cPanel administrado, los problemas que encontraron en el camino y los resultados medibles tras 6 meses de operación.
El punto de partida: hosting compartido al límite
Perfil de la agencia
Estudio Digital Norte es una agencia de marketing digital con sede en Bilbao. Su modelo de negocio incluye:
- Diseño y desarrollo WordPress
- Mantenimiento mensual de sitios
- Gestión de campañas publicitarias
- SEO y contenidos
| Métrica | Valor |
|---|---|
| Sitios gestionados | 47 WordPress |
| Clientes activos | 38 |
| Tráfico mensual total | ~180.000 visitas |
| Tiendas WooCommerce | 8 |
| Empleados técnicos | 2 |
La infraestructura problemática
Tenían los 47 sitios distribuidos en 3 planes de hosting compartido con diferentes proveedores:
- Proveedor A: 22 sitios en plan “ilimitado”
- Proveedor B: 15 sitios en reseller básico
- Proveedor C: 10 sitios en hosting premium
Coste mensual total: 127€
Los problemas acumulados
Durante nuestra llamada inicial, el responsable técnico de la agencia describió una situación que conocemos bien:
1. Caídas frecuentes
“El proveedor A nos tumba webs constantemente. Dicen que superamos los límites de CPU, pero no nos dan datos concretos. El mes pasado tuvimos 4 caídas que duraron más de 2 horas cada una.”
2. Velocidad inconsistente
“Las webs cargan rápido a las 3 de la madrugada y lentas a mediodía. GTmetrix nos da resultados diferentes cada vez que medimos. Es imposible optimizar así.”
3. Soporte fragmentado
“Cuando hay un problema, tengo que abrir tickets en 3 sitios diferentes. Y cada proveedor dice que el problema es del otro o del cliente.”
4. Sin control real
“No puedo instalar Redis, no puedo cambiar la versión de PHP sin esperar días, no puedo ver los logs reales. Estoy ciego.”
5. Límites de correo
“Dos clientes tienen listas de más de 5.000 suscriptores. El hosting compartido los bloquea por ‘exceso de envíos’ aunque usen plataformas externas como Mailchimp.”
El detonante final
En septiembre, una tienda WooCommerce de un cliente importante cayó durante 6 horas en pleno Black Friday. El cliente perdió ventas estimadas en 4.000€ y amenazó con rescindir el contrato de mantenimiento.
“Ese día decidí que necesitábamos una solución real, no parches.”
La solución: VPS cPanel administrado
Tras evaluar opciones (AWS, DigitalOcean con panel propio, VPS no administrado), eligieron un VPS cPanel administrado por estas razones:
Por qué VPS y no cloud DIY
“Somos 2 personas técnicas y no podemos dedicar 20 horas semanales a administrar servidores. Necesitamos algo que funcione y que alguien más mantenga actualizado y seguro.”
Por qué cPanel
“Nuestros clientes conocen cPanel. Cuando necesitan subir un archivo o crear un correo, pueden hacerlo solos. No quiero 47 llamadas explicando interfaces nuevas.”
La configuración elegida
| Componente | Especificación |
|---|---|
| Plan | VPS cPanel 8 GB RAM |
| CPU | 4 vCores dedicados |
| Almacenamiento | 200 GB NVMe |
| Servidor web | LiteSpeed Enterprise |
| Panel | cPanel/WHM incluido |
| Seguridad | Imunify360 incluido |
| Backups | Diarios externos incluidos |
| Coste mensual | 89€ |
Ahorro vs hosting compartido: 38€/mes (127€ → 89€)
El proceso de migración
La migración se planificó en 3 fases durante 2 semanas, minimizando el riesgo de problemas.
Fase 1: Preparación (Días 1-2)
Auditoría de los 47 sitios:
Antes de migrar, documentamos cada sitio:
- Versión de WordPress y PHP requerida
- Plugins activos y sus requisitos
- Tamaño de base de datos
- Configuraciones especiales (.htaccess, wp-config)
- Cuentas de correo asociadas
Resultado de la auditoría:
| Categoría | Cantidad | Notas |
|---|---|---|
| WordPress estándar | 31 | Sin requisitos especiales |
| WooCommerce | 8 | Requieren más RAM/CPU |
| Multisitio | 2 | Configuración especial |
| Con staging | 6 | Migrar también entornos dev |
| PHP 7.4 legacy | 4 | Actualizar tras migración |
Reducción de TTL DNS:
48 horas antes de empezar, redujimos el TTL de todos los dominios a 300 segundos. Esto permite cambios DNS rápidos durante la migración.
Fase 2: Migración por lotes (Días 3-10)
Migramos en grupos de 10-12 sitios por día, priorizando por criticidad inversa (los menos importantes primero para detectar problemas).
Lote 1 (Día 3): 12 sitios de bajo tráfico
Usamos WHM Transfer Tool para migrar desde cPanel a cPanel. El proceso:
- Crear cuenta en VPS con mismo usuario
- Iniciar transferencia desde WHM → Transfers → Transfer Tool
- Verificar archivos, bases de datos y correos
- Probar con archivo hosts antes de cambiar DNS
- Cambiar DNS y monitorizar
Tiempo por sitio: 15-20 minutos Problemas encontrados: 0
Lote 2 (Día 5): 11 sitios incluyendo 2 WooCommerce
Mismo proceso. Un sitio WooCommerce mostró error de conexión a base de datos tras migrar.
Causa: El wp-config.php tenía la IP del servidor anterior hardcodeada en lugar de “localhost”. Solución: Editar wp-config.php → 2 minutos.
Lote 3 (Día 7): 12 sitios incluyendo el multisitio
El WordPress Multisitio requirió atención especial:
- Migración estándar con Transfer Tool
- Actualizar tabla wp_blogs con nueva IP
- Verificar que todos los subsitios resuelven correctamente
- Regenerar .htaccess del multisitio
Tiempo adicional para multisitio: 45 minutos
Lote 4 (Día 9): 12 sitios restantes, incluyendo tiendas críticas
Los sitios más importantes al final, cuando ya teníamos experiencia con el proceso.
Programamos la migración de las tiendas WooCommerce para domingo a las 6:00 AM (mínimo tráfico).
Downtime real por tienda: 8-12 minutos cada una.
Fase 3: Optimización post-migración (Días 11-14)
Con todo migrado, dedicamos tiempo a optimizar:
1. Activar LSCache en todos los WordPress
Desde WHM → LiteSpeed → Manage Cache Installations, escaneamos e instalamos LSCache en los 47 sitios de una vez.
Configuramos el preset “Advanced” como base y ajustamos exclusiones para WooCommerce en las 8 tiendas.
Guía detallada: Configurar LiteSpeed en VPS cPanel
2. Estandarizar versiones de PHP
Actualizamos los 4 sitios legacy de PHP 7.4 a PHP 8.1, corrigiendo las incompatibilidades (principalmente avisos de deprecación).
3. Configurar staging para todos
Usando el WordPress Toolkit de cPanel, creamos entornos de staging para los 47 sitios. Algo imposible en hosting compartido por límites de espacio y cuentas.
4. Revisar seguridad
Con Imunify360 ya configurado, solo tuvimos que revisar que todos los sitios pasaran el escaneo inicial.
Resultado: 3 sitios tenían archivos sospechosos heredados del hosting anterior. Imunify los detectó y limpió automáticamente.
Resultados medibles: 6 meses después
Disponibilidad (uptime)
| Período | Hosting compartido | VPS cPanel |
|---|---|---|
| Caídas/mes | 4-6 | 0 |
| Downtime total/mes | 8-12 horas | 12 minutos (mantenimiento) |
| Uptime real | 96.2% | 99.97% |
“En 6 meses no hemos tenido ni una sola llamada de cliente por web caída. Antes era semanal.”
Velocidad de carga
Mediciones con GTmetrix (servidor Frankfurt) para una muestra de 10 sitios:
| Métrica | Antes | Después | Mejora |
|---|---|---|---|
| TTFB promedio | 1.2s | 0.18s | -85% |
| LCP promedio | 4.1s | 0.9s | -78% |
| Tiempo carga total | 5.8s | 1.3s | -78% |
| PageSpeed Score | 42 | 89 | +112% |
Caso destacado: Tienda WooCommerce principal
| Métrica | Antes | Después |
|---|---|---|
| Tiempo carga home | 6.2s | 1.1s |
| Tiempo carga producto | 4.8s | 0.8s |
| Tiempo checkout | 5.1s | 1.3s |
Rendimiento WooCommerce
Las 8 tiendas WooCommerce mostraron mejoras significativas en conversión:
| Métrica | Antes (media) | Después (media) | Cambio |
|---|---|---|---|
| Tasa rebote | 62% | 41% | -34% |
| Páginas/sesión | 2.1 | 3.4 | +62% |
| Tiempo en sitio | 1:23 | 2:47 | +101% |
| Tasa conversión | 1.8% | 2.4% | +33% |
“El cliente de la tienda que cayó en Black Friday nos dijo que este año facturó un 40% más. No todo es por la velocidad, pero ayuda.”
Productividad del equipo
| Tarea | Tiempo antes | Tiempo ahora |
|---|---|---|
| Crear cuenta nueva | 15-30 min (depende proveedor) | 3 min |
| Cambiar versión PHP | 24-72h (ticket soporte) | 2 min |
| Revisar logs de error | Imposible | 1 min |
| Crear staging | No disponible | 1 min |
| Restaurar backup | 2-4h (ticket) | 15 min |
“Antes perdía media mañana en tareas administrativas. Ahora lo hago en minutos y dedico ese tiempo a trabajo que facturamos.”
Arquitectura final
Distribución de recursos
| Recurso | Asignación |
|---|---|
| RAM total | 8 GB |
| RAM por cuenta (media) | ~120 MB |
| RAM para MySQL | 2 GB (InnoDB buffer) |
| RAM para LiteSpeed | 1.5 GB |
| Disco usado | 78 GB de 200 GB |
| Cuentas cPanel | 47 + 1 (desarrollo interno) |
Stack tecnológico
┌─────────────────────────────────────────┐
│ CloudLinux + cPanel │
├─────────────────────────────────────────┤
│ LiteSpeed Enterprise + LSCache │
├─────────────────────────────────────────┤
│ PHP 8.1/8.2 (LSAPI) │
├─────────────────────────────────────────┤
│ MariaDB 10.6 (optimizado) │
├─────────────────────────────────────────┤
│ Imunify360 + CSF (Legacy) + cPHulk │
├─────────────────────────────────────────┤
│ Backups diarios externos │
└─────────────────────────────────────────┘Monitorización implementada
- Uptime Robot: Ping cada 5 minutos a los 47 sitios
- GTmetrix: Medición semanal automatizada de 10 sitios muestra
- WHM → Server Status: Revisión diaria de recursos
- Imunify360 alertas: Email inmediato si detecta amenazas
Lecciones aprendidas
Lo que funcionó bien
1. Migrar por lotes pequeños
Dividir en grupos de 10-12 sitios permitió detectar problemas sin afectar a todo el portfolio. Si hubiéramos migrado los 47 de golpe, cualquier error habría sido caótico.
2. Reducir TTL con antelación
Los cambios DNS propagaron en minutos en lugar de horas. Crítico para minimizar downtime.
3. Probar con archivo hosts
Verificar cada sitio antes de cambiar DNS evitó sorpresas. Encontramos 3 problemas que habrían causado downtime visible.
4. Documentar todo
El documento de auditoría inicial nos salvó varias veces. Cuando algo no funcionaba, teníamos la referencia de cómo estaba configurado originalmente.
Lo que podríamos haber hecho mejor
1. Empezar antes con la optimización
Esperamos a tener todo migrado para activar LSCache. Podríamos haberlo hecho sitio a sitio durante la migración.
2. Comunicación proactiva a clientes
Avisamos a los clientes después de migrar sus sitios. Habría sido mejor avisar antes para que no se alarmaran si veían algo raro durante el proceso.
3. Staging desde el día 1
Creamos los entornos de staging al final. Si los hubiéramos creado durante la migración, habríamos podido probar actualizaciones pendientes inmediatamente.
ROI: ¿Mereció la pena?
Inversión
| Concepto | Coste |
|---|---|
| VPS cPanel (anual) | 1.068€ |
| Tiempo migración (40h × 35€/h) | 1.400€ |
| Total primer año | 2.468€ |
Ahorro y beneficios
| Concepto | Valor anual |
|---|---|
| Ahorro en hosting (38€ × 12) | 456€ |
| Tiempo admin ahorrado (8h/mes × 35€ × 12) | 3.360€ |
| Clientes no perdidos por caídas (estimado) | 2.400€ |
| Total beneficio primer año | 6.216€ |
ROI primer año
ROI = (6.216€ - 2.468€) / 2.468€ = 152%
A partir del segundo año, sin coste de migración:
ROI anual recurrente = (6.216€ - 1.068€) / 1.068€ = 482%
¿Tu agencia está en una situación similar?
El VPS cPanel administrado de Avantys incluye migración gratuita de todos tus sitios. Nuestro equipo técnico se encarga del proceso completo mientras tú sigues trabajando.
FAQ del caso de estudio
¿Por qué no eligieron servidores cloud como AWS o Google Cloud?
“Evaluamos AWS, pero el modelo de precios variables nos asustaba. Con 47 sitios y tráfico fluctuante, no podíamos predecir el coste mensual. Además, necesitaríamos contratar a alguien para administrarlo o dedicar tiempo que no tenemos.”
¿8 GB de RAM son suficientes para 47 sitios?
Para sitios WordPress con LSCache activo, sí. La caché reduce drásticamente el uso de PHP y MySQL. En picos de tráfico, hemos llegado a usar 6.5 GB, pero nunca nos hemos quedado sin recursos.
¿Qué pasaría si un sitio recibe un pico viral de tráfico?
Con LSCache, un sitio puede servir miles de visitas simultáneas sin impactar a los demás. LiteSpeed maneja las conexiones de forma más eficiente que Apache. En el peor caso, CloudLinux aísla las cuentas para que un sitio problemático no afecte al resto.
¿Los clientes notaron el cambio?
Los que tenían tiendas notaron que “la web va más rápida”. Los demás no notaron nada, que era el objetivo. Migración transparente.
¿Habéis tenido algún problema en estos 6 meses?
Un sitio WordPress se infectó con malware porque el cliente instaló un plugin pirata. Imunify360 lo detectó en minutos, limpió los archivos y nos avisó. Tiempo de impacto: prácticamente cero.
¿Recomendaríais este setup a otras agencias?
“Sin duda. Si gestionas más de 20 sitios WordPress, el hosting compartido es una bomba de relojería. Un VPS administrado con cPanel es la opción lógica: control total sin la carga de administrar un servidor.”
Conclusión
La migración de Estudio Digital Norte ilustra un patrón que vemos frecuentemente: agencias que han crecido más allá de lo que el hosting compartido puede ofrecer.
Los indicadores de que necesitas dar el salto:
- Más de 20 sitios gestionados
- Caídas frecuentes “por exceso de recursos”
- Clientes con tiendas online o alto tráfico
- Frustración constante con el soporte
- Tiempo perdido en tareas que deberían ser instantáneas
El resultado típico tras migrar a VPS cPanel administrado:
- Disponibilidad superior al 99.9%
- Velocidad de carga 3-5 veces mejor
- Control total sobre la configuración
- Menos tiempo en administración, más en trabajo facturable
- Clientes más satisfechos y menos rotación
Si tu agencia está en una situación similar, el VPS cPanel de Avantys ofrece exactamente este tipo de solución, con migración incluida y soporte técnico en español.
Guías técnicas relacionadas
¿Quieres implementar algo similar? Estas guías te ayudarán:
Migración
Configuración y optimización
- Configurar LiteSpeed en VPS cPanel
- VPS cPanel vs VPS Plesk: ¿Cuál elegir?
- Cómo cambiar la versión de PHP en cPanel
Seguridad
Fundamentos
- Qué es un VPS y para qué sirve
- VPS administrado vs no administrado
- Hosting compartido vs VPS: cuándo cambiar
Caso de estudio basado en cliente real. Algunos datos han sido modificados por confidencialidad. Diciembre 2025.
VPS cPanel Administrado
La potencia de un VPS con la facilidad de cPanel. Soporte en español.
