Por qué una checklist y no una guía técnica
La mayoría de los recursos sobre self-hosting responden a la pregunta de «cómo migrar» asumiendo que la decisión ya está tomada. Sin embargo, los equipos que empezaron por el «cómo» sin haber resuelto el «qué» y el «por qué» terminan a menudo con tres herramientas self-hosted que funcionan bien — y ningún ahorro real, porque no migraron las partidas de gasto más pesadas.
Una agencia raramente gestiona un solo SaaS. Gestiona una cartera: CRM, gestión de proyectos, mensajería, almacenamiento, contraseñas, analítica, formularios, facturación. La decisión de migrar una herramienta no se toma de forma aislada — depende de lo que la herramienta realmente cuesta (suscripción, integraciones, formación), de lo que haría falta para reemplazarla (competencias, tiempo, servidor), y del orden en que las migraciones tienen sentido.
Esta checklist es una guía meta: no documenta los pasos de despliegue de una herramienta específica, sino que te ayuda a construir tu propio plan de migración, herramienta por herramienta, con un método reproducible.
Paso 1 — Elaborar el inventario de SaaS con su coste total
Antes de cualquier decisión, mapea lo que tienes. El ejercicio lleva menos de una hora y a menudo revela sorpresas: suscripciones activas que nadie sabe quién usa, herramientas que facturan por asiento mientras la mitad de las cuentas están inactivas, duplicados funcionales.
El coste a medir no es solo el coste directo (la línea en la tarjeta de crédito). Es el coste total: suscripción mensual o anual × número de asientos × 12, al que se suma el coste de integración (conectores, APIs de terceros de pago, módulos complementarios) y el coste de dependencia (cuántas otras herramientas dejan de funcionar si esta herramienta desaparece).
Este último criterio — la dependencia — es el más importante para decidir el orden de las migraciones. Una herramienta central, conectada a otras diez, suele costar menos conservarla que migrarla.
Qué debe contener tu inventario
- Nombre y categoría — mensajería, CRM, almacenamiento, gestión de proyectos, seguridad, analítica, facturación
- Coste anual real — suscripción × asientos × 12, más módulos y conectores de pago
- Número de usuarios activos — no el número de licencias compradas
- Integraciones activas — cuántas otras herramientas dependen de esta vía API o webhook
- Datos críticos almacenados — volumen, formato de exportación disponible, frecuencia de acceso
- Propietario interno — quién sabe cómo funciona la herramienta y quién sería responsable de la migración
Cuadrícula de decisión: criterios de migración SaaS
Desplace la tabla
| Criterio | Migración recomendada | Precaución necesaria |
|---|---|---|
| Coste anual | Superior a 299 DH/mes × 12 por herramienta | Inferior al coste de un VPS dedicado |
| Dependencias externas | Herramienta autónoma, pocas integraciones | Conectada a 5 o más herramientas vía API |
| Datos a migrar | Formato abierto (CSV, JSON, SQL) | Formato propietario sin exportación estándar |
| Competencias requeridas | Despliegue Docker documentado | Stack específico sin comunidad activa |
| Carga de mantenimiento | Actualizaciones mensuales, herramienta estable | Parches de seguridad semanales |
| Frecuencia de uso | Uso diario por todo el equipo | Uso ocasional por una sola persona |
| Alternativa open source | Alternativa madura con +1000 estrellas en GitHub | Sin equivalente funcional establecido |
Paso 2 — Calcular el ROI de cada candidato a migración
Una vez elaborado el inventario, identifica los candidatos a migración: las herramientas cuyo coste anual supera significativamente lo que costaría un VPS para ejecutarlas. No es una regla absoluta — una herramienta crítica de bajo coste puede quedarse como SaaS sin que nadie cuestione la decisión.
Para cada candidato, el cálculo del ROI real tiene cuatro líneas. Primera: el coste SaaS anual actual. Segunda: el coste de infraestructura (VPS o una porción de uno existente, según los requisitos de RAM y CPU). Tercera: el coste de migración inicial (tiempo de despliegue, migración de datos, formación del equipo, estimado honestamente en horas × coste por hora). Cuarta: el coste de mantenimiento recurrente anual (actualizaciones, copias de seguridad, supervisión).
El punto de equilibrio se calcula: coste migración inicial ÷ (coste SaaS anual − coste infraestructura anual − coste mantenimiento anual). Si este punto supera los 24 meses, la migración solo es rentable en un horizonte largo plazo.
Cuidado con subestimar el mantenimiento. Una herramienta self-hosted que recibe parches de seguridad frecuentes consume tiempo real, aunque sea poco por incidente.
La checklist de 5 pasos antes de cada migración
Verificar la existencia de una alternativa open source madura
Antes de continuar, confirma que existe una alternativa real. «Madura» significa: una comunidad activa, versiones recientes (en los últimos 6 meses), documentación de instalación actualizada, y experiencias publicadas por equipos de tamaño comparable al tuyo. Un proyecto abandonado o demasiado joven conlleva el riesgo de una migración sin vuelta atrás.
Estimar el coste de migración honestamente
Estima el tiempo necesario integrando todas las fases: despliegue inicial, migración de los datos existentes, período de doble funcionamiento (SaaS y self-hosted en paralelo para validar), formación del equipo, y puesta en marcha de la supervisión y copias de seguridad. Para una herramienta como Vaultwarden, calcula de dos a cuatro horas para un despliegue cuidadoso. Para una suite ofimática completa, varios días.
Prepara la salida antes de entrar
Antes de importar nada en tu nuevo entorno self-hosted, exporta todos los datos del SaaS actual en un formato abierto y verifica que la exportación es completa. Una exportación parcial descubierta tras cerrar la cuenta SaaS puede causar una pérdida de datos irreparable. Prueba también que puedes reimportar la exportación en la alternativa open source antes de cancelar nada.
Prueba en un VPS de cualificación antes de cambiar
Despliega la herramienta en un VPS de prueba, migra un subconjunto de datos reales (no datos de demostración), y haz que al menos dos miembros del equipo usen la herramienta durante una semana completa antes de decidir el cambio. Esta prueba revela problemas de ergonomía, integraciones faltantes y limitaciones que la documentación no menciona.
Planifica el mantenimiento en el calendario operativo
Una herramienta self-hosted sin mantenimiento planificado acaba acumulando deuda de seguridad. Antes de aprobar la migración, designa un responsable técnico, inscribe las verificaciones de actualizaciones en el calendario (semanal o mensual según la herramienta), y configura una supervisión de disponibilidad y copias de seguridad automáticas. Sin estos tres elementos, la migración transforma una suscripción SaaS en deuda técnica silenciosa.
Paso 3 — Establecer el orden de migración
El orden en que migras tus herramientas es tan importante como elegir qué herramientas migrar. Un error habitual es empezar por la herramienta que ahorra menos (porque es técnicamente más sencilla) o por la más compleja (por ambición).
El orden racional sigue dos reglas. Primero, empieza por las herramientas con ROI rápido y bajas dependencias: aquellas cuya migración lleva menos de un día, que no están conectadas a otras herramientas críticas, y cuyo ahorro es inmediato. Estas primeras migraciones permiten al equipo ganar competencia en las operaciones cotidianas (despliegue, copias de seguridad, actualizaciones) en herramientas de bajo riesgo. Luego, aborda las herramientas de alto valor económico solo cuando los procesos operativos estén asentados.
La regla de secuenciación más sencilla: empieza por las herramientas donde la migración es reversible (vuelta al SaaS posible si falla la migración), antes de las herramientas donde el retroceso es costoso o imposible.
Herramientas típicamente en cabeza de lista (bajo riesgo, ROI rápido)
- Gestor de contraseñas — migración Vaultwarden en dos a cuatro horas, formato compatible con Bitwarden, vuelta atrás posible en cualquier momento
- Analítica — Umami, Matomo o Plausible reemplazan la analítica SaaS sin necesidad de migrar datos históricos
- Formularios y encuestas — herramientas autónomas, sin integraciones críticas, datos fácilmente exportables
- Acortador de enlaces / redirecciones — herramienta periférica, migración no crítica
- Monitorización de disponibilidad — Uptime Kuma se instala en minutos y no requiere migración de datos
Herramientas a abordar en segunda fase (mayor complejidad y dependencias)
- Almacenamiento y suite ofimática — Nextcloud centraliza archivos, calendario y contactos; la migración implica sincronizar los clientes en todos los puestos
- CRM — Twenty CRM u otras alternativas requieren exportar y limpiar los datos existentes, y reconfigurar las automatizaciones
- Mensajería de equipo — Mattermost o Rocket.Chat implican migrar el historial y reconfigurar las integraciones (webhooks, bots)
- Gestión de proyectos — Plane, Vikunja o Gitea Issues: la migración de tickets y archivos adjuntos puede ser parcial según la herramienta origen
- Facturación y contabilidad — migra al final, con un período largo de doble funcionamiento; estos datos son críticos y las obligaciones legales van asociadas a ellos
Paso 4 — Preparar la infraestructura antes de las migraciones
Una migración exitosa no empieza por desplegar la herramienta, sino por preparar la infraestructura que la va a alojar. Migrar cada herramienta a un VPS dedicado no siempre es la solución más económica: un VPS correctamente dimensionado puede alojar varias herramientas a la vez, siempre que sus necesidades de RAM y CPU sean compatibles.
La preparación de la infraestructura cubre cuatro áreas. Primero, el dimensionamiento del servidor: cada herramienta publica sus requisitos de RAM y CPU — súmalos y añade un margen del 30% para los picos. Luego, el endurecimiento básico: cortafuegos, actualizaciones de seguridad automáticas, acceso SSH solo por clave. Después, la estrategia de copias de seguridad: copias automáticas diarias en una ubicación separada del servidor de producción. Por último, la supervisión: una alerta en caso de indisponibilidad y verificaciones periódicas de actualizaciones de seguridad.
Estas cuatro áreas son requisitos previos, no opciones. Una herramienta self-hosted sin copias de seguridad probadas no es una alternativa a un SaaS — es un SaaS sin garantía de servicio.
Empieza con un solo VPS para tus primeras migraciones, usando Docker Compose para aislar las herramientas entre sí. Este enfoque permite comenzar rápidamente sin sobredimensionar la infraestructura. Consulta nuestra guía de hardening Linux para asegurar el servidor antes del primer despliegue.
Paso 5 — Validar y documentar antes de cancelar
La migración solo está terminada cuando se cumplen tres condiciones: el equipo lleva al menos una semana usando la herramienta self-hosted a diario sin ningún problema bloqueante, las copias de seguridad se han probado con una restauración real (no solo verificadas en los registros), y la documentación de mantenimiento está redactada y la conoce el responsable técnico.
Solo entonces, cancela la suscripción SaaS. No antes. Esta regla es la protección contra las migraciones precipitadas que terminan en un regreso de urgencia al SaaS, a veces con datos perdidos en el proceso.
Documenta también las decisiones tomadas para cada herramienta: por qué migraste, cuál era el coste antes, y cuáles son los procedimientos de mantenimiento. Esta documentación es útil si un nuevo miembro del equipo necesita hacerse cargo de la gestión de la infraestructura, y permite medir el ROI real tras seis meses de operación.
Lo que esta checklist no reemplaza
Esta checklist cubre la toma de decisiones y la secuenciación. No reemplaza las guías de migración específicas de cada herramienta, que documentan los pasos técnicos de despliegue, la migración de datos y los errores habituales. Para cada herramienta elegida en tu plan de migración, existe una guía dedicada: migración a Vaultwarden, migración a Twenty CRM, migración a Nextcloud, y otras más.
La checklist es también una ayuda a la decisión, no una garantía. Algunas herramientas parecen candidatas a la migración según todos los criterios y luego resultan difíciles de mantener en tu contexto específico. Otras parecen complejas y se despliegan en pocas horas. Las estimaciones dadas aquí son órdenes de magnitud, no promesas.
Por último, esta checklist no aborda la gestión multicliente: si eres una agencia que aloja la infraestructura de tus clientes en lugar de la tuya, las restricciones son diferentes — aislamiento entre clientes, gestión de accesos, facturación del servicio, responsabilidad contractual. Estos aspectos pertenecen a una arquitectura multitenant, más allá del alcance de esta guía.
Por dónde empezar de forma concreta
Si estás leyendo este artículo con una hoja de cálculo de SaaS abierta en otra pestaña, aquí tienes los primeros pasos concretos: elabora el inventario de coste total en una hora, identifica uno o dos candidatos con ROI rápido y bajas dependencias, y prepara un VPS de cualificación antes de desplegar nada en producción.
Para las agencias que gestionan la infraestructura de varios clientes, centralizar la gestión de dominios, alojamientos y VPS en una sola plataforma antes de iniciar las migraciones simplifica considerablemente las operaciones: sabes qué corre dónde, y puedes asignar recursos por cliente sin hacer malabarismos entre paneles de administración dispares.
El self-hosting es una inversión, no un ahorro inmediato. La checklist sirve precisamente para distinguir las migraciones que se amortizan rápidamente de las que requieren un horizonte más largo — para que cada decisión sea una decisión, y no una reacción a una factura.
