Planificar una migración a Shopify sin perder datos por el camino

Los productos siempre llegan. Esa es la parte engañosa de migrar una tienda: el catálogo aterriza, las imágenes cruzan, alguien abre el admin nuevo y se ve bien. Después llega el lanzamiento y las reseñas no están, las guías de tallas salen vacías, las URLs viejas de colección devuelven 404, y los clientes mayoristas no pueden entrar porque sus tags nunca viajaron con ellos.

Nada se perdió de forma dramática. Se perdió porque nadie anotó que existía. Un plan de migración es sobre todo papeleo: un inventario tomado antes de mover nada, una decisión al lado de cada línea, y un corte que se puede deshacer. La ingeniería es la mitad fácil.

Empieza por el inventario, no por la plataforma

El primer artefacto de una migración no es un tema ni un script de importación. Es una lista de lo que la tienda actual contiene de verdad — tomada de la tienda y no de la memoria, porque la memoria omite justamente lo que se rompe.

Exporta el catálogo y cuéntalo: productos, variantes, los archivados, los borradores. Saca las definiciones de metafields y, aparte, los namespaces que realmente cargan valores, porque una definición sin valores es una forma y una definición con cuarenta mil valores es una migración de datos. Lista las apps y qué guarda cada una. Lista los segmentos de clientes y los tags de los que dependen. Lista el contenido y los ajustes del tema que contienen textos que nadie recuerda haber editado. Lista las URLs que reciben tráfico.

La línea que más veces falta es la que más importa: los datos que viven dentro de una app y no dentro de la tienda. Reseñas, contratos de suscripción, saldos de fidelidad, listas de deseos, listas de precios negociadas. Shopify no los tiene; los tiene la app. Si el destino usa otra app, esos datos se mueven a través del proveedor o no se mueven. Pregunta antes de elegir la fecha de lanzamiento, no después.

Esa lista es el proyecto. Todo lo demás es ejecución.

Datos estructurales y datos transaccionales son dos migraciones

Fallan de forma distinta, quieren herramientas distintas, y correrlas como un solo trabajo es como una migración deja de ser repetible.

La estructura es la forma de la tienda

Definiciones de metafields y metaobjects, entradas de metaobjects, colecciones, navegación, páginas, blogs, ajustes del tema, markets, perfiles de envío. La estructura es idempotente por naturaleza: puedes correrla, mirarla, corregir el mapeo y volver a correrla, porque recrear una definición que ya existe devuelve TAKEN en vez de duplicar en silencio, así que el migrador tiene que comprobar antes de escribir — siempre que emparejes por clave lógica y nunca por ID de origen. Un ID de la tienda vieja no significa nada en la nueva.

El migrador estructural entre tiendas que construimos hace exactamente esto y se niega a tocar otra cosa. El razonamiento vale la pena robarlo: una herramienta que también puede mover pedidos es una herramienta que también puede perderlos.

Lo transaccional es el registro de lo que pasó

Pedidos, clientes, niveles de inventario, saldos de tarjetas de regalo. No es idempotente, es sensible al tiempo, y sigue cambiando mientras migras. Córrelo dos veces y tienes duplicados. Córrelo temprano y se queda viejo. Córrelo tarde y se vuelve la ruta crítica del corte.

Así que la secuencia no es paralela: estructura primero y muchas veces, transacciones una vez y al final. Los productos quedan en medio — bastante estructurales como para cargarlos semanas antes, bastante transaccionales en precio e inventario como para necesitar una pasada de deltas justo antes del cambio.

Qué tiene que moverse de verdad

Productos, variantes y su material

Empareja por SKU o por handle, nunca por ID de origen. Las imágenes son la parte que se rompe en silencio: los registros de producto se exportan limpios, pero el material que cuelga de ellos son URLs que apuntan a una tienda que está por apagarse. Descarga cada imagen durante la exportación y vuélvela a subir contra el producto destino. La migración de catálogo que hicimos desde BigCommerce fue, en la práctica, sobre todo esto: paginar la exportación, capturar imágenes a disco, resubirlas emparejadas por SKU.

Definiciones de metafields y valores, en dos pasadas

La omisión más común, y el síntoma más confuso. Una definición es un esquema: namespace, key, tipo, validaciones, el recurso al que se adjunta. Un valor es el contenido. Copia solo definiciones y tienes un admin que se ve completo sobre un storefront que no renderiza nada. Copia solo valores y tienes datos que el admin no muestra.

Definiciones primero, todas, y después valores. El orden importa otra vez por los tipos de referencia: un metafield de tipo product_reference guarda un ID global, y un ID global de la tienda origen no apunta a nada en el destino. Esos campos hay que resolverlos por clave lógica cuando ya existen ambos lados. Planea una pasada. No lo descubras el viernes.

Clientes

Clientes, direcciones, tags y consentimiento de marketing se mueven. Las contraseñas no. En las cuentas de cliente clásicas eso significa un reseteo de contraseña para cada cliente, que es un problema de comunicación antes que técnico: un login que ya no funciona, sin un correo que lo explique, se convierte en volumen de soporte durante un mes. Y importar una marca de consentimiento que no puedes evidenciar es una decisión legal, no una de datos.

Redirecciones y contenido

Cada URL con tráfico o con un enlace entrante necesita un destino. Saca la lista de la analítica y de search console y no del sitemap: el sitemap te dice qué existe, los logs te dicen qué pide la gente. Construye el mapa de redirecciones como archivo y verifícalo como una lista de aserciones y no haciendo clic en tres — que es la mayor parte de en qué consiste realmente la implementación de SEO en un lanzamiento. Páginas, blogs y menús se mueven junto a eso, y se dejan sistemáticamente para la semana del lanzamiento.

Qué no debería moverse

Una migración es la única oportunidad gratis que vas a tener de borrar cosas. Tómala, con una decisión escrita por categoría en lugar de un default de cargar con todo.

• Productos sin ventas en dos años que no sean de temporada. Archívalos en el origen.
• Namespaces de metafields de apps que no vas a reinstalar. Esos datos son inertes en la tienda nueva y van a confundir a quien lea el esquema después.
• Ajustes de un tema que estás reemplazando. Migrarlos reproduce decisiones tomadas para otro layout.
• Pedidos históricos más allá de tu necesidad operativa. Se discute, así que hazlo una decisión. Una postura defendible es migrar los últimos doce a veinticuatro meses como registros vivos y guardar el historial completo como una exportación consultable.
• Clientes que nunca compraron y no abren un correo hace años. Estás migrando un problema de entregabilidad.
• Todos los códigos de descuento que hayan existido. Migra los activos.

La prueba es si un registro tiene lector. Ningún cliente, ningún reporte, ninguna automatización lo lee — es peso.

La operación en paralelo, y un corte que se puede deshacer

El error es tratar el lanzamiento como un evento en vez de como un solapamiento. Los dos entornos deberían estar vivos a la vez: el viejo sirviendo clientes, el nuevo completo, alcanzable en un hostname temporal y haciendo trabajo real.

Trabajo real significa pedidos que llegan hasta el pago y la preparación, no una vista previa del tema. Después dispara las uniones. ¿El ERP recibe el pedido con la forma que espera? ¿El 3PL recibe la solicitud de fulfillment? ¿El motor de impuestos devuelve la tasa correcta? Eso se rompe de una forma que mirar el storefront nunca revela, y por eso el trabajo de integraciones va dentro de la operación en paralelo y no después.

Después, la pasada de deltas: productos nuevos, cambios de precio, inventario, y los clientes y pedidos creados durante el solapamiento. Congela lo que puedas — un congelamiento corto de catálogo es una petición normal y sensata — y corre los deltas tan cerca del cambio como te lo puedas permitir.

El corte en sí debería ser un solo cambio pequeño: mueve el dominio y observa. Lo pequeño es el punto. Un corte hecho de un único cambio reversible se deshace en lo que tarda en expirar un TTL, que es por lo que el TTL baja a un minuto o dos antes y vuelve a subir después.

Escribe el rollback antes del día, y sé honesto sobre dónde deja de estar disponible. No es el cambio de DNS. Es el primer pedido que la tienda nueva acepta y prepara. Antes de eso, volver no cuesta nada. Después de eso, un pedido existe en un sistema y no en el otro y estás reconciliando a mano. Saber dónde está ese umbral es lo que te deja programar el día con criterio en vez de con nervios.

El plan es el entregable

Nada de la ingeniería de aquí es difícil. Las exportaciones paginan, las importaciones hacen upsert, las redirecciones son un archivo. Lo difícil es la contabilidad: saber qué existe, decidir qué sobrevive, y ordenar la secuencia para que el cambio sea lo bastante pequeño como para revertirlo.

Escribe el inventario. Separa estructura de transacciones. Prueba las uniones y no la portada. Guarda un camino de vuelta hasta que el primer pedido preparado te lo quite. La mayoría de las migraciones que salen mal no fallaron técnicamente — fallaron en la lista, semanas antes de que alguien escribiera código. El trabajo en Shopify de este tipo se gana o se pierde en ese documento.