Salir de un SaaS empresarial: cómo recuperar datos y cambiar de proveedor
Por Carlos Isidoro De Ayala Diaz ·
Salir de un SaaS empresarial: qué datos, formatos, plazos, pruebas y controles acordar para migrar a otro proveedor sin perder trazabilidad ni continuidad.
Define la salida antes de depender del servicio
Contratar un SaaS resuelve una función sin desplegar toda la plataforma en la empresa, pero también concentra datos, configuraciones y procesos en un proveedor. La salida no empieza cuando llega la baja. Debe definirse antes de contratar o durante una revisión del servicio: qué necesita recuperar la empresa, qué debe seguir funcionando, quién participará y cómo se comprobará que el cambio terminó bien. Un botón de exportar contactos no equivale a poder trasladar el proceso completo.
El inventario distingue datos introducidos por usuarios, resultados generados por el sistema, archivos, metadatos, historiales y activos digitales. En un CRM incluye empresas, contactos, oportunidades, actividades, documentos, campos personalizados, etiquetas, relaciones, usuarios, roles y registros de auditoría. En una plataforma de pedidos añade productos, tarifas, estados, impuestos, adjuntos e identificadores externos. También se documentan paneles, reglas, automatizaciones, plantillas e integraciones, aunque no todos esos elementos puedan trasladarse de forma directa.
Cada categoría necesita propietario, formato de salida, volumen aproximado, frecuencia de cambio y destino previsto. Los identificadores son especialmente importantes: si el contacto, la empresa y el pedido se exportan en ficheros separados, debe existir una clave estable que permita reconstruir sus relaciones. Las fechas conservan zona horaria y significado; los importes necesitan moneda e impuestos; los estados y listas cerradas requieren un diccionario. Sin esa semántica, un CSV puede abrirse y seguir siendo insuficiente para migrar.
El Reglamento de Datos de la Unión Europea se aplica desde el 12 de septiembre de 2025 y su capítulo sobre cambio entre servicios de tratamiento de datos establece requisitos para facilitar el cambio y la portabilidad. La Comisión Europea explica que los proveedores de software como servicio deben ofrecer interfaces abiertas y, como mínimo, exportar los datos pertinentes en formatos habituales y legibles por máquina. La aplicación concreta depende del servicio y del contrato; el plan técnico debe apoyarse en sus condiciones reales y en la revisión jurídica que corresponda.
Prueba la exportación mientras el SaaS sigue operativo
La primera exportación debe ejecutarse antes de necesitarla. Se utiliza una cuenta autorizada, se registra la fecha, el alcance solicitado y el tiempo de generación y se guarda el resultado en una ubicación controlada. Después se compara el número de registros con informes del propio sistema y se revisan muestras de cada tipo. Que el archivo se descargue sin error no demuestra que contenga todos los campos, relaciones, adjuntos o elementos archivados.
La validación comprueba codificación, separadores, zonas horarias, decimales, valores nulos, duplicados y caracteres especiales. También confirma que los identificadores sean persistentes y que las relaciones puedan reconstruirse sin depender de una URL interna. Los documentos necesitan nombre, tipo, propietario y vínculo con su registro. Si el proveedor entrega una API, se documentan paginación, límites, filtros, versión y comportamiento ante reintentos. Una API disponible comercialmente puede omitir datos que sí aparecen en la interfaz.
El ensayo debe medir volumen y ventana. Una descarga manual que funciona con cien registros puede no terminar con varios años de actividad. Se estima ancho de banda, almacenamiento temporal, tiempo de extracción y capacidad de importación del destino. Cuando la empresa no puede detener el servicio, se prepara una exportación inicial y otra incremental con los cambios posteriores. El criterio para identificar altas, modificaciones y eliminaciones debe ser verificable; confiar solo en una fecha actualizada puede perder cambios si el origen no la mantiene de forma consistente.
Los ficheros de salida se protegen como los datos de producción. Se cifran en tránsito y en reposo cuando corresponda, se limita su acceso y se define su eliminación. Se calculan huellas o controles equivalentes para detectar modificaciones durante la transferencia y se conserva un manifiesto con los archivos esperados. La prueba más útil es importar una muestra en un entorno separado y reconstruir recorridos: localizar un cliente, abrir sus documentos, relacionar sus pedidos y explicar de dónde procede cada cifra.
Planifica el cambio, la continuidad y la reversión
El sistema de destino rara vez utiliza exactamente el mismo modelo. Antes de migrar se crea una tabla de correspondencias entre entidades, campos, estados, usuarios y permisos. Cada transformación indica regla, responsable y tratamiento de excepciones. Los datos que no se trasladan se enumeran con su motivo y forma de consulta posterior. Aprovechar la migración para limpiar duplicados puede ser útil, pero limpieza y portabilidad se validan por separado para no confundir una decisión de negocio con una pérdida accidental.
La secuencia de cambio define exportación base, pruebas, formación, congelación o periodo de convivencia, carga final, validación y apertura. Si ambos sistemas trabajan en paralelo, se decide cuál es la fuente de verdad para cada operación y cómo se evitan registros duplicados. Si existe una parada, se comunica qué funciones no estarán disponibles y cómo se atenderán urgencias. La aceptación combina recuentos, totales conciliados y recorridos reales de usuarios; una importación sin errores técnicos no demuestra que facturación o seguimiento comercial funcionen.
Las integraciones suelen marcar el camino crítico. Se inventarían SSO, API, webhooks, correo, almacenamiento, pagos, ERP, copias y herramientas de análisis. Para cada una se prepara nueva credencial, endpoint, permiso, prueba y momento de activación. Los dominios, enlaces públicos y aplicaciones móviles pueden conservar referencias al proveedor anterior. La observabilidad del día de cambio debe mostrar errores, colas, latencia y operaciones de negocio para detectar una migración aparentemente correcta que deja de entregar pedidos o notificaciones.
La reversión se acuerda antes de la carga final. Indica hasta qué momento puede recuperarse el SaaS anterior, qué cambios realizados en el destino habría que retirar y cómo se tratarían las operaciones creadas durante el intento. Una copia de los datos no restaura automáticamente automatizaciones, permisos o integraciones. El proveedor de origen confirma continuidad durante la transición y el equipo conserva accesos de administración hasta que los criterios de aceptación estén cumplidos, sin prolongar cuentas y credenciales más de lo necesario.
Cierra accesos y conserva evidencia de la entrega
El cierre no se limita a cancelar la suscripción. Se obtiene la exportación final, se confirma el periodo disponible para recuperar datos y se identifica qué copias, registros o archivos conservará el proveedor y durante cuánto tiempo. El contrato debe explicar asistencia, plazos, categorías exportables, exclusiones y eliminación. El Reglamento de Datos exige que las condiciones de cambio figuren por escrito para los servicios cubiertos, pero la empresa sigue necesitando comprobar técnicamente qué recibe y si puede utilizarlo.
Después del cambio se revocan usuarios, tokens, claves API, aplicaciones OAuth, certificados y cuentas técnicas del proveedor anterior. Se actualizan gestores de contraseñas, inventarios, documentación, contactos de soporte y listas de terceros. También se revisan reenvíos, webhooks y tareas programadas que podrían seguir enviando información. Si el servicio gestionaba un dominio, número, certificado o cuenta de tienda, la titularidad y el control se transfieren antes de que la baja elimine el acceso.
La evidencia final incluye manifiesto de exportación, recuentos, conciliaciones, incidencias, decisiones, aceptación y confirmaciones de cierre. No hace falta conservar indefinidamente copias intermedias con datos personales; se define qué documento demuestra la operación sin multiplicar el riesgo. Las obligaciones fiscales, laborales, contractuales o de protección de datos pueden exigir conservaciones distintas, por lo que negocio, tecnología y asesoría responsable acuerdan el calendario antes de borrar.
Élite Solutions Tech puede ayudar desde Murcia a empresas regionales y nacionales a inventariar un SaaS, probar sus exportaciones y preparar la migración con criterios de aceptación y reversión. La propuesta concreta sistemas, datos, integraciones, responsabilidades y entregables; no presupone acceso al código ni cooperación ilimitada del proveedor de origen. Para una primera valoración puedes indicar en el formulario de contacto el servicio utilizado, usuarios, volumen aproximado e integraciones, sin adjuntar exportaciones, credenciales ni datos confidenciales.