Caso de migración Shopify
Cómo Llantas Cavazos migró más de 8,000 SKUs a Shopify sin frenar la operación
Cómo una llantera establecida de Monterrey migró más de 8,000 SKUs a Shopify, añadió búsqueda por medida y sincronización de inventario, y conservó más del 90% del tráfico orgánico durante la primera semana.
Publicado
Resumen editorial
Qué obtendrás de esta guía
Cómo una llantera establecida de Monterrey migró más de 8,000 SKUs a Shopify, añadió búsqueda por medida y sincronización de inventario, y conservó más del 90% del tráfico orgánico durante la primera semana.
Qué demuestra este caso
Cómo Llantas Cavazos rediseñó datos de producto, búsqueda por medida, sincronización de inventario, continuidad SEO, historial de clientes y lanzamiento como una sola migración a Shopify.
Para quién es relevante
Líderes ecommerce, distribuidores, retailers automotrices y operadores que planean migrar miles de productos definidos por especificaciones y con demanda orgánica existente.
Llantas Cavazos no necesitaba una versión más bonita de la misma tienda. Necesitaba una operación ecommerce capaz de sostener un catálogo grande, productos definidos por especificaciones, varios flujos internos y clientes que suelen llegar con una pregunta urgente: ¿tienen la medida exacta de llanta que necesito?
El proyecto migró más de 8,000 SKUs activos de llantas desde T1Paginas, una plataforma heredada que ya limitaba la operación, a Shopify en menos de 7.5 semanas. El alcance incluyó arquitectura de catálogo, historial de clientes y pedidos, búsqueda por medida, sincronización de inventario en tiempo real, limpieza de Google Merchant Center, redirects SEO, capacitación y un lanzamiento controlado.
De acuerdo con la analítica revisada después del lanzamiento, la tienda conservó más del 90% de su tráfico orgánico durante la primera semana posterior a la migración.
| Resultado del proyecto | Cifra |
|---|---|
| Catálogo migrado | Más de 8,000 SKUs activos de llantas |
| Ventana de ejecución | Menos de 7.5 semanas |
| Tráfico orgánico conservado | Más del 90% durante la primera semana |
| Landing pages orientadas a búsqueda | 84 colecciones por medida |
| Operación de inventario | Shopify sincronizado con Google Sheets y herramientas internas |
| Descubrimiento de producto | Búsqueda personalizada por medida exacta |
| Continuidad operativa | Clientes, pedidos históricos, inventario y feeds integrados en la nueva operación |
Sobre Llantas Cavazos
Llantas Cavazos es uno de los distribuidores de llantas con mayor trayectoria en Monterrey. La empresa comunica más de 35 años de experiencia y opera varias sucursales en Monterrey y San Pedro, además de mayoreo y call center, según su página oficial de sucursales.
Ese contexto físico es importante. El sitio no funciona como un catálogo aislado. Es parte de una operación donde una persona puede investigar en línea, llamar para confirmar existencia, acudir a una sucursal, solicitar instalación o buscar una solución rápida después de detectar una llanta dañada.
Además, el comprador de llantas no navega como quien compra moda. Normalmente empieza con una medida impresa en el costado de la llanta —por ejemplo 225/45R17— y espera que la tienda entienda esa información de inmediato.
Toda la migración se diseñó alrededor de ese comportamiento.
La plataforma anterior ya limitaba la operación
La tienda funcionaba sobre T1Paginas. La plataforma había acompañado al negocio durante años, pero ya no respondía a la complejidad acumulada del catálogo.
El problema principal no era el diseño visual. Era la estructura.
Cada llanta necesita información que influye directamente en la compra:
- ancho;
- perfil;
- diámetro del rin;
- índice de carga;
- código de velocidad;
- marca y modelo;
- disponibilidad;
- relaciones con paquetes, instalación, accesorios o garantías.
En la plataforma anterior, buena parte de estos datos dependía de convenciones manuales y soluciones improvisadas. Incluso un cliente que ya conocía su medida podía terminar recorriendo un catálogo muy amplio sin una ruta clara.
El equipo interno también tenía que conciliar existencias y relaciones entre productos usando herramientas que no estaban pensadas para operar como un solo sistema.
El inventario añadía otra restricción. Una llantera vende con frecuencia cantidades y configuraciones relacionadas: cuatro piezas del mismo modelo, servicios de instalación, garantías o accesorios que dependen del mismo stock base. Cuando la tienda, la hoja de cálculo y la lógica interna no coinciden, el negocio puede sobrevender producto agotado o esconder inventario que todavía podría comercializarse.
A esto se sumaba un activo que no podía perderse: años de visibilidad orgánica en búsquedas por medida y producto. Cambiar de plataforma sin proteger esas URLs habría resuelto el problema tecnológico creando uno comercial.
Qué debía lograr una migración exitosa
Antes de mover datos, el proyecto se definió en términos de negocio, clientes y operación.
La nueva tienda debía:
- llevar al cliente a la selección correcta en segundos;
- administrar más de 8,000 productos sin convertir el mantenimiento del catálogo en trabajo manual constante;
- mantener el inventario alineado con las herramientas que el equipo ya utilizaba;
- conservar información de clientes y pedidos históricos necesaria para servicio y garantías;
- dar a Google destinos claros para las URLs antiguas de productos y medidas;
- salir en una sola ventana controlada, sin operar durante meses dos catálogos que se desactualizaran entre sí;
- ser entendible y operable por los equipos de marketing y operaciones después de la entrega.
Esta definición evitó que la migración se convirtiera en un rediseño de tema acompañado por una importación de datos. Catálogo, búsqueda, operación, SEO y preparación de lanzamiento se trataron como un solo programa.
Por qué importaba la ventana de menos de 7.5 semanas
El proyecto se entregó en menos de 7.5 semanas. Esto no se logró recortando el alcance ni capturando productos manualmente a mayor velocidad. Requirió automatización, validaciones repetibles y decisiones claras antes de comenzar la importación.
Un catálogo de este tamaño no puede revisarse producto por producto. El equipo necesitaba reglas aplicables de manera consistente a miles de registros y después auditorías para encontrar excepciones. Datos, imágenes, atributos, redirects y relaciones de inventario se manejaron como workstreams estructurados, no como tareas aisladas.
La ventana corta también redujo el riesgo de transición. Mantener demasiado tiempo la plataforma anterior y Shopify en paralelo habría creado oportunidades para que inventario, precios y datos de producto dejaran de coincidir. También habría expuesto a Google durante más tiempo a experiencias duplicadas o incompletas.
El objetivo era un cutover preparado, no un periodo prolongado en el que ninguno de los dos sistemas resultara completamente confiable.
Por qué Shopify era el destino correcto
Shopify se eligió porque podía ofrecer una base estable de comercio y, al mismo tiempo, permitir adaptar catálogo, búsqueda, automatizaciones e integraciones a la realidad de una llantera.
La decisión no se tomó por comodidad genérica. Respondía al modelo operativo que el negocio necesitaba después del lanzamiento:
- atributos estructurados para miles de productos definidos por especificaciones;
- colecciones automáticas capaces de actualizarse sin asignación manual;
- automatizaciones alrededor de inventario y eventos operativos;
- un admin entendible para el equipo del cliente;
- una plataforma capaz de absorber tráfico y actividad de feeds sin que la llantera administrara servidores;
- un ecosistema donde búsqueda e integraciones personalizadas pudieran añadirse sin reconstruir toda la plataforma ecommerce.
La propia documentación de migración de Shopify separa productos, clientes, datos históricos, redirects y pruebas posteriores como workstreams distintos. En Llantas Cavazos, todos tenían que avanzar coordinados.
Discovery y auditoría de datos antes de la primera importación
Antes de mover un solo producto, el proyecto comenzó con una revisión completa del catálogo heredado, la estructura de URLs, los datos de clientes, el historial de pedidos, las dependencias de inventario y el feed de Google Merchant Center.
Los catálogos grandes rara vez mantienen una consistencia perfecta durante muchos años. Distintos equipos capturan una misma especificación con formatos diferentes. Aparecen duplicados. Un producto puede conservar una imagen antigua, una medida incompleta o un nombre que ya no coincide con el modelo actual. Los artículos descontinuados permanecen activos en feeds. Algunas URLs acumulan valor orgánico aunque la estructura original ya no tenga sentido.
La auditoría identificó:
- registros duplicados y desactualizados;
- nombres y formatos de medida inconsistentes;
- especificaciones faltantes o poco confiables;
- relaciones de imágenes y variantes;
- dependencias de inventario;
- URLs históricas con valor orgánico;
- productos inactivos que seguían presentes en Merchant Center;
- clientes y pedidos necesarios para mantener continuidad de servicio.
Este trabajo definió qué podía migrarse tal como estaba, qué debía normalizarse y qué necesitaba una estructura nueva. También permitió dimensionar el mapa de redirects antes de la semana de lanzamiento, en vez de descubrir el problema SEO cuando el dominio ya se hubiera movido.
Reorganizar el catálogo según la forma real de comprar llantas
Mover miles de filas entre plataformas no es lo más difícil en una migración de catálogo complejo. La parte difícil es decidir qué significa cada dato dentro del nuevo sistema.
Los atributos de una llanta no deberían vivir dentro de una sola descripción larga. Ancho, perfil, diámetro del rin, índice de carga, código de velocidad y otras especificaciones necesitan campos consistentes para poder buscarse, filtrarse, mostrarse y reutilizarse.
Antes de importar, Shugert diseñó una estructura de datos de producto en Shopify para esos atributos. La importación trasladó después más de 8,000 SKUs activos y su información relacionada a ese modelo.
Esto permitió que cada producto tuviera un lugar claro para sus especificaciones importantes. La misma estructura podía alimentar páginas de producto, búsqueda, colecciones, inventario y feeds de marketing.
También se construyeron 84 colecciones automáticas organizadas por medida. Estas colecciones se actualizan mediante reglas, sin obligar al equipo a asignar manualmente miles de productos.
Para el cliente, esto significa encontrar páginas relevantes según la medida que busca. Para el equipo interno, significa que una llanta nueva puede entrar a las colecciones correctas cuando sus datos se cargan bien. Para Google, significa contar con páginas más claras sobre búsquedas específicas, en lugar de depender de un catálogo genérico que intenta responder a todas las medidas al mismo tiempo.
Una búsqueda personalizada alrededor del dato más importante
La interacción principal de la nueva tienda se convirtió en la búsqueda por medida.
En vez de obligar al usuario a recorrer categorías y filtros genéricos, la experiencia comienza con la información que probablemente ya conoce: la medida escrita en su llanta.
El widget personalizado interpreta esa medida y devuelve productos relevantes del catálogo estructurado. El servicio de búsqueda opera por separado del tema sobre la red de Cloudflare, lo que permite responder con rapidez sin que Llantas Cavazos tenga que administrar infraestructura propia. Cloudflare describe Workers como una plataforma serverless para desplegar aplicaciones a través de su red global.
La decisión técnica tiene una traducción sencilla para el cliente:
- ingresar la medida;
- ver llantas compatibles;
- confirmar disponibilidad;
- comparar opciones relevantes;
- continuar hacia la compra o el servicio en sucursal.
Es una ruta mucho más corta que navegar entre miles de SKUs.
La búsqueda personalizada también dio al negocio mayor control que un campo genérico por palabras clave. Las especificaciones exactas podían interpretarse como datos estructurados, no sólo como texto que casualmente aparecía en el título de un producto. En una categoría donde un solo carácter puede cambiar la pieza necesaria, esa diferencia importa.
Un tema diseñado para un comprador guiado por especificaciones
La tienda también debía explicar el producto de otra manera.
Una persona que busca llantas no está principalmente buscando una imagen lifestyle y una descripción breve. Sus preguntas son prácticas:
- ¿es la medida correcta?
- ¿cuáles son el índice de carga y el código de velocidad?
- ¿hay existencia?
- ¿qué garantía o servicio aplica?
- ¿puedo instalarla en una sucursal cercana?
Las páginas de producto se organizaron para mostrar la información que determina la compra, sin esconderla dentro de texto sin estructura.
Los templates de colección siguieron la misma lógica. Filtros y navegación priorizaron los atributos que los clientes realmente utilizan —como medida, marca y tipo de producto— en vez de depender únicamente de filtros genéricos de ecommerce.
La regla en toda la tienda fue sencilla: Shopify debía adaptarse a la manera en que las personas compran llantas, no obligar al comprador a seguir las suposiciones de un tema de retail general.
Experiencia móvil y performance
Muchas búsquedas de llantas ocurren desde un teléfono y bajo presión. Una persona puede estar junto a una llanta dañada, leyendo el código del costado o intentando confirmar existencia antes de desplazarse a una sucursal.
Ese contexto cambió el estándar de performance. El cliente no tiene tiempo para una página pesada, un filtro de varios pasos o una búsqueda que espere a cargar un catálogo completo.
El servicio de búsqueda se mantuvo fuera del proceso de render del tema y la tienda se construyó para mostrar especificaciones sin cargar primero capas innecesarias. También se evitó el patrón habitual de instalar una app distinta para cada función, agregando en cada caso scripts y nuevos puntos de falla.
Para este negocio, la velocidad móvil no era optimización cosmética. Influía en descubrimiento de producto, visitas a sucursales, tráfico pagado y búsqueda orgánica.
Inventario sincronizado con Google Sheets y herramientas internas
Llantas Cavazos ya tenía procesos operativos fuera de la tienda en línea. Reemplazar todas las herramientas conocidas habría complicado la adopción y aumentado el riesgo del proyecto.
En lugar de eso, Shopify se conectó con un flujo basado en Google Sheets y con herramientas internas de automatización de Shugert. Las actualizaciones podían viajar entre las fuentes operativas y Shopify, mientras una conciliación programada revisaba diferencias que un evento aislado pudiera no detectar.
La arquitectura de inventario utilizó dos capas complementarias:
- actualizaciones inmediatas cuando ocurrían pedidos, cambios de stock u otros eventos relevantes;
- conciliaciones programadas para detectar diferencias provocadas por cargas masivas, herramientas externas o casos que no siguieran el flujo normal de la tienda.
Esto era especialmente importante para relaciones entre productos: juegos de llantas, servicios, accesorios u otras configuraciones que comparten el mismo inventario base. Una tienda puede parecer correcta y aun así sobrevender si un paquete y sus componentes se contabilizan por separado.
Shopify explica en su documentación de inventario que una gestión precisa ayuda a evitar vender productos agotados y facilita entender los niveles disponibles.
Para el equipo de Llantas Cavazos, el beneficio no fue la tecnología en sí. Fue reducir correcciones manuales, mostrar disponibilidad más confiable y tener una fuente operativa más clara.
El historial de clientes y pedidos también se migró
El proyecto no se limitó a productos activos.
Los pedidos históricos y la información de clientes eran importantes porque una compra de llantas puede generar preguntas meses después. Un cliente puede volver por una garantía, pedir confirmación de lo que compró o buscar un reemplazo equivalente.
Dejar ese historial en una plataforma retirada habría obligado al equipo a consultar dos sistemas o mantener acceso antiguo indefinidamente.
La migración incluyó los registros necesarios para seguir atendiendo relaciones existentes desde el nuevo entorno.
Este trabajo es fácil de subestimar porque no aparece en el storefront. Operativamente, determina si el servicio al cliente mejora después de la migración o simplemente hereda una nueva serie de vacíos de información.
Proteger el tráfico orgánico durante el cambio
Una migración cambia al mismo tiempo URLs, templates, navegación y enlaces internos. Google no entiende automáticamente que cada página antigua tiene una equivalente nueva.
El mapa de redirects se construyó junto con el catálogo, no como una tarea posterior al lanzamiento. Las URLs relevantes de productos y categorías se relacionaron con el destino válido más cercano dentro de Shopify.
El objetivo era conservar intención. No enviar todas las páginas antiguas al home.
Este enfoque sigue los principios de la guía oficial de Google para migraciones con cambios de URL: preparar un mapeo, utilizar redirects permanentes, actualizar señales internas y monitorear URLs antiguas y nuevas después del lanzamiento.
Las colecciones por medida también dieron al sitio destinos indexables alineados con búsquedas long tail. Una persona buscando una medida específica podía llegar a una página construida alrededor de esa necesidad, en vez de aterrizar en un catálogo sin filtrar.
El resultado medido fue sólido para un proyecto de este tamaño: más del 90% del tráfico orgánico se conservó durante la primera semana después del lanzamiento.
Ese dato no significa que una migración no tenga riesgo SEO. Refleja el trabajo realizado antes del cutover: limpieza de catálogo, mapeo de URLs, arquitectura de colecciones, staging y monitoreo.
Limpiar la base de Google Merchant Center
El feed anterior incluía productos descontinuados, ofertas antiguas y registros que ya no representaban el catálogo activo.
Arrastrar esa deuda a Shopify habría provocado diferencias evitables entre la tienda y Google. También habría dificultado que marketing distinguiera si un problema provenía del catálogo, del feed o de una publicación antigua que ya no debería existir.
Merchant Center se limpió y se reconstruyó con base en el nuevo catálogo para que productos activos, precios, disponibilidad e identificadores arrancaran desde una estructura más confiable.
La especificación de datos de producto de Google Merchant Center exige identificadores y atributos consistentes. En un catálogo con miles de productos muy parecidos, la calidad del dato no es un detalle administrativo. Determina si Google puede entender y mostrar correctamente cada oferta.
El staging y el lanzamiento se trataron como operación de negocio
Antes del cambio final se probaron situaciones reales para clientes y equipo interno:
- buscar una medida común;
- encontrar una medida poco frecuente;
- revisar especificaciones desde móvil;
- confirmar existencia;
- comprar cantidades o configuraciones relacionadas;
- localizar historial de clientes;
- abrir una URL guardada del sitio anterior;
- verificar productos activos en Merchant Center;
- comprobar que las reglas de colección respondieran correctamente a los datos;
- confirmar que las actualizaciones de inventario llegaran a los sistemas esperados.
Las migraciones de catálogo grande suelen fallar por casos atípicos, no porque la estrategia general sea incorrecta. Un producto común puede funcionar perfectamente mientras un SKU descontinuado, un juego con inventario parcial o un cliente con pedidos antiguos revela el problema real.
La salida a producción ocurrió en una sola ventana planeada. Redirects, DNS, estado del catálogo, flujos de inventario y cambio del feed se coordinaron como partes del mismo lanzamiento.
Esto redujo el periodo en el que dos plataformas podían mostrar inventario, precio o disponibilidad diferentes.
Resultados del lanzamiento
La migración dio a Llantas Cavazos una base ecommerce acorde con el tamaño de la empresa, no con los límites de la plataforma anterior.
Más de 8,000 SKUs dentro de un catálogo estructurado
Las especificaciones dejaron de ser texto aislado y se convirtieron en datos reutilizables para páginas de producto, búsqueda, colecciones, inventario y marketing.
Una ruta más rápida hacia la llanta correcta
El cliente puede buscar por medida exacta en vez de recorrer manualmente un catálogo plano. Esto refleja la forma en que las personas compran llantas y también la manera en que buscan en Google.
Inventario conectado con la operación real
Shopify, Google Sheets y las herramientas internas ahora trabajan juntos, reduciendo la conciliación manual entre sistemas desconectados.
Más del 90% del tráfico orgánico conservado durante la primera semana
El mapa de redirects y la arquitectura por medida dieron a Google señales claras durante el cambio de plataforma.
Una forma repetible de hacer crecer el catálogo
Nuevas marcas, medidas y categorías relacionadas pueden seguir una estructura ya definida. El negocio no necesita rediseñar el catálogo cada vez que amplía su oferta.
Una base más limpia para Shopping y adquisición futura
Merchant Center comenzó a operar sobre un feed más confiable, dando al equipo de marketing un mejor punto de partida para campañas de Shopping y crecimiento continuo del catálogo.
Handoff: el equipo del cliente podía operar la nueva tienda
Una migración no está terminada si cada cambio de catálogo todavía depende de la agencia.
La estructura de producto, convenciones de nombres, reglas de colecciones y flujos diarios se documentaron en lenguaje práctico. Los equipos de marketing y operaciones recibieron capacitación para:
- agregar y actualizar llantas;
- cargar correctamente las especificaciones;
- entender cómo entra un producto a las colecciones por medida;
- revisar estados de inventario;
- identificar si un problema pertenecía a la tienda, a la fuente de datos o a la automatización.
Las 84 colecciones se actualizan mediante reglas cuando la información del producto se captura correctamente. Esto permite que los cambios habituales de surtido sigan un proceso definido, en vez de convertirse cada vez en una nueva solicitud de desarrollo.
Shugert continuó a cargo de la capa técnica más profunda y del roadmap posterior, pero la operación cotidiana quedó en manos del equipo que conoce el negocio.
Qué ocurrió después del lanzamiento
La migración fue la base, no el final de la relación.
Después de la estabilización, la siguiente etapa se enfocó en aprovechar la nueva infraestructura en vez de seguir peleando con los límites de la plataforma anterior. El roadmap incluyó:
- monitorear el mapa de redirects mientras el catálogo seguía cambiando;
- extender la taxonomía de producto para nuevas marcas y especificaciones;
- refinar la búsqueda utilizando consultas reales de clientes;
- mantener consistencia de inventario entre Shopify, Google Sheets y herramientas internas;
- ampliar visibilidad orgánica con nuevas combinaciones de medida y marca;
- mejorar la base de Merchant Center para la actividad continua de Shopping;
- continuar la planeación SEO y de búsqueda pagada desde una base técnica más limpia.
La capa interna de automatización también permitió añadir nuevos procesos programados sin crear un servicio independiente y desconectado para cada necesidad operativa.
El cambio importante no fue únicamente que el sitio quedara sobre Shopify. Fue que nuevas iniciativas de crecimiento podían construirse sobre un modelo reutilizable de catálogo y automatización, en vez de empezar desde cero.
Por qué este caso importa más allá del sector de llantas
Las lecciones aplican a cualquier comercio cuyos productos se eligen por especificaciones y no sólo por apariencia:
- autopartes;
- suministros industriales;
- componentes eléctricos;
- materiales de construcción;
- catálogos médicos o de laboratorio;
- distribuidores B2B;
- refacciones y accesorios.
Para estos negocios, una migración a Shopify no es principalmente un proyecto de tema. Es un rediseño coordinado de datos de producto, búsqueda, inventario, historial de clientes, SEO y procesos operativos.
Las lecciones prácticas son consistentes:
- diseñar la taxonomía de producto antes de importar;
- construir la búsqueda según la forma en que el comprador identifica el producto;
- conectar el inventario con la fuente de verdad de la operación;
- combinar actualizaciones inmediatas con conciliaciones programadas;
- construir redirects antes del lanzamiento, no después de que caiga el tráfico;
- probar casos atípicos en staging;
- capacitar al equipo del cliente para que el trabajo cotidiano no quede atrapado con la agencia.
Llantas Cavazos migró más de 8,000 SKUs activos en menos de 7.5 semanas, conservó más del 90% del tráfico orgánico durante la primera semana y lanzó una infraestructura de búsqueda, catálogo, inventario y marketing que la plataforma anterior no podía sostener.
Ese es el estándar de una migración de catálogo complejo bien ejecutada: el trabajo difícil ocurre detrás de la tienda, mientras comprar y operar se vuelven más sencillos.
¿Planeas migrar un catálogo complejo?
La primera conversación útil no trata sobre colores o secciones de un tema. Trata sobre estructura de catálogo, dependencias operativas, comportamiento de búsqueda, ownership de inventario, datos históricos, riesgo SEO y evidencia necesaria para un cutover seguro.
Shugert define estos workstreams como un proyecto de precio fijo para los entregables, supuestos, exclusiones y criterios de aceptación aprobados.
Fuentes verificadas
Referencias oficiales utilizadas para validar el contexto de la empresa, las capacidades de plataforma y las recomendaciones de migración.
Continúa explorando
Migración de catálogo complejo
¿Planeas migrar miles de SKUs a Shopify?
Definimos catálogo, datos, búsqueda, inventario, continuidad SEO, QA y cutover como un solo proyecto controlado de precio fijo para el alcance aprobado.
Solicitar alcance de migración