Lista de verificación para migrar al autoalojamiento

Una lista de una página para pasar a un equipo de una herramienta de pago a una autoalojada. Cubre los pasos que deciden si la migración será aburrida o un desastre: la exportación de datos, el dimensionamiento, las copias de seguridad y el plan de vuelta atrás que casi todo el mundo olvida.

1. Antes de instalar nada

• Exporta hoy mismo una copia real de tus datos. No una cuenta de prueba: tu espacio de trabajo real. Algunas exportaciones son parciales, están limitadas o solo existen en planes superiores. Mejor descubrirlo ahora que el día en que vence el contrato.
• Abre la exportación y comprueba qué falta. Adjuntos, comentarios, historial, menciones y permisos son las bajas habituales.
• Confirma que la herramienta nueva puede importar ese formato. Si no puede, reserva tiempo para convertirlo. Ese coste no aparece en ninguna cifra de este sitio.
• Enumera las integraciones de las que dependes. SSO, notificaciones de chat, webhooks, sincronización de calendario. Comprueba que cada una existe en la herramienta autoalojada.
• Revisa la licencia. Varias herramientas populares son de código disponible y no de código abierto, con límites al uso comercial. Cada página de herramienta de este sitio lo indica.
• Nombra a un responsable. Un software autoalojado sin nadie encargado de las actualizaciones es la forma más habitual en que fracasan estos proyectos.

2. Dimensionamiento e instalación

• Dimensiona el servidor con la página de coste de la herramienta para tu tamaño de equipo y conserva el 25 % de margen de memoria. Un servidor ajustado al milímetro suele caerse en su primera actualización.
• Usa el archivo Docker Compose del propio proyecto en lugar de uno de terceros, y fija la versión de la imagen en vez de usar latest.
• Ponlo detrás de HTTPS y en su propio subdominio desde el primer día. Cambiar la dirección más tarde rompe enlaces, redirecciones de OAuth y aplicaciones móviles.
• Configura el correo saliente con un servicio de envío transaccional. Sin él, los restablecimientos de contraseña y las notificaciones fallan en silencio, y la mayoría de las herramientas no avisan.
• Cierra todos los puertos excepto el 80 y el 443, y nunca expongas la base de datos directamente.
• Activa el SSO, o al menos la autenticación en dos pasos obligatoria, antes de invitar a nadie.

3. Copias de seguridad probadas

• Respalda tanto la base de datos como los archivos subidos. Un volcado de la base de datos sin la carpeta de archivos restaura una herramienta llena de adjuntos rotos.
• Guarda al menos una copia fuera del servidor, con otro proveedor o en otra región distinta a la del propio servidor.
• Automatízalo y recibe una alerta si falla. Una tarea de copia que dejó de funcionar hace tres semanas es la forma habitual de descubrir que no había copia.
• Restáurala en un servidor nuevo antes de la puesta en producción. Mide cuánto tarda. Esa cifra es tu tiempo real de recuperación, y hasta que no la tengas no tienes copias de seguridad, solo archivos.

4. El cambio

• Elige un día tranquilo y anuncia una congelación de contenidos en la herramienta antigua durante la migración.
• Haz una última exportación tras la congelación, impórtala y revisa una muestra de registros, adjuntos y permisos frente a la herramienta antigua.
• Pasa primero a un grupo pequeño durante una semana de trabajo real antes de mover a todo el mundo.
• Redirige o actualiza los marcadores allí donde estuviera enlazada la dirección antigua: documentación, chat, navegadores y aplicaciones móviles.

5. El plan de vuelta atrás que casi todo el mundo olvida

• Escribe antes del cambio qué te haría volver atrás. Pérdida de datos, una función imprescindible que falta o caídas repetidas. Fija el umbral mientras estás tranquilo.
• Mantén la suscripción antigua un ciclo de facturación más tras la puesta en producción, aunque parezca un derroche. Es el seguro más barato que vas a comprar.
• Averigua cómo exportar desde la herramienta nueva a un formato que la antigua pueda leer.
• Cancela la suscripción antigua solo cuando haya pasado una prueba de restauración, todo el equipo haya usado la nueva herramienta para trabajo real y nadie haya pedido volver a la antigua.

6. Después de la puesta en producción

• Pon las actualizaciones en el calendario. Este sitio calcula entre 0,5 y 3 horas al mes según la herramienta. Lo que no se planifica no se hace.
• Lee las notas de la versión antes de actualizar, sobre todo en versiones mayores con migraciones de base de datos.
• Añade monitorización de disponibilidad para enterarte de una caída antes que tu equipo.
• Repite la prueba de restauración cada pocos meses.

Antes de empezar

Si todavía no has calculado el coste de la migración, comprueba si autoalojar ahorra dinero de verdad con tu tamaño de equipo. Con algunas herramientas no es así una vez contadas las horas anteriores. Ver todas las comparativas o leer cómo se calculan los costes.