Migrar un catálogo grande a Shopify Plus: límites reales, modelado de variantes y plan por fases

Qué es un catálogo grande y por qué no se mide en productos

Un catálogo no se complica por el número de referencias, sino por tres ejes a la vez: cuántos productos hay, cuántas variantes distingue cada producto y cuántas combinaciones de precio, idioma e impuestos hacen falta por mercado. Una tienda con 40.000 referencias simples da menos trabajo de migración que una con 3.000 productos de talla, color, acabado y precio por país.

Shopify anuncia productos ilimitados en todos sus planes: su página de precios incluye «Sell unlimited products» como característica de Basic, Grow, Advanced y Plus. El cuello de botella no está ahí, sino en el modelado de variantes, en el ritmo al que se puede escribir inventario por la API y en lo que el tema es capaz de mostrar en una ficha.

Por eso el primer entregable de una migración seria no es un calendario, sino un inventario del catálogo de origen con cifras. Cuántos productos activos, cuántos con más de tres atributos, cuántas variantes tiene el producto más grande, cuántas imágenes, cuántas URL indexadas y cuántos atributos de ficha técnica se usan de verdad.

• Más de tres atributos distinguen un SKU de otro: talla, color, acabado, largo
• Referencias que solo existen en un país o en un idioma
• Precios por cliente, por empresa o por volumen
• Fichas técnicas con decenas de atributos que hoy viven en campos propios del CMS antiguo
• Productos personalizables en los que el comprador escribe o sube algo

Los límites de plataforma que hay que comprobar antes de firmar

El cambio más importante de los últimos años es el tope de variantes. En su changelog del 15 de octubre de 2025, Shopify anunció que todos los comerciantes pueden crear productos con hasta 2.048 variantes, frente al límite histórico de 100. Buena parte del contenido en español sobre migraciones sigue citando el 100, así que conviene comprobar la fecha de cualquier guía que leas, incluida esta.

Lo que no ha cambiado es el número de opciones. La documentación de la Admin API GraphQL recoge el error OPTIONS_OVER_LIMIT, con el mensaje de que solo se puede especificar un máximo de tres opciones. Ese es el límite que de verdad obliga a replantear el modelo de datos: si hoy distingues un SKU por talla, color, material y largo, en Shopify no caben los cuatro como opciones del mismo producto.

En la API, las mutaciones de variantes trabajan por lotes acotados. Shopify documenta que productVariantsBulkCreate acepta hasta 2.048 variantes en una sola operación, y que se llega a las 2.048 solo con la estrategia REMOVE_STANDALONE_VARIANT; si no, son 2.047 junto a la variante que se crea sola. productVariantsBulkDelete trabaja con hasta 250. Al consultar las variantes de un producto se pueden pedir hasta 2.048 con el argumento first, y el campo variantsCount devuelve cuántas tiene.

Para el inventario hay otro techo que marca el ritmo de carga: desde la versión 2025-10 de la API, la mutación productSet aplica un máximo de 50.000 cantidades de inventario entre todas las variantes de una misma llamada. Es el número que determina cómo se trocea la carga de stock de un catálogo grande con varias ubicaciones.

Todo esto se gestiona por GraphQL, y ese es un punto que conviene cerrar antes de elegir herramientas. La referencia de la Admin API REST indica que esa API es heredada desde el 1 de octubre de 2024, y que listar, crear, actualizar y borrar productos quedó obsoleto en la versión REST 2024-04, con equivalentes en GraphQL: productCreate, products, product, productsCount, productUpdate y productDelete. La misma página añade que desde el 1 de abril de 2025 todas las apps públicas nuevas tienen que construirse exclusivamente con la Admin API GraphQL. Para una migración esto no es un detalle de desarrollador: condiciona qué herramienta de carga puedes usar y descarta cualquier script antiguo que escriba productos por REST.

• 2.048 variantes por producto para todos los comerciantes, desde octubre de 2025
• 3 opciones por producto: límite de la Admin API, error OPTIONS_OVER_LIMIT
• productVariantsBulkCreate: hasta 2.048 por operación, 2.047 sin REMOVE_STANDALONE_VARIANT
• productVariantsBulkDelete: hasta 250 por operación
• productSet: hasta 50.000 cantidades de inventario por llamada, API 2025-10
• Admin API REST: heredada desde el 1 de octubre de 2024
• Productos por REST (listar, crear, actualizar, borrar): obsoletos desde la versión 2024-04

El límite que casi nadie mira: el tema, Liquid y las apps heredadas

Que la plataforma acepte 2.048 variantes no significa que tu tema las muestre. La referencia de Liquid es explícita: product.variants devuelve un máximo de 250 variantes sin paginar, y con la etiqueta paginate se sirven hasta 50 por página. Un selector de variantes construido con un bucle sobre product.variants se queda corto en cuanto un producto pasa de 250, y el fallo no da un error visible: simplemente faltan combinaciones.

Con las apps pasa algo parecido. El propio changelog de las 2.048 variantes avisa de que los comerciantes que usen apps que no trabajan con las API de producto de GraphQL en soporte pueden encontrarse una experiencia degradada o rota al crear o ver productos con más de 100 variantes. Eso incluye conectores de ERP, de PIM, de feeds y de marketplaces, que son justo las piezas críticas de un catálogo grande.

La comprobación es barata y hay que hacerla antes de firmar, no después: crea en una tienda de desarrollo un producto con más variantes de las que tiene tu peor caso real, instala el tema candidato y las apps que vas a heredar, y mira qué pasa en la ficha, en el carrito, en el panel de inventario y en el feed de producto. Si algo se rompe, mejor saberlo cuando todavía puedes cambiar de tema o de app.

• Liquid: product.variants devuelve como máximo 250 variantes sin paginar
• Con paginate, hasta 50 variantes por página
• Apps fuera de las API de producto de GraphQL: experiencia degradada por encima de 100 variantes
• Probar con un producto extremo en una tienda de desarrollo antes de contratar nada

Qué hacer con lo que no cabe en tres opciones

El límite de tres opciones no se salta: se rodea cambiando el modelo. La primera vía son los metacampos y los metaobjetos, que es donde deben vivir los atributos de ficha técnica que no determinan el precio ni el stock. Material, certificaciones, consumo, compatibilidades o medidas de embalaje no necesitan ser una variante: necesitan estar estructurados, ser filtrables y poder reutilizarse en varias fichas.

Aquí sí hay cifras publicadas, y conviene tenerlas delante antes de dibujar el modelo de datos. Shopify documenta hasta 128 definiciones de metaobjeto para los planes Basic, Shopify y Advanced, y 256 para Plus y Enterprise, con un máximo de 40 campos por definición y hasta 1.000.000 de entradas en cada una. En metacampos, el tope es de 256 definiciones por tipo de recurso, de las cuales 50 pueden estar fijadas; las mutaciones por lotes admiten 25 metacampos por petición en metafieldsSet, con un máximo de 10 MB de carga, y 250 por petición en metafieldsDelete.

Ese reparto por plan importa al dimensionar un catálogo grande: si necesitas decenas de tipos de contenido estructurado (fichas técnicas, guías de tallas, ingredientes, compatibilidades, fabricantes), el doble de definiciones de metaobjeto en Plus deja de ser un detalle y pasa a ser un criterio de plan. Conviene mirar también los límites de render en Liquid: sin paginar se recorren hasta 50 entradas de metaobjeto y, con la etiqueta paginate, hasta 250 por página.

La segunda vía son los listados combinados. Shopify documenta la app de listados combinados para comerciantes de Shopify Plus, y precisa que un listado combinado puede tener hasta tres opciones además de las opciones de cada producto incluido en el listado. Sirve para agrupar lo que conceptualmente es un producto y técnicamente son varios, sin inflar el número de variantes de ninguno.

La tercera es dividir o simplificar. Si un atributo tiene dos valores y no se usa para filtrar ni para comprar, probablemente sobra. Si un atributo multiplica el catálogo por diez y casi nunca se vende, conviene revisarlo antes de migrarlo. Una migración es la mejor ocasión que vas a tener en años para quitarle peso al catálogo.

Para productos personalizables, la respuesta no es una variante por combinación. Shopify documenta las propiedades de línea de pedido: campos dentro del formulario de producto cuyo nombre es properties con el nombre de la propiedad entre corchetes, por ejemplo properties[Monogram], que acompañan a la línea del carrito. Un grabado, un texto o un archivo subido van ahí y no multiplican el catálogo.

Plan de migración por fases para un catálogo grande

El orden importa más que la velocidad. En los proyectos de migración que hacemos la secuencia es siempre la misma: primero auditoría y limpieza del origen, después modelado de producto, después carga por lotes y, solo al final, la ventana de corte. Cada lote se verifica antes de lanzar el siguiente, porque un error de modelado repetido veinte mil veces cuesta mucho más de deshacer que de prevenir.

La limpieza previa se hace en el sistema antiguo, no en Shopify: SKU descatalogados, duplicados, atributos sin uso, imágenes huérfanas y categorías vacías. Todo lo que no se limpia antes se migra, y lo que se migra hay que mantenerlo.

Para la carga conviene decidir pronto la herramienta. El CSV nativo de Shopify sirve para catálogos moderados y tiene sus reglas: el fichero no puede superar los 15 MB y, si la importación falla o se agota el tiempo, Shopify recomienda partirlo en varios. La coincidencia se hace por handle y, sin la opción de sobrescribir, los productos que coinciden con un handle existente se ignoran. Hay un detalle que rompe integraciones: cambiar los valores de las columnas Option1, Option2 u Option3 borra los identificadores de variante existentes y crea otros nuevos, lo que puede romper cualquier dependencia externa de esos identificadores. Y el CSV no sirve para borrar productos en masa.

Por encima de cierto volumen o complejidad la carga se hace por la Admin API GraphQL, troceada según los límites de arriba, con reintentos y con un registro de qué lote llevó cada producto. Ese registro es lo que permite reparar un error sin volver a cargarlo todo.

La verificación no se hace a ojo: se hace por muestreo con criterios fijos. En cada lote comprobamos un número de productos elegidos al azar más el peor caso conocido, y revisamos precio, stock por ubicación, imágenes, metacampos, colecciones y la ficha renderizada. Si quieres que miremos tu caso antes de decidir nada, nuestro servicio de migración a Shopify empieza justamente por esa auditoría del catálogo de origen.

• Auditoría del origen: productos, variantes, imágenes, atributos y URL, con cifras
• Limpieza en el sistema antiguo antes de exportar nada
• Modelado de producto cerrado y documentado antes del primer lote
• Carga en este orden: productos, inventario, metacampos y metaobjetos, colecciones, clientes, pedidos históricos
• Verificación por muestreo en cada lote, con el peor caso incluido
• Congelación del catálogo durante la ventana de corte y plan de reversión escrito

SEO: no perder el catálogo en el cambio de plataforma

El mapa de redirecciones es el entregable que más posiciones salva y el que más se improvisa. Tiene que ser producto a producto y categoría a colección, no una redirección genérica a la portada ni a la colección padre. Cuando el origen es Magento con el sufijo .html en las URL de producto, prácticamente ninguna URL antigua coincide con la nueva, así que el mapa cubre el catálogo entero.

Shopify permite importar redirecciones en masa desde un CSV, en Contenido, en menús, dentro de la vista de redirecciones de URL. Los topes publicados dan margen de sobra: una tienda puede tener hasta 100.000 redirecciones de URL, y las tiendas del plan Plus hasta 20.000.000. Conviene conocer también una limitación poco difundida: una redirección solo funciona para URL rotas. Si la URL de origen sigue cargando una página válida, la redirección no se aplica.

Con las facetas y los filtros indexados del sistema antiguo hay que decidir caso por caso. Las URL de filtro que tenían tráfico y enlaces merecen una colección propia en Shopify, con su título y su texto; el resto se redirigen a la colección correspondiente y se quedan fuera del sitemap. Multiplicar colecciones vacías para conservar URL antiguas sale caro en mantenimiento y no aporta nada.

Si hay varios idiomas o mercados, el control se amplía a canónicas, paginación de colecciones y hreflang entre los dominios o subcarpetas de cada mercado. Después del corte toca mirar Search Console a diario durante las primeras semanas: cobertura, 404, redirecciones detectadas y evolución de las URL que más tráfico traían. Ahí se ven los agujeros del mapa, y se tapan a tiempo.

• Mapa de redirecciones producto a producto y categoría a colección, entregable y revisable
• Importación masiva por CSV desde las redirecciones de URL del admin
• Hasta 100.000 redirecciones por tienda, y 20.000.000 en Plus
• Una redirección no se aplica si la URL de origen sigue devolviendo una página válida
• Vigilancia diaria de cobertura y 404 en Search Console las primeras semanas

Catálogo internacional y B2B sin duplicar productos

La tentación en una migración internacional es duplicar el catálogo por país. Con Markets no hace falta: las personalizaciones de un mercado controlan ajustes como la moneda, la disponibilidad de producto, el contenido del tema, los dominios, los idiomas y los impuestos sobre el mismo catálogo. Shopify también define una región de reserva para los compradores que no encajan en ningún mercado activo, un detalle que conviene configurar antes de abrir y no después.

Una expansion store se justifica cuando lo que cambia no es el precio ni el idioma, sino el negocio: surtido realmente distinto, operativa y almacén propios, o una entidad legal separada con su facturación. Si lo único que cambia son moneda, impuestos y traducciones, duplicar tienda multiplica el mantenimiento del catálogo sin ganar nada.

Para mayorista, el B2B nativo trabaja con catálogos: se elige qué productos y qué precios se ofrecen a los clientes B2B, con inclusión o exclusión de productos, ajustes de precio porcentuales y precios fijos. Los catálogos se asignan a un mercado B2B y, en el plan Plus, también directamente a ubicaciones de empresa. Hay un límite de plan que condiciona la arquitectura: en Basic, Grow y Advanced se pueden tener hasta tres asignaciones de catálogo activas entre los mercados B2B activos, y asignar el mismo catálogo activo a dos mercados activos cuenta como dos asignaciones. Ese límite de tres asignaciones no se aplica en el plan Shopify Plus.

Dicho al revés: si tu modelo mayorista necesita condiciones distintas para muchos grupos de clientes, el número de asignaciones de catálogo es un argumento técnico concreto a favor de Plus, bastante más sólido que los genéricos.

Qué pedir a tu agencia antes de firmar la migración

Una propuesta de migración de catálogo grande se juzga por cuatro documentos, no por el precio de la portada. El primero es el inventario del catálogo de origen con cifras: productos, variantes, el producto con más variantes, imágenes, atributos y URL indexadas. Si en la propuesta hay adjetivos donde deberían ir números, nadie ha mirado el catálogo todavía.

El segundo es el criterio de modelado de variantes, por escrito: qué tres atributos son opciones, qué pasa a metacampos o metaobjetos, qué se resuelve con listados combinados y qué con propiedades de línea de pedido. El tercero es el plan de redirecciones como entregable revisable, con su cobertura declarada sobre el total de URL indexadas. El cuarto es el plan de reversión y la ventana de corte: qué pasa si algo sale mal a mitad de la carga.

Pide también la prueba del peor caso en una tienda de desarrollo, con el tema y las apps candidatas, antes de comprometer el proyecto entero. Es poco trabajo y evita descubrir en producción que el selector de variantes se queda en 250.

En Weblineo trabajamos solo con Shopify desde 2016 y somos Shopify Plus Partner. Si estás valorando salir de Magento, PrestaShop o un desarrollo propio, podemos auditar el catálogo de origen y entregarte el modelado y el mapa de redirecciones antes de que decidas la plataforma.

• Inventario del catálogo de origen con cifras
• Criterio de modelado de variantes documentado
• Plan de redirecciones entregable, con cobertura declarada
• Plan de reversión y ventana de corte
• Prueba del peor caso con el tema y las apps candidatas