Qué cambia cuando una web debe ponerse en producción en un hosting externo

Una web puede estar completamente terminada, probada y funcionando correctamente en el entorno donde se ha desarrollado.

Pero eso no significa que ponerla en producción en cualquier servidor sea simplemente copiar unos archivos y una base de datos.

Cuando la web debe publicarse en un hosting gestionado por un tercero, aparecen variables que hasta ese momento estaban bajo control y que pasan a depender de una infraestructura ajena.

No tiene por qué ser un problema.

Pero sí cambia la forma de plantear la puesta en producción.

La web es la misma, el entorno no

Dos servidores pueden alojar exactamente la misma instalación de WordPress y comportarse de forma diferente.

Puede cambiar:

• la versión de PHP;
• la memoria disponible;
• el tiempo máximo de ejecución;
• las extensiones instaladas;
• la configuración de la base de datos;
• el sistema de caché;
• las reglas de seguridad;
• los permisos de archivos;
• el servidor web;
• o la forma en la que se gestionan las tareas programadas.

Por eso una web que funciona perfectamente en un entorno de desarrollo no debería darse por validada automáticamente en producción.

El despliegue también necesita comprobaciones.

Lo primero es conocer el servidor

Antes de mover la web conviene conocer qué tenemos al otro lado.

No siempre disponemos del mismo nivel de acceso.

En algunos proyectos tendremos acceso completo al servidor o a un panel como Plesk o cPanel.

En otros, únicamente tendremos FTP y una base de datos.

Y en determinados casos habrá que solicitar cada cambio al proveedor que administra la infraestructura.

Esto condiciona bastante el trabajo.

Cuanto menor sea el control sobre el servidor, mayor importancia tiene conocer previamente sus limitaciones.

PHP puede marcar la diferencia

Uno de los primeros puntos que revisamos es la versión de PHP.

Una instalación puede haberse desarrollado y probado con una versión concreta y encontrarse en producción con otra más antigua o más reciente.

Eso puede afectar a WordPress, al theme, a los plugins o al código personalizado.

Además de la versión, existen otros parámetros importantes:

• memoria disponible;
• tamaño máximo de subida;
• tiempo máximo de ejecución;
• número de variables permitidas;
• y extensiones de PHP instaladas.

Algunas diferencias pasan desapercibidas hasta que intentamos importar contenido, procesar imágenes grandes o ejecutar una tarea especialmente pesada.

La memoria disponible importa más de lo que parece

Es bastante habitual encontrarse con instalaciones donde WordPress tiene configurado un límite de memoria que parece suficiente, pero el servidor establece otro límite inferior.

También puede ocurrir lo contrario.

En una web sencilla probablemente nunca lo notemos.

Pero una instalación con plugins complejos, múltiples idiomas, comercio electrónico o procesos de importación puede necesitar bastante más memoria durante determinadas operaciones.

Una puesta en producción debería comprobar este tipo de límites antes de que se conviertan en errores visibles.

No todos los servidores aplican las mismas reglas de seguridad

Los sistemas de protección del servidor también pueden afectar al funcionamiento de una web.

Un firewall de aplicaciones, reglas de ModSecurity u otros mecanismos de filtrado pueden bloquear determinadas peticiones perfectamente legítimas.

Esto suele aparecer en operaciones relativamente complejas:

guardado de formularios grandes, llamadas AJAX, importaciones, APIs o determinadas acciones dentro del administrador.

En estos casos la aplicación puede estar funcionando correctamente y ser el propio servidor quien esté rechazando la petición.

Por eso resulta importante poder consultar logs o, al menos, contar con un proveedor que pueda revisarlos.

DNS y SSL también forman parte de la puesta en producción

Mover una web no termina cuando los archivos están en el servidor.

Hay que comprobar también el dominio.

El cambio puede implicar:

• modificaciones DNS;
• cambio de IP;
• configuración de certificados SSL;
• redirecciones;
• versiones con y sin www;
• subdominios;
• correo electrónico;
• o servicios externos asociados al dominio.

Este punto merece especial atención cuando el correo se mantiene con otro proveedor.

Cambiar incorrectamente determinados registros DNS puede provocar que la web funcione mientras el correo deja de hacerlo.

Por eso conviene saber exactamente qué registros deben modificarse y cuáles deben mantenerse.

El correo de WordPress también debe probarse

Una web puede estar publicada y aparentemente funcionar correctamente mientras sus correos no llegan.

Formularios de contacto, avisos administrativos, recuperación de contraseñas o notificaciones de pedidos dependen de que el sistema de envío esté bien configurado.

En un nuevo servidor pueden cambiar:

• las restricciones de envío;
• la configuración SMTP;
• las políticas antispam;
• la reputación de la IP;
• o el comportamiento de la función de correo de PHP.

Por eso siempre conviene realizar pruebas reales después del cambio.

No basta con comprobar que el formulario muestra el mensaje de “enviado”.

Caché y rendimiento no son iguales en todos los proveedores

Una configuración de caché que funciona bien en un servidor puede ser redundante o incluso problemática en otro.

Algunos proveedores incorporan su propia caché a nivel de servidor.

Otros dependen completamente de plugins.

También pueden existir CDN, proxies o servicios intermedios.

Antes de activar todas las capas posibles conviene entender qué está haciendo cada una.

Más caché no significa necesariamente más rendimiento.

En ocasiones significa simplemente más sitios donde buscar cuando algo no se actualiza como debería.

Las tareas programadas pueden comportarse de forma distinta

WordPress utiliza WP-Cron para ejecutar determinadas tareas.

Actualizaciones, sincronizaciones, correos, procesos de WooCommerce o plugins de terceros pueden depender de él.

En algunos servidores WP-Cron funciona de la forma estándar.

En otros puede estar desactivado y sustituido por un cron real del sistema.

Al migrar una web conviene comprobar cómo estaba configurado el entorno anterior y cómo funciona el nuevo.

Una tarea que deja de ejecutarse no siempre provoca un error visible inmediatamente.

Puede tardar días en detectarse.

También necesitamos saber cómo se hacen los backups

Cuando gestionamos nosotros la infraestructura sabemos dónde están las copias, con qué frecuencia se realizan y cómo recuperarlas.

En un hosting externo necesitamos comprobarlo.

No basta con asumir que “el proveedor hace backups”.

Conviene saber:

• con qué frecuencia;
• cuánto tiempo se conservan;
• qué incluyen;
• dónde se almacenan;
• y cómo se solicita o ejecuta una restauración.

Y antes de una puesta en producción importante, siempre es recomendable disponer de una copia propia.

Los accesos condicionan el soporte posterior

Hay otro aspecto que a veces se pasa por alto.

Una cosa es conseguir publicar la web y otra mantenerla posteriormente.

Si para cada incidencia necesitamos solicitar información o cambios a un tercero, los tiempos de diagnóstico pueden aumentar.

Por ejemplo, ante un error 500 podemos necesitar:

• logs del servidor;
• configuración PHP;
• reglas de seguridad;
• espacio disponible;
• o reiniciar algún servicio.

Si no tenemos acceso a esa información tendremos que coordinar la intervención con quien gestione el hosting.

Eso no hace inviable el mantenimiento.

Simplemente implica una dependencia adicional que conviene conocer desde el principio.

Publicar en un hosting externo puede hacerse perfectamente

Nada de esto significa que una web deba alojarse obligatoriamente con la empresa que la desarrolla.

Es perfectamente posible trabajar con infraestructura gestionada por otro proveedor.

De hecho, en muchas organizaciones es lo normal.

Lo importante es entender que cambia el alcance del trabajo.

Cuando conocemos y gestionamos la infraestructura tenemos control sobre toda la cadena.

Cuando trabajamos sobre un servidor externo tenemos que adaptarnos a sus características, sus accesos y sus procedimientos.

Una puesta en producción es una fase técnica del proyecto

A veces se percibe el despliegue como el último paso administrativo después de terminar una web.

Pero técnicamente es una fase más del proyecto.

Hay que migrar, adaptar, comprobar y validar.

Una puesta en producción correctamente realizada debería revisar como mínimo:

servidor, PHP, base de datos, SSL, DNS, correo, permisos, caché, tareas programadas, backups y funcionamiento general.

La web puede ser exactamente la misma.

El entorno donde funciona no lo es.

Y esa diferencia es precisamente la que hay que gestionar.