¿Cómo determinar si una plataforma de creación de sitios web para comercio internacional admite la migración de datos?

Para determinar si una plataforma de creación de sitios web para el comercio transfronterizo admite la migración de datos, no basta con comprobar si ofrece un botón de «exportar». Lo fundamental es verificar si los datos que la empresa necesita conservar pueden obtenerse en un formato procesable, si es posible reconstruir las relaciones entre ellos y si la nueva plataforma puede recibirlos y restablecer las funciones empresariales necesarias.

Poder exportar una hoja de cálculo de productos no significa que sea posible trasladar todo el sitio web. El diseño de las páginas, las versiones en distintos idiomas, las cuentas de clientes, el estado de los pedidos, los archivos de imágenes y las URL indexadas por los motores de búsqueda pueden almacenarse en ubicaciones diferentes o estar sujetos a las limitaciones de la arquitectura de la plataforma o de servicios de terceros. Al elegir una plataforma, hay que comprobar tanto la capacidad de exportar los datos como la de importarlos, en lugar de conformarse con una respuesta general como «admitimos la migración».

Primero, define qué significa exactamente «datos completos»

El alcance de la migración depende del modelo de negocio del sitio web. En un sitio B2B puede ser más importante migrar la información de los productos, las consultas y las páginas en varios idiomas; una tienda transfronteriza también debe gestionar las variantes de los productos, el inventario, las cuentas de clientes y el historial de pedidos. Durante la evaluación, elabora una lista de los distintos tipos de datos y confirma si cada uno se puede exportar y si, una vez exportado, se podrá utilizar en el sistema de destino.

• Contenido y archivos multimedia: texto de las páginas, artículos, descripciones de productos, imágenes, vídeos y archivos adjuntos. Comprueba si se exportan los propios archivos o solo enlaces a la plataforma original; estos últimos podrían dejar de funcionar cuando se cierre el sitio original.
• Productos y registros empresariales: códigos de producto, combinaciones de variantes, precios, inventario, categorías, información de clientes, consultas y pedidos. Comprueba especialmente si se conservan identificadores estables que vinculen las variantes, los clientes y los pedidos.
• Estructura del sitio e información para buscadores: URL de las páginas, títulos, descripciones, URL canónicas, correspondencia entre versiones en distintos idiomas y reglas de redireccionamiento. Aunque esta información se pueda exportar, la plataforma de destino debe admitir la configuración correspondiente.
• Cuentas y configuración operativa: permisos de administrador, formularios, correos electrónicos automatizados e integraciones de pago y logística. Algunas configuraciones dependen de la plataforma original o de servicios externos y es posible que no se puedan migrar junto con los datos.

También hay que distinguir entre migrar los datos y migrar las funciones del sitio web. Exportar el texto de una página no significa que se puedan copiar las plantillas y los componentes interactivos originales; obtener los registros de clientes tampoco significa que se puedan migrar las sesiones de inicio de sesión o las contraseñas. Las contraseñas suelen almacenarse de forma irreversible. La posibilidad de conservar el acceso con las credenciales actuales depende de los mecanismos de autenticación de ambas plataformas y, en algunos casos, los usuarios tendrán que restablecer su contraseña.

Revisa el resultado de la exportación, no solo la lista de funciones

Entre los métodos de exportación habituales se encuentran CSV, Excel, JSON, XML, API y los archivos de bases de datos o de archivos que proporciona el proveedor. El formato, por sí solo, no demuestra que la migración vaya a ser correcta: CSV facilita el procesamiento de tablas, pero puede separar en varias tablas las variantes complejas de los productos, el contenido anidado y las relaciones entre idiomas; JSON puede representar estructuras jerárquicas, pero aun así hay que confirmar si la plataforma de destino acepta los mismos campos y el mismo modelo de datos.

Solicitar al proveedor una descripción de los campos y una muestra anonimizada resulta más útil que limitarse a confirmar que «admite la exportación a CSV». La muestra debería incluir objetos complejos, como productos con varias variantes, contenido en varios idiomas, registros con archivos adjuntos y pedidos en distintos estados. Durante la revisión, comprueba especialmente lo siguiente:

• Si los campos exportados incluyen todos los datos necesarios para el negocio y si se conservan los ID internos, los ID de relación y los campos de fecha y hora;
• Si la codificación del texto, los saltos de línea, los caracteres especiales y el contenido en idiomas que no utilizan el alfabeto latino se muestran correctamente;
• Si las imágenes se pueden descargar en bloque y si los nombres de archivo o las direcciones se pueden asociar a los registros originales;
• Si la exportación incluye todos los datos o solo los resultados del filtro actual, y si existen límites de cantidad, de intervalo de tiempo o relacionados con el plan contratado;
• Si se incluyen los datos eliminados, archivados o en estados históricos.

Por ejemplo, un producto puede tener un nombre, una descripción y una URL diferentes para cada idioma. Si el archivo exportado solo conserva el idioma predeterminado o no permite identificar la relación entre los registros de cada idioma, aunque la exportación se haya realizado correctamente, habrá que volver a establecer la correspondencia entre idiomas en el nuevo sitio. Es necesario identificar este trabajo durante la selección de la plataforma, no dejarlo para justo antes del cambio.

Que haya una API no significa que la migración sea posible

Si la migración depende de una API, hay que comprobar por separado la capacidad de lectura y la de escritura. La plataforma de origen puede permitir consultar los productos, pero no exportar los pedidos; la plataforma de destino puede permitir crear productos, pero no importar la fecha y hora originales, el estado del pago o los ID especificados de los pedidos históricos. Los datos que queden fuera del alcance de la API quizá solo puedan importarse por otros medios o conservarse como archivos históricos.

La documentación de la API debe verificarse junto con los permisos reales: si los endpoints pertinentes están disponibles en el plan actual; si admiten paginación, filtros y consultas incrementales; y si existen límites en la frecuencia de las solicitudes, la cantidad de datos por operación o la carga de archivos adjuntos. Para grandes volúmenes de datos, también hay que confirmar que existan mecanismos para reintentar las operaciones fallidas, gestionar los envíos duplicados y consultar los registros de errores, a fin de evitar registros duplicados u omisiones si se interrumpe la migración.

Si el cambio del sistema no puede interrumpir el servicio durante mucho tiempo, una única exportación completa no es suficiente. Hay que confirmar si es posible obtener datos incrementales por fecha de actualización o identificar de otro modo los registros añadidos, modificados y eliminados después de la exportación completa, y sincronizarlos durante la ventana final del cambio. Si la plataforma no puede proporcionar información fiable sobre los cambios, habrá que reservar tiempo para la comprobación manual o para detener temporalmente la escritura de datos.

Valida con una migración de alcance reducido que los datos no solo se puedan exportar, sino también utilizar

Las declaraciones por escrito del proveedor sirven para una evaluación inicial, pero la valoración final debe basarse en los resultados de la importación en el entorno de destino. Selecciona un conjunto representativo de datos anonimizados que incluya páginas en varios idiomas, productos con múltiples variantes, imágenes y relaciones entre clientes y pedidos. Exporta los datos de la plataforma de origen, impórtalos en la plataforma candidata y registra qué elementos requieren conversión o introducción manual.

La validación no debe limitarse a comparar el número total de registros. También hay que comprobar por muestreo los valores de los campos y las relaciones entre registros: por ejemplo, si las variantes de los productos están vinculadas a las imágenes correctas, si los pedidos están asociados a los clientes correctos, si los importes y las monedas coinciden y si las páginas en distintos idiomas apuntan a las versiones correspondientes. Si falla la importación de algún registro, hay que confirmar si se puede identificar la causa del error y si es posible volver a intentarlo de forma individual tras corregirlo.

La continuidad de acceso al sitio web también debe validarse por separado: si el nuevo sitio permite conservar las URL originales y, cuando no sea posible, si permite configurar redireccionamientos 301 en bloque; y si se pueden configurar los títulos, las descripciones y las URL canónicas de las páginas. Los redireccionamientos ayudan a gestionar los cambios de dirección, pero no garantizan que las posiciones en los resultados de búsqueda ni el estado de indexación se mantengan exactamente igual. También hay que coordinar el cambio de la resolución del dominio, los certificados y los enlaces externos con la migración del contenido.

Incluye las condiciones de salida en la selección de la plataforma y en el contrato

Que los datos se puedan exportar técnicamente no significa que la empresa pueda obtenerlos completos en cualquier momento. Hay que confirmar si existe un plazo de exportación tras el vencimiento del servicio, la desactivación de la cuenta o la rescisión del contrato; si la exportación requiere asistencia manual del proveedor; si la entrega de archivos, la conversión de campos, las llamadas a la API y el soporte técnico tienen un coste adicional; y cómo se acordarán los plazos de entrega.

En el caso de datos que incluyan información de clientes, consultas y pedidos, también hay que definir las autorizaciones de acceso, los métodos de transferencia y las condiciones de conservación y eliminación tras la entrega. Asimismo, se deben evaluar las condiciones de tratamiento de acuerdo con los requisitos de protección de datos de las regiones pertinentes para la actividad. Durante las pruebas, conviene utilizar datos anonimizados para evitar la divulgación innecesaria de información personal al validar la capacidad de migración.

Por último, se pueden clasificar los datos según las capacidades de la plataforma en tres categorías: los que se pueden importar directamente y validar, el contenido que requiere conversión o reconstrucción manual y los elementos que no se pueden migrar o que solo se pueden archivar. Solo si se definen claramente el alcance, las responsabilidades y los costes de cada categoría será posible determinar si las limitaciones de migración de la plataforma son aceptables para el negocio.