Lo que aprendí migrando datos entre plataformas de e-commerce

¿Cuándo hace falta migrar datos?

En el trabajo he ayudado a algunas empresas a migrar su plataforma de e-commerce. Este tipo de necesidad suele aparecer cuando una empresa ya lleva un tiempo vendiendo en su plataforma actual y, porque quiere más funcionalidades o por alguna decisión de negocio, decide cambiarse a otra plataforma. Como ya ha estado operando allí durante un tiempo, también ha acumulado bastantes datos. Desde el punto de vista de la empresa, lo normal es que quiera llevárselos. Además, normalmente no querrá seguir pagando la plataforma anterior, así que tarde o temprano tendrá que cerrar su panel de administración. En ese momento toca trasladar los datos que estaban en la plataforma original a la nueva.

Este tipo de datos suele dividirse en tres categorías: productos, clientes y pedidos. A continuación cuento un poco mi experiencia con cada una.

Productos

Los productos suelen ser la parte más sencilla. En comparación, normalmente hay menos registros y, aunque se migren, la empresa casi siempre tendrá que revisarlos, maquetarlos y ordenarlos por su cuenta. Los problemas que suelen aparecer aquí tienen más que ver con las reglas de categorías de cada plataforma, o con cómo las categorías configuradas en el panel de administración se corresponden con lo que se muestra en la tienda. Cada plataforma lo hace un poco a su manera, aunque normalmente la clasificación también acaba gestionándose desde el lado de la empresa.

Clientes

Los datos de clientes también se pueden migrar, pero después de la migración los clientes no tienen por qué mudarse contigo 😹. Desde el lado técnico, lo que podemos hacer es ayudar a la empresa a guardar esos datos en la nueva plataforma: conservar la información de contacto, el nivel de membresía, etc. Como mucho, si la plataforma lo permite, se puede generar un enlace de activación de cuenta y enviar una notificación por correo a los consumidores. Pero la empresa tendrá que acompañarlo con alguna campaña o actividad para conseguir que esas personas entren de verdad en la nueva plataforma y activen su cuenta.

Pedidos

Los pedidos son la parte más complicada. Las primeras veces que hice este tipo de migración, probaba a llamar a la API de la plataforma de origen, sacaba algunos registros para compararlos con los campos de la plataforma de destino. Cuando me parecía que la conversión y el mapeo de campos estaban más o menos listos, empezaba a enviar datos a la API de la plataforma de destino. Pero, mientras iba enviando, aparecían registros que fallaban en la conversión o que no se creaban correctamente. Entonces revisaba qué había pasado y descubría que eran pedidos con casos especiales: quizá una devolución, quizá una cancelación, etc. Tocaba ajustar las reglas de mapeo y volver a enviar. Luego volvían a aparecer errores; al revisarlos, resultaba que la regla de los créditos o recompensas no estaba bien escrita… así que otra vez a modificar y reenviar. Después de varias rondas así, acababa consiguiendo cargar todos los datos.

A lo largo del tiempo hice varias migraciones de datos y, curiosamente, nunca me encontré con un caso en el que la plataforma de origen y la plataforma de destino fueran exactamente la misma combinación. Eso dice bastante de lo variado que es el mercado de plataformas de e-commerce en Taiwán. Me encontré de todo: desde plataformas más tradicionales que no ofrecían API y solo permitían descargar un Excel de pedidos desde el panel de la tienda (con archivos tan enormes que incluso abrirlos costaba), hasta plataformas de destino en las que, al guardar datos por API, aparecían problemas constantemente y el contacto de la plataforma acababa diciendo que también era la primera vez que se encontraban con alguien intentando insertar tantos datos por API 🤨.

De tomar datos al azar a elegir casos con intención

Después de hacerlo unas cuantas veces, probé otro enfoque: dejé de recibir datos de forma pasiva, analizarlos y probar, y pasé a elegir activamente los datos que quería ver. Por la experiencia anterior, aprendí que los pedidos se pueden dividir, en general, entre “pedidos normales” y “pedidos especiales”. Un pedido normal es el caso en el que el cliente hace el pedido, paga, la tienda lo envía, el cliente lo recibe sin problemas y todo el mundo queda contento. En cambio, los pedidos especiales incluyen devoluciones, devoluciones parciales, cambios, cancelaciones, pedidos sin finalizar, descuentos, créditos o recompensas, etc. Con este tipo de pedidos, solo mirando el JSON devuelto por la API es imposible entender bien qué significa cada campo. Hace falta apoyarse en la interfaz del panel de e-commerce de la plataforma de origen, buscar directamente números de pedido con esos casos, comparar con la pantalla real y entender qué significa cada dato recibido.

Es decir, ya no se trataba de llamar a la API a ciegas y tomar unos cuantos pedidos al azar, sino de ir al panel de administración con intención, escoger “la forma de pedido que quiero observar” y después llamar a la API para recuperar esos datos y hacer el mapeo de campos. Al cambiar a este enfoque, cuando enviaba datos por API a la plataforma de destino, todo iba bastante mejor. Seguía habiendo algunos registros fallidos, pero al mirar el detalle, casi siempre eran pedidos de prueba (normalmente se detectaban por el email, las notas, etc.).

Esta experiencia se me quedó bastante grabada. Antes siempre pensaba que hacer ETL / transformación de datos consistía en considerar el origen y el destino de los datos, y luego construir un adaptador intermedio que alineara campos y formatos. Para mí, ese adaptador era el centro del trabajo técnico. Pero después de ajustar el enfoque, me di cuenta de que lo importante era entender primero qué tipos de datos tenía delante, ver el panorama general y separar lo principal de lo secundario: resolver primero el 70% de los casos normales y tratar los casos especiales aparte. Con esta forma de pensar, dejé de mirar solo los datos en sí y empecé a verlos junto con los escenarios reales a los que pertenecen. Solo cuando se tiene en cuenta ese contexto real, los datos empiezan a tener sentido.