Al elegir un proveedor de creación de sitios web SaaS, es necesario verificar si los datos pueden migrarse fuera de la plataforma

Si antes de firmar el contrato no es posible migrar íntegramente y de forma utilizable los datos del sitio web y de marketing, la comodidad que aporta la creación de sitios SaaS se convertirá en una limitación al renovar, cambiar de proveedor, integrar tras una adquisición o crear un sistema propio. Al evaluar un proveedor de creación de sitios SaaS, no basta con confirmar que «admite exportación»; también es necesario confirmar los objetos exportados, la estructura de los datos, las relaciones entre ellos y el grado de recuperación posible tras la migración. Una función de exportación que solo permite descargar capturas de pantalla de páginas, hojas de cálculo o archivos comprimidos normalmente no es suficiente para respaldar una migración real.

En primer lugar, deben definirse claramente los límites de la propiedad de los datos. El titular del registro del dominio, el control de DNS, los archivos fuente del sitio web, el contenido de las páginas, los archivos originales de imágenes y vídeos, la información de productos, las consultas de clientes, los pedidos, los registros de formularios, los eventos de seguimiento, la configuración de las páginas de destino publicitarias, los metadatos SEO y los informes analíticos pueden estar alojados en diferentes cuentas y sistemas. El contrato debe estipular que la empresa posee los derechos de uso, copia de seguridad y migración de sus propios datos comerciales y activos de contenido, en lugar de conservar únicamente derechos de acceso al panel de administración. Si el dominio está registrado a nombre del proveedor de servicios o si la cuenta de resolución DNS no puede transferirse, incluso cuando el contenido se pueda descargar, pueden producirse interrupciones de acceso y riesgos en la resolución del correo electrónico durante la migración del sitio.

Distinguir primero entre «archivo exportado» y «datos migrables»

Que los datos sean migrables no significa simplemente exportar la base de datos a CSV. Para los sitios web orientados a contenidos, los artículos, productos, materiales descargables y páginas multilingües deben conservar, como mínimo, el título, el cuerpo del texto, el resumen, las categorías, las etiquetas, el autor, la fecha de publicación, la URL, el título SEO, la descripción, la configuración Canonical, los datos estructurados y las relaciones de referencia de los medios. Si solo se exporta el texto del cuerpo, tras importarlo al nuevo sistema todavía será necesario volver a añadir imágenes, modificar enlaces y completar metadatos, y las páginas existentes de búsqueda orgánica podrían sufrir falta de contenido o cambios de dirección.

En el caso de las tiendas transfronterizas, también debe confirmarse si se pueden exportar por separado los SKU de productos, los atributos de variantes, el inventario, las reglas de precios, las cuentas de clientes, las direcciones de entrega, los estados de los pedidos, los registros de reembolsos, la configuración fiscal, los números de seguimiento logístico y los identificadores de transacciones de pago. La información de tarjetas de pago suele estar sujeta a restricciones normativas y de seguridad, por lo que no necesariamente puede migrarse directamente; sin embargo, los números de pedido, importes, divisas, detalles de productos y estados de pago deben conservarse de una forma verificable. Es necesario distinguir entre credenciales sensibles que no pueden migrarse y registros comerciales que deberían conservarse pero se han omitido.

Los datos de consultas y marketing suelen pasarse por alto con mayor facilidad. Las definiciones de campos de formularios, las fuentes de prospectos, los parámetros UTM, las versiones de páginas de destino, los archivos adjuntos, los estados de seguimiento, los registros de consentimiento para suscripciones por correo electrónico, las horas de activación de eventos y la configuración de devolución de conversiones publicitarias determinan si posteriormente se podrá seguir atribuyendo y realizando seguimiento. Si el proveedor solo proporciona el nombre, correo electrónico y teléfono del contacto, se interrumpirán las fuentes originales de captación y las rutas de conversión, y los datos históricos difícilmente podrán utilizarse para remarketing o revisiones de canales.

El formato de exportación debe resistir una importación real

Durante la evaluación, debe solicitarse la revisión de archivos de muestra, en lugar de limitarse a consultar la descripción de las funciones. Los datos comerciales estructurados deberían proporcionarse en CSV, XLSX, JSON o ser accesibles mediante API; los archivos multimedia, como imágenes y documentos, deben conservar los archivos originales, y el inventario debe indicar el nombre del archivo, la ruta, el tipo y el objeto asociado. Si el contenido de la página se guarda en plantillas propietarias o formatos binarios y no puede editarse fuera del sistema original, es necesario confirmar si puede exportarse en HTML, Markdown, JSON u otros formatos abiertos y analizables.

También deben verificarse la codificación, la zona horaria, el idioma y los identificadores únicos. Los caracteres en chino, árabe, ruso y otros idiomas no deben mostrarse de forma incorrecta tras la exportación; las páginas multilingües deben conservar los códigos de idioma y las relaciones de traducción; las fechas deben indicar la zona horaria utilizada; y los registros de productos, pedidos, contenido y clientes deben contar con ID estables para evitar creaciones duplicadas o pérdidas de asociaciones durante la importación. En el caso de las URL de imágenes, también debe confirmarse si seguirán siendo accesibles después de la descarga o si dependen de direcciones con firma temporal del sitio original.

La existencia de una API no significa que la migración sea viable. Es necesario verificar si la interfaz cubre todos los objetos y si admite paginación, lectura incremental, filtrado de registros históricos y descargas por lotes; las reglas de limitación de solicitudes, los costes de llamadas, el alcance de permisos y el período de disponibilidad de la interfaz tras la finalización del contrato también afectan a la ventana de migración. Tener solo una interfaz de lectura sin descarga de medios, diccionario de campos o explicaciones de relaciones seguirá incrementando el coste de depuración de datos.

Riesgos de publicación del sitio web durante la migración

La migración de contenido suele implicar varios pasos: exportación del sitio antiguo, mapeo hacia el nuevo sitio, validación previa a la publicación, cambio de DNS y conservación del sitio antiguo. Si cambian las URL de las páginas originales, debe poder generarse un mapeo completo entre las direcciones antiguas y nuevas, y configurarse redirecciones 301 en el nuevo sitio. No deben migrarse únicamente las páginas con mejor posicionamiento: las páginas de productos de larga duración, las páginas regionales, las direcciones de descarga de PDF y las páginas de destino exclusivas para publicidad también pueden recibir enlaces externos o tráfico de campañas.

Los formularios, los códigos analíticos, los píxeles publicitarios, los mecanismos de consentimiento de Cookie, las notificaciones por correo electrónico y los Webhook de CRM deben probarse uno por uno antes del cambio. El entorno de prueba no debe enviar notificaciones reales directamente a clientes o sistemas de ventas; pueden utilizarse correos electrónicos de prueba, prospectos de prueba y direcciones de devolución aisladas. Tras el cambio, deben comprobarse los códigos de estado de las páginas clave, los títulos de página, la configuración de robots, el mapa del sitio, las etiquetas Canonical y los resultados de envío de formularios, para evitar fluctuaciones de indexación causadas por una configuración incorrecta de noindex o redirecciones erróneas.

Los sitios web con actualizaciones frecuentes no son adecuados para «congelar y trasladar» todo de una sola vez. Primero puede completarse la exportación total y el mapeo de campos, y después exportar el contenido incremental, los pedidos más recientes o las nuevas consultas antes de la puesta en línea. El alcance incremental debe confirmarse tanto por fecha de creación como por fecha de actualización, para evitar omisiones al editar contenido antiguo. El tiempo de conservación del sitio antiguo, si seguirá generando costes y cuándo expirarán los recursos multimedia también deben definirse claramente en el plan de migración.

Convertir la capacidad de migración en cláusulas contractuales verificables

Durante la fase de adquisición, los requisitos de migración deben transformarse en condiciones de entrega ejecutables, en lugar de quedarse en formulaciones como «admite copias de seguridad de datos». Puede acordarse el canal para solicitar la exportación, el plazo de procesamiento, el medio de entrega, el formato de archivo, la descripción de campos y el alcance de la asistencia cuando se finalice el servicio, se desactive la cuenta o surja una disputa. Si la migración requiere un coste adicional, el criterio de facturación debe definirse de antemano para evitar perder capacidad de negociación durante un cambio urgente del negocio.

• Exigir una exportación de pequeño alcance durante la fase de prueba o aceptación: seleccionar páginas que incluyan imágenes, contenido multilingüe, archivos adjuntos de formularios y campos SEO, y verificar si los archivos pueden abrirse e importarse de forma independiente.
• Conservar el diccionario de campos, la documentación de API, las instrucciones de configuración de plantillas y las reglas de redirección. Sin estas indicaciones, los datos exportados a menudo solo podrán reorganizarse manualmente.
• Definir claramente el período de conservación de datos tras la finalización del servicio, el mecanismo de eliminación y la capacidad de restauración de copias de seguridad, especialmente el alcance de conservación de consultas, pedidos y registros de acceso.
• Para los datos alojados en herramientas de terceros, como registros de correo electrónico, pagos, publicidad y atención al cliente, confirmar por separado la titularidad de las cuentas y las rutas de exportación; no debe asumirse que el proveedor de creación de sitios puede realizar una entrega unificada.

La evaluación final debe basarse en un simulacro de migración reproducible: si los datos obtenidos del panel de administración pueden leerse, validarse e importarse sin depender del entorno operativo propietario del proveedor original, y si pueden restaurarse las páginas clave, los registros comerciales y las cadenas de marketing. Solo al completar este paso la migración de datos dejará de ser un eslogan y se convertirá en una capacidad del sistema verificable.