Abandonar el hosting compartido: 5 señales de que ha llegado el momento

Abandonar el hosting compartido se convierte en una necesidad cuando el sitio web deja de ser un escaparate y pasa a ser una operación: tienda que vende, EVA con alumnos, sistema que recibe webhooks de WhatsApp. Esta guía muestra las cinco señales que vemos cada mes en los entornos que recibimos, cómo medir cada una en casa, cuánto cuesta el cambio y cuándo aún no merece la pena cambiar.

TL;DR

• Error 508 o 503 en hora punta casi siempre significa que has alcanzado el límite de procesos simultáneos del plan, y no que "la web se ha caído".
• TTFB por encima de 0,8 s con caché activada es el límite que el propio Google considera "bueno". Si lo supera de forma consistente, el cuello de botella es el servidor.
• PHP 8.2 pierde el soporte de seguridad el 31/12/2026. Si el panel no te permite actualizar la versión a tu ritmo, ya estás atado.
• Gmail exige una tasa de spam inferior al 0,30% e IP fuera de listas negras. En IP compartida, la reputación del vecino también es la tuya.
• No migres solo por estatus: un sitio web institucional con poco tráfico puede seguir en el hosting compartido.

Qué cambia cuando decides abandonar el hosting compartido

En el hosting compartido, cientos de cuentas dividen la misma máquina. Para que nadie tumbe a nadie, el proveedor coloca cada cuenta en una "jaula" de recursos. En el mercado, la herramienta más común para esto es CloudLinux LVE (Lightweight Virtual Environment), que limita CPU, memoria, E/S de disco y cuántos procesos puede ejecutar tu cuenta al mismo tiempo.

Esto no es un defecto, es el modelo de negocio. Funciona muy bien para lo que fue diseñado: sitios web ligeros, con tráfico predecible y sin procesos ejecutándose en segundo plano.

El problema comienza cuando la empresa crece dentro de él. Para escalar, la tabla pública de Hostinger, una de las mayores del segmento, muestra el plan Web Premium con 40 PHP workers, 2 GB de RAM, 1 núcleo de CPU y 400.000 inodes. El plan superior asciende a 60 workers, 3 GB y 2 núcleos. Cada PHP worker atiende una petición a la vez. Cuando todos están ocupados, el siguiente visitante espera o recibe un error.

Abandonar el hosting compartido significa cambiar ese límite fijo por recursos dedicados a tu sistema: una VPS, una instancia en la nube o un entorno gestionado. La pregunta correcta no es "cuál es más rápido", sino quién va a operar la máquina después. Volveremos a esto más adelante.

Soy Cleverson Gouvêa, fundador de Agathas Web. Desde 2008 recibo clientes que llegaron al límite del hosting compartido, desde EVAs Moodle hasta tiendas e integraciones con la API oficial de WhatsApp. Las cinco señales siguientes son las que más aparecen cuando el cliente decide abandonar el hosting compartido definitivamente.

Señal 1: errores 508 y 503 justo en el momento de mayor venta

La primera señal es la más costosa, porque aparece en el peor momento: campaña en marcha, examen online abierto, lista de difusión enviada.

Cómo reconocerlo

• 508 Resource Limit Is Reached: la documentación de LiteSpeed y Plesk describe el mismo motivo. La cuenta alcanzó el límite de entry processes, es decir, de conexiones simultáneas al PHP/servidor web dentro del LVE.
• 503 o 500 intermitente: suele ser desbordamiento de memoria o de número de procesos.
• Sitio web lento, pero sin error: es el límite de CPU o de E/S. El LVE no lo tumba, lo estrangula.

Cómo medirlo

En cPanel con CloudLinux, abre Uso de recursos (Resource Usage). Ahí aparecen los momentos en que la cuenta alcanzó cada límite. Si los "faults" se repiten cada semana a las mismas horas, el problema no es un accidente: es capacidad, y es el primer motivo concreto para abandonar el hosting compartido sin remordimientos.

Cuándo aún no es motivo para abandonar

Si el 508 proviene de un robot rastreando el sitio o de un plugin mal escrito, cambiar de servidor solo traslada el problema. Antes, bloquea bots en Cloudflare, activa la caché de página y mira si los faults desaparecen. Si desaparecen, ganaste un respiro sin gastar. Si continúan con tráfico legítimo, es una señal real de que ha llegado el momento de abandonar el hosting compartido y tener recursos dedicados.

En EVAs esto es aún más claro. Un Moodle con 200 alumnos realizando un cuestionario al mismo tiempo genera muchas más peticiones al PHP que 200 visitas en un sitio web institucional. Explicamos cómo estimar esto en la guía sobre cuántos alumnos simultáneos soporta tu servidor Moodle.

Señal 2: el TTFB no baja de 0,8 s, incluso con caché

TTFB (Time to First Byte) es el tiempo entre que el navegador solicita la página y recibe el primer byte de respuesta. Mide el servidor, no el diseño.

Según web.dev, de Google, un TTFB es bueno hasta 0,8 segundos y malo por encima de 1,8 segundos. El TTFB no es una Core Web Vital, pero las retrasa todas: ninguna imagen se carga antes de que llegue el primer byte.

La prueba que realizamos en todo diagnóstico

1. Ejecuta PageSpeed Insights en la página más importante y anota el TTFB de los datos de campo (usuarios reales, percentil 75).
2. Mide de nuevo en tres horarios: madrugada, media mañana y hora punta.
3. Compara. Si el TTFB es óptimo de madrugada y malo a las 10h, el problema es disputa de recursos, no tu código.

Este patrón tiene nombre en el mercado: vecino ruidoso. Otra cuenta en la misma máquina ejecuta una copia de seguridad pesada o sufre un ataque, y tu sitio web paga las consecuencias. En el hosting compartido no ves al vecino, no sabes quién es y no puedes hacer nada al respecto.

Trampa común

Cambiar a un plan compartido "más caro" rara vez lo resuelve. Ganas más workers, pero continúas en el mismo disco y en la misma CPU disputada. Si el TTFB oscila con el horario, el camino es abandonar el hosting compartido e ir a un recurso dedicado.

Señal 3: el panel decide tu versión de PHP y lo que puede ejecutarse

Esta es la señal que poca gente percibe hasta que se convierte en urgencia.

Según el calendario oficial de php.net, PHP 8.1 perdió todo el soporte el 31/12/2025 y PHP 8.2 solo recibe correcciones de seguridad hasta el 31/12/2026. Después de eso, una nueva vulnerabilidad en el 8.2 ya no recibirá corrección. WordPress hoy recomienda PHP 8.3 o superior y MariaDB 10.11+ o MySQL 8.0+.

En el hosting compartido, tú eliges entre las versiones que el proveedor ofrece, cuando las ofrece. La versión de la base de datos, normalmente, ni siquiera eso.

Lo que más suele quedar fuera

• Cron real: Moodle y varios sistemas Laravel necesitan tareas programadas cada minuto. Muchos planes limitan la frecuencia o terminan procesos largos.
• Procesos persistentes: colas de correo electrónico, workers de Node.js y el receptor de webhooks de la API oficial de WhatsApp necesitan permanecer activos todo el tiempo. El hosting compartido fue diseñado para peticiones cortas.
• Redis y caché de objetos: cuando existe, es compartido o limitado.
• Configuración del servidor web: a partir de Moodle 5.1, la documentación oficial pide que el document root apunte a la carpeta /public. En un panel compartido, esto puede convertirse en un apaño con symlink.

Si necesitas abrir una incidencia para cambiar algo que lleva cinco minutos en un servidor propio, esa es la señal para abandonar el hosting compartido antes de que la prisa decida por ti. Para quienes usan Moodle, los detalles están en Requisitos de servidor para Moodle 5.x.

Señal 4: tus correos electrónicos empiezan a caer en spam

Muchas empresas utilizan el correo electrónico que viene incluido con el hosting. Sale por la misma IP que utilizan cientos de otros clientes.

Google es directo con las reglas para quienes envían a Gmail. Todo remitente necesita SPF o DKIM, DNS inverso (PTR) válido y una tasa de spam inferior al 0,30% en Postmaster Tools, con la recomendación de mantenerse por debajo del 0,10%. Quien envía más de 5.000 mensajes al día necesita SPF, DKIM y DMARC. Sobre IP compartido, el texto de Google dice apenas que no puede estar en ninguna lista negra pública.

El problema es que no controlas esto. Basta una cuenta vecina comprometida enviando spam para que la IP entera entre en una lista, y tu factura, tu presupuesto y tu recuperación de contraseña pasen a caer en el correo no deseado.

Cómo verificar

• Consulta la IP de salida de tu servidor en herramientas de listas negras como la de MXToolbox.
• Envía un correo electrónico a una cuenta de Gmail y abre "Mostrar original": SPF, DKIM y DMARC deben aparecer como PASS.
• Si aparece softfail o la IP está listada más de una vez en el trimestre, el problema es estructural.

Cuándo no es necesario migrar por esto

Si el único problema es el correo electrónico, a veces basta con separar: el sitio web se queda donde está y el correo electrónico va a un proveedor dedicado. Es la solución más barata y lo resuelve al instante, sin necesidad de abandonar el hosting compartido solo por la bandeja de entrada.

Señal 5: el sitio web genera ingresos, pero nadie responde por él

La última señal no aparece en el panel. Aparece en la pregunta: si se cae a las 23h del viernes, ¿quién atiende?

En el hosting compartido, el contrato cubre la máquina, no tu aplicación. El soporte confirmará que el servidor está en línea. Si el problema es tu WordPress, tu Moodle o tu base de datos corrupta, es tu responsabilidad.

Preguntas que exponen el riesgo

• Copia de seguridad: ¿existe copia fuera del servidor? ¿Cuándo fue la última restauración probada? Una copia de seguridad que nunca ha sido restaurada es solo una esperanza.
• Actualización: ¿quién aplica parches del sistema, del PHP y de los plugins críticos? ¿En cuánto tiempo después de un fallo público?
• Incidente: ¿existe tiempo de respuesta por escrito? ¿Existe multa si no se cumple?
• RGPD: si el sitio web guarda datos de alumnos o clientes, ¿puedes probar quién accede al servidor y cómo se protegen las copias de seguridad?

Cuando la respuesta a tres de estas cuatro es "no sé", el riesgo no es técnico. Es de negocio, y quizás sea el motivo más fuerte para abandonar el hosting compartido. Una hora de inactividad en una tienda o en un EVA en semana de exámenes cuesta más que un año de diferencia en la mensualidad.

Cuándo NO merece la pena abandonar el hosting compartido

La honestidad aquí ahorra dinero. No todas las empresas necesitan abandonar el hosting compartido ahora. Hay casos en los que nuestra recomendación es quedarse:

• Sitio web institucional con pocas centenas de visitas al día, sin tienda, sin inicio de sesión de cliente.
• Landing page de campaña temporal, que puede ir a un hosting estático o CDN.
• Blog personal o proyecto en validación, sin ingresos que dependan de él.
• Problema de código, no de servidor: plugin pesado, consulta sin índice, imagen de 4 MB en la página de inicio. Esto se trasladará a cualquier servidor.

La regla que usamos: si ninguna de las cinco señales aparece con frecuencia y el sitio web no factura directamente, el hosting compartido con Cloudflare delante suele ser suficiente. Abandonar el hosting compartido antes de tiempo solo cambia una cuenta barata por una cara con el mismo resultado.

Adónde ir y cuánto cuesta abandonar el hosting compartido

VPS, nube o hosting gestionado

Después de decidir abandonar el hosting compartido definitivamente, el error más común es contratar una VPS barata creyendo que lo ha resuelto. La máquina es más potente, pero ahora toda la operación es tuya: firewall, actualización, copia de seguridad, monitorización, certificado, correo electrónico.

Criterio	Compartido	VPS sin gestión	Nube (AWS, etc.)	Hosting gestionado
Recursos	Compartidos, con límite fijo	Dedicados	Elásticos	Dedicados y dimensionados
Versión de PHP/base de datos	Lo que ofrece el panel	Tú eliges y mantienes	Tú eliges y mantienes	Elegida y mantenida por el equipo
Procesos y cron	Limitados	Libres	Libres	Libres y monitorizados
Seguridad y parches	Del proveedor (solo la máquina)	Tuya	Tuya	Del equipo, con plazo
Copia de seguridad probada	Raro	Tuya	Tuya	Incluida y restaurada
Quién atiende el incidente	Cola de soporte	Tú	Tú	Equipo con SLA
Coste mensual típico	Bajo	Bajo	Variable	Medio, predecible

Si tu empresa tiene un sysadmin, una VPS puede ser óptima. Si no tiene, la diferencia real entre VPS y gestionado está en quién se levanta de madrugada. Detallamos esa división de responsabilidades en Hosting gestionado vs VPS: quién se encarga de qué cuando el sitio web se cae.

Qué incluye el coste

El coste de abandonar el hosting compartido tiene dos partes: la nueva mensualidad y la migración en sí.

• Mensualidad: en nuestro hosting gestionado, sitios web institucionales y blogs se sitúan entre R$ 250 y R$ 500 al mes; e-commerce y SaaS, entre R$ 600 y R$ 2.500. (Precios de referencia del mercado brasileño)
• Configuración y migración: de R$ 800 a R$ 3.500, conforme la complejidad (cantidad de sitios web, correos electrónicos, bases de datos e integraciones). (Precios de referencia del mercado brasileño)
• Coste oculto del "hazlo tú mismo": horas de alguien del equipo aprendiendo a configurar el servidor, y el riesgo de equivocarse justo en el cambio.

Hoja de ruta para migrar sin tumbar el sitio web

1. Inventario: sitios web, bases de datos, cuentas de correo electrónico, crons, integraciones y registros DNS.
2. Bajar el TTL del DNS a 300 segundos con al menos 48 horas de antelación.
3. Montar el nuevo entorno con la versión de PHP y de base de datos correctas, y probar en un dominio interno.
4. Validar con el cliente antes de cambiar. Formulario, checkout, login y envío de correo electrónico.
5. Cambio en ventana de bajo tráfico, con sincronización final de la base de datos.
6. Mantener el entorno antiguo intacto por un tiempo, para poder revertir si es necesario.

Quien decide abandonar el hosting compartido suele tropezar siempre en el mismo punto. La trampa clásica es olvidar el correo electrónico. El sitio web migra perfecto y, el lunes, nadie recibe mensajes porque el registro MX aún apunta al servidor antiguo, o la bandeja de entrada fue eliminada junto con el plan.

Cómo Agathas Web resuelve esto

No revendemos cPanel. El hosting gestionado de Agathas Web es un entorno configurado para la stack que utilizas (WordPress, Laravel, Next.js, Node, Python o Moodle) y operado por el mismo equipo que lo configuró.

Qué incluye

• Recursos dedicados, dimensionados según el uso real medido en el diagnóstico, sin límite de entry processes.
• Versiones actualizadas de PHP, base de datos y sistema operativo, con parche crítico aplicado en un máximo de 72 horas después de que la vulnerabilidad se haga pública, siempre pasando por staging.
• Cloudflare con WAF, fail2ban, hardening del sistema y SSL automático en todos los dominios.
• Copia de seguridad diaria e incremental, fuera del servidor y cifrada, con restauración probada cada mes.
• Correo electrónico corporativo con SPF, DKIM y DMARC configurados correctamente.
• Monitorización 24/7 con alertas al equipo técnico y SLA contractual: uptime del 99,9%, respuesta a incidentes críticos en un máximo de 15 minutos y multa si no cumplimos.

Cómo funciona la contratación

1. Solicitas el diagnóstico gratuito de la infraestructura actual. En un máximo de 3 días hábiles señalamos riesgos, cuellos de botella y el plan de costes.
2. Aprobado el plan, realizamos la migración en un máximo de 7 días hábiles: sitio web, base de datos, correos electrónicos y DNS, con staging, cambio fuera del horario comercial y entorno antiguo preservado durante 30 días.
3. El contrato es mensual, sin permanencia, con 30 días de preaviso para cancelar. La infraestructura está documentada y puedes llevarte todo cuando quieras.

Para instituciones educativas con EVA, existe una línea específica: el hosting Moodle, ajustado para cron, caché y picos de exámenes.

Conclusión: la señal más clara es el coste de quedarse

Ninguna de las cinco señales por sí sola obliga a migrar. Juntas, muestran que abandonar el hosting compartido dejó de ser un lujo y cuentan la misma historia: el sitio web dejó de ser una tarjeta de visita y pasó a generar ingresos, alumnos o atención al cliente. El modelo compartido no fue diseñado para eso.

Haz la prueba práctica esta semana: verifica los 'faults' en el panel, mide el TTFB en tres horarios, mira la versión de PHP y pasa la IP por una lista negra. Si dos o más dan rojo, es hora de abandonar el hosting compartido con planificación, y no a toda prisa después de una caída.

Si quieres un diagnóstico sin compromiso, con números de tu entorno y no de una tabla genérica, conoce el hosting gestionado de Agathas Web y solicita una evaluación. Respondemos con el plan en un máximo de 3 días hábiles.