Los problemas en una migración hacia Square rara vez se explican únicamente por registros ausentes. Suelen aparecer cuando una tienda de origen se traslada a Square sin conservar las relaciones entre la biblioteca de artículos, las operaciones de Point of Sale, ubicaciones, inventario, Customers, Orders y Square Online. Un Product puede estar presente y resultar incómodo de vender, un Order puede ser legible pero quedar desconectado de su contexto de reembolso o procesamiento, y un Customer puede existir mientras se pierden los identificadores utilizados por el equipo o las integraciones.
La estrategia de prevención más sólida es tratar cada funcionamiento importante del origen como una relación operativa de Square. Cada problema siguiente describe un patrón recurrente, las señales que permiten detectarlo pronto y una condición concreta que demuestra que ha quedado controlado.
Problema 1: tratar Square como una tienda online genérica
Qué sale mal
La migración se planifica como una transferencia convencional de sitio web: se trasladan Products, Customers y Orders y el proyecto parece completo. Sin embargo, Square conecta la biblioteca de artículos con Point of Sale, ubicaciones, inventario, Orders, pagos, Customer Directory y, opcionalmente, venta online. Si no se definen esas relaciones, el equipo recibe registros existentes que no respaldan el flujo de venta previsto.
Un negocio centrado primero en web puede descubrir que el catálogo migrado resulta difícil de utilizar en caja. Un negocio orientado a POS puede descubrir que nunca se asignó responsable a visibilidad online, procesamiento o URL. El fallo comienza con una función de destino poco clara, no con un campo individual.
Señales tempranas
| Señal de advertencia | Consecuencia probable |
|---|---|
| El proyecto describe Square únicamente como el nuevo sitio web. | Las relaciones de POS, ubicaciones y operación de pagos quedan sin definir. |
| Los recuentos de Products son la principal medida de aceptación del catálogo. | Los Items pueden existir sin variaciones, modificadores o visibilidad de canal utilizables. |
| Square Online se aborda solo después de migrar el catálogo. | Páginas, rutas, Categories y disponibilidad online se convierten en retrabajo tardío. |
| Los flujos del equipo no aparecen en los ejemplos. | Los datos pueden estar técnicamente presentes pero ser operativamente inutilizables. |
Prevención
Define la función de Square como destino antes de relacionar registros. Indica si la tienda utilizará Point of Sale, Square Online, varias ubicaciones, recogida o entrega, servicios, inventario comercio minorista o una combinación. Después conecta cada tipo de registro migrado con el área de Square que debe consumirlo.
Utiliza un mapa sencillo de propiedad: los datos migrados establecen registros históricos o de catálogo; la configuración de Square controla el funcionamiento activo de ventas; las integraciones controlan datos sincronizados o externos. Así se evita confundir una capa con otra.
Ejemplo de recomendación
Para un retailer que migra desde una plataforma centrada en web, selecciona una familia representativa de Products y síguela a través de la biblioteca de artículos, una venta POS, visibilidad online, inventario por ubicación y el Order resultante. Esto descubre brechas del modelo de destino que una revisión limitada a la tienda online no mostraría.
Condición de aprobación
El modelo operativo de destino identifica los productos y ubicaciones de Square que utilizarán cada área de datos migrados, y los registros representativos respaldan los flujos previstos del equipo y compradores sin depender de suposiciones no documentadas.
Problema 2: aplanar Items, variaciones, opciones y modificadores
Qué sale mal
La estructura de Product del origen se convierte en una lista plana de Items de Square. Las elecciones de variantes, valores de opción, modificadores seleccionados durante la venta, SKU, precios, imágenes y comportamiento de stock se mezclan o se representan en el nivel equivocado. El resultado puede multiplicar Items innecesariamente, eliminar elecciones necesarias o convertir variantes con inventario en selecciones de texto sin stock.
Square distingue el Item principal de las Item Variations y también puede utilizar opciones de Item y listas de modificadores. Estas estructuras resuelven problemas diferentes. Las variaciones representan formas vendibles de un Item; las opciones estandarizan atributos utilizados para generar o identificar variaciones; los modificadores representan selecciones realizadas durante la venta. Ninguna elección del origen puede asignarse de forma segura sin comprender antes su función comercial.
Señales tempranas
| Funcionamiento de origen | Señal de advertencia en Square |
|---|---|
| Talla o color controlan SKU y stock. | Se representan únicamente como modificadores. |
| Una elección de menú añade un extra opcional. | Se expande en variaciones de inventario independientes. |
| Importan imágenes o precios específicos de variantes. | Cada selección hereda los mismos valores del artículo principal. |
| Existen elecciones obligatorias en la tienda de origen. | Square permite vender el Item sin la elección prevista. |
Prevención
Clasifica cada opción del origen por función: identidad, inventario, precio, procesamiento, presentación o personalización durante la venta. Relaciona las elecciones que controlan identidad e inventario con Item Variations o opciones de Item. Relaciona los añadidos opcionales de venta con listas de modificadores únicamente cuando ese comportamiento refleje la regla empresarial.
Conserva SKU e identificadores externos en el nivel donde los sistemas dependientes esperan encontrarlos. Decide también si los nombres de variaciones deben generarse a partir de valores de opción estandarizados o conservarse como nombres explícitos.
Ejemplo de recomendación
Para un Product de ropa configurable, compara una combinación de origen como talla M, color negro y bordado con su representación en Square. Talla y color pueden pertenecer a la variación, mientras que el bordado puede pertenecer a un modificador si se elige durante la venta y no controla stock independiente.
Condición de aprobación
Las familias representativas de Products siguen siendo fáciles de localizar y vender, y cada elección conserva el significado previsto de SKU, precio, imagen, inventario, selección obligatoria y línea de Order.
Problema 3: reducir inventario por ubicación a una sola cantidad
Qué sale mal
La tienda de origen muestra un total único de stock o cantidades separadas por almacén, pero la migración las reduce a una cantidad de Square sin definir propiedad por ubicación. Los Products aparecen disponibles en la tienda equivocada, la disponibilidad online no coincide con la recogida prevista o el equipo no puede conciliar el inventario inicial migrado con los ajustes posteriores.
Square controla inventario para Item Variations en ubicaciones y puede representar distintos estados. Una cantidad sin su ubicación y estado constituye información operativa incompleta.
Señales tempranas
| Señal de advertencia | Riesgo |
|---|---|
| La exportación del origen contiene un total, pero el negocio opera varias ubicaciones. | El stock se asigna arbitrariamente o se duplica. |
| La recogida y venta en tienda comparten inventario, pero las reglas de ubicación no están documentadas. | Los compradores ven disponibilidad que el equipo no puede atender. |
| paquetes o ingredientes se tratan como stock ordinario de variación. | La cantidad mostrada no representa la disponibilidad de componentes. |
| El inventario inicial se carga sin una marca temporal de propiedad. | Los ajustes posteriores no pueden conciliarse con el saldo migrado. |
Prevención
Define la granularidad del inventario antes de migrar: variación de Product, ubicación y estado necesario. Decide qué sistema controla el saldo inicial y cuál será la autoridad después del cambio. Cuando el origen no aporta cantidades por ubicación, documenta el método de asignación en lugar de copiar silenciosamente el mismo total en todas las ubicaciones.
Separa el inventario que Square puede controlar directamente de la disponibilidad de paquetes, componentes o integraciones que necesita otro responsable.
Ejemplo de recomendación
Un negocio con dos tiendas físicas y Square Online debe seleccionar varios SKU sensibles al stock y documentar el recuento inicial esperado por ubicación, la disponibilidad online y el comportamiento de recogida. La comparación debe incluir una variación agotada y un Product disponible solo en una ubicación.
Condición de aprobación
Cada variación revisada tiene un saldo inicial por ubicación explicable, se conoce la autoridad de inventario y la disponibilidad online o para recogida coincide con las reglas aprobadas de ubicación.
Problema 4: conservar registros del Catalog sin conservar visibilidad por canal
Qué sale mal
Items, Categories, imágenes, impuestos y descuentos están presentes en el catálogo de Square, pero no aparecen en el canal previsto. Los Products pueden venderse en Point of Sale y estar ausentes online, aparecer online en la ubicación equivocada o agruparse en Categories que ya no ayudan al Customer a descubrirlos.
El catálogo es infraestructura compartida; no demuestra que cada Item esté publicado u organizado correctamente en cada superficie de venta. La visibilidad por canal, tipo de Item, asignación de imágenes, pertenencia a Categories y presentación online siguen necesitando relaciones explícitas.
Señales tempranas
| Resultado del Catalog | Fallo oculto |
|---|---|
| El Item aparece en Dashboard. | Puede seguir sin estar disponible en Square Online o en la ubicación prevista. |
| Las Categories se migraron por nombre. | La pertenencia de Products y la navegación de compradores pueden no coincidir. |
| Las imágenes existen en el catálogo. | La imagen principal o específica de variación puede ser incorrecta online. |
| Descuentos e impuestos existen como objetos. | Su aplicabilidad puede no reflejar la regla comercial del origen. |
Prevención
Crea una matriz de visibilidad por canal para Products representativos. Registra dónde debe venderse cada Product, si necesita imágenes y contenido online, qué rutas de Category importan y qué reglas de ubicación o procesamiento afectan a su publicación.
Trata la migración de Categories como una decisión de descubrimiento, no como una transferencia de etiquetas. Consolida rutas obsoletas, conserva agrupaciones comercialmente importantes e identifica la navegación online que debe configurarse fuera de la migración de registros.
Ejemplo de recomendación
Para una familia estacional de Products, compara la biblioteca de artículos, disponibilidad en Point of Sale, página de Product en Square Online, pertenencia a Category, orden de imágenes y ubicación de recogida. El Product no debe aprobarse únicamente porque exista su objeto de catálogo.
Condición de aprobación
Los Products representativos están disponibles solo en los canales y ubicaciones previstos, con pertenencia a Categories, imágenes, estado de publicación y aplicabilidad comercial correctos para cada recorrido del comprador.
Problema 5: migrar Customers sin su contexto de grupos o datos personalizados
Qué sale mal
Los perfiles de Customer se migran como nombres, correos, teléfonos y direcciones, pero se omite el significado empresarial que aportaban grupos, atributos personalizados, IDs de CRM, campos de consentimiento o notas del equipo. El equipo puede localizar al Customer, pero no reconocer la relación, segmentación o vínculo con sistemas externos que hacía útil el registro.
Square puede gestionar perfiles de Customer, pertenencia a grupos y atributos personalizados, pero son relaciones diferentes. Un atributo personalizado no forma parte automáticamente de un registro básico de Customer y un segmento de origen puede no tener un destino con significado en Square.
Señales tempranas
| Señal de Customer | Riesgo si se ignora |
|---|---|
| Los grupos controlan promociones o tratamiento del equipo. | Los Customers dejan de distinguirse después de la migración. |
| Los IDs externos de CRM están guardados en campos personalizados. | La sincronización crea duplicados o pierde el vínculo. |
| Consentimiento y preferencias de comunicación están mezclados con datos del perfil. | El tratamiento de marketing deja de ser fiable. |
| Existen perfiles duplicados entre canales POS y online. | El historial de compras y la identidad siguen fragmentados. |
Prevención
Clasifica los datos de Customer como identidad, contacto, pertenencia a grupos, atributos personalizados, consentimiento e identificadores externos. Define qué valores pertenecen a Customer Directory, cuáles a grupos de Customer, cuáles necesitan definiciones de atributos personalizados y cuáles siguen bajo otro sistema.
Establece una regla para duplicados antes de importar. Utiliza identificadores estables cuando existan y evita fusionar Customers únicamente porque nombres o correos parezcan similares.
Ejemplo de recomendación
Selecciona un Customer habitual, otro perteneciente a un grupo objetivo, un perfil con identificador ERP o CRM y un probable duplicado. Confirma cómo reconocerán cada perfil el equipo y las integraciones después de la migración.
Condición de aprobación
Los Customers representativos conservan el contexto de identidad, grupo, datos personalizados y sistemas externos necesario para soporte y sincronización, sin resultados de duplicación o fusión no explicados.
Problema 6: tratar Orders históricos como configuración activa de pagos y procesamiento
Qué sale mal
Los Orders históricos se importan o conservan como referencia y el equipo asume que pagos, reembolsos, recogida, entrega, envío, impuestos o flujos del personal ya están configurados. Los datos históricos y la configuración operativa activa pertenecen a capas diferentes.
Los Orders de Square pueden contener líneas, referencias de Customer, impuestos, descuentos, devoluciones, reembolsos y detalles de procesamiento. Un registro histórico migrado puede conservar parte de esta evidencia, pero no activa un método de pago, crea un flujo activo de procesamiento ni reproduce todos los estados del origen.
Señales tempranas
| Atajo de revisión de Order | Consecuencia |
|---|---|
| Solo se comprueban número, fecha y total del Order. | El contexto de líneas, descuentos, reembolsos y procesamiento puede quedar ilegible. |
| Las etiquetas de pago del origen se tratan como configuración activa. | El equipo espera comportamiento de proceso de compra que nunca se configuró. |
| Los reembolsos se representan únicamente como totales negativos. | La evidencia de devoluciones y pagos se vuelve difícil de explicar. |
| Los estados personalizados se copian sin una regla de propiedad. | El equipo no puede distinguir si el estado es histórico, activo u obsoleto. |
Prevención
Define la finalidad de los Orders históricos: atención al Customer, referencia financiera, historial de procesamiento o conciliación. Conserva la evidencia necesaria para esa finalidad, incluidas líneas, totales, contexto de impuestos y descuentos, relación con Customer, reembolsos o devoluciones y detalles relevantes de procesamiento.
Asigna por separado responsables de pagos activos, creación de Orders, procesamiento, operaciones de reembolso y permisos del equipo.
Ejemplo de recomendación
Revisa un Order completado en tienda, un Order online con envío o recogida, un Order con descuento y otro reembolsado o cambiado. Confirma que el equipo puede explicar la transacción sin suponer que el registro histórico controla los ajustes activos de Square.
Condición de aprobación
Los Orders históricos son legibles para la finalidad empresarial aprobada y cada flujo activo de pagos, procesamiento y reembolsos tiene un responsable de configuración independiente.
Problema 7: perder el significado de impuestos, descuentos y precios aplicados durante la venta
Qué sale mal
Los registros de impuestos y descuentos se migran como etiquetas o valores y se pierde su alcance o lógica de aplicación. Un impuesto puede pertenecer a Products o ubicaciones específicas. Un descuento puede ser automático, aplicarse a una línea o al Order completo, o depender de otra regla. Si el destino recibe solo el nombre y el importe, la venta puede calcularse incorrectamente.
Square modela impuestos y descuentos como objetos del catálogo y aplica ajustes de precios mediante Orders y relaciones del catálogo. Por tanto, la regla de origen debe traducirse a una relación comercial compatible en Square o reconstruirse de forma intencional en otro sistema.
Señales tempranas
| Regla comercial | Señal temprana |
|---|---|
| Tratamiento fiscal específico de Product | Todos los Products heredan el mismo impuesto después de la migración. |
| Descuento automático | El descuento existe pero nunca se aplica durante la venta. |
| Precio específico por Customer o canal | El modelo de destino solo tiene un precio base global. |
| Ajuste de precio mediante modificador | La línea del Order no explica el cargo añadido. |
Prevención
Inventaría las reglas que modifican el valor de venta y clasifica cada una por detonante, alcance, cálculo y responsable. Conserva la evidencia del origen necesaria para comparar totales esperados, pero no asumas que los valores históricos recrean la lógica activa.
Cuando una regla no pueda representarse directamente, define un responsable de configuración, aplicación o integración en el destino y documenta cómo se calculará el precio final.
Ejemplo de recomendación
Utiliza una cesta representativa con un Product sujeto a impuestos, otro con descuento y un Item con modificador de precio. Compara los ajustes esperados a nivel de línea y Order con su representación en Square.
Condición de aprobación
Las reglas comerciales aprobadas generan precios y totales explicables en ventas representativas, sin reglas conservadas únicamente como etiquetas que nunca se utilizan.
Problema 8: dejar para el final las rutas y redirecciones de Square Online
Qué sale mal
La migración del catálogo se aprueba antes de planificar páginas de Square Online, URL de Products, rutas de Categories, dominios y redirecciones. El nuevo sitio se lanza con enlaces entrantes rotos, destinos de redirección irrelevantes o rutas importantes de contenido ausentes aunque los Products estén disponibles.
Square Online admite redirecciones de URL, pero toda redirección sigue necesitando un destino con sentido. Redirigir cada ruta antigua a la página de inicio no conserva la intención del comprador ni la relevancia del contenido.
Señales tempranas
| Condición de ruta | Prioridad de prevención |
|---|---|
| Cambia una URL de Product con mucho tráfico. | Relaciónala con la página activa equivalente del Product. |
| Se consolida una Category antigua. | Selecciona la Category o página de destino activa más cercana. |
| Cambian tanto el dominio como la plataforma. | Confirma qué redirecciones siguen siendo técnicamente posibles. |
| Imágenes, documentos o rutas no compatibles son importantes. | Planifica un tratamiento independiente; no asumas que las redirecciones de páginas las cubren. |
Prevención
Construye el inventario de rutas mientras todavía se toman decisiones sobre catálogo y contenido. Clasifica cada ruta importante como conservada, redirigida, consolidada, reconstruida o retirada. Prioriza Products, Categories, campañas, páginas de políticas y contenido enlazado externamente.
Verifica que las páginas de destino estén publicadas y sean relevantes antes de activar redirecciones.
Ejemplo de recomendación
Para una Category retirada con varias páginas de Products bien posicionadas, asigna cada Product a su sustituto o sucesor y la Category a la colección activa o guía de compra más cercana. No utilices un único destino genérico para todas las rutas.
Condición de aprobación
Las URL prioritarias del origen resuelven a destinos relevantes y publicados de Square Online, y ninguna ruta importante depende de una suposición de redirección no documentada o técnicamente no compatible.
Problema 9: ocultar datos propiedad de integraciones dentro de campos ordinarios
Qué sale mal
IDs externos, metadatos de aplicaciones, atributos personalizados, marcas temporales de sincronización o indicadores operativos se copian a campos genéricos de Square sin definir quién los lee o mantiene. Los valores pueden ser visibles mediante API pero no para el equipo en Point of Sale, o pueden ser sobrescritos por una integración después del cambio.
Square admite atributos personalizados para objetos del Catalog y Customers, pero la visibilidad difiere según objeto e interfaz. Guardar un valor no es suficiente: debe conocerse el consumidor que continuará y la ruta de acceso.
Señales tempranas
| Señal de datos | Fallo probable |
|---|---|
| Un valor se migra porque quizá resulte útil en el futuro. | Ningún sistema o persona lo consume realmente. |
| El equipo necesita el valor en Point of Sale. | Solo está guardado en un atributo personalizado visible por API. |
| Un ERP volverá a sincronizar el campo. | El valor migrado se sobrescribe o crea un conflicto. |
| Los IDs externos se trasladan a otro nivel de registro. | Se rompe la relación con Product, variación, Customer u Order. |
Prevención
Crea un registro de propiedad de integraciones para cada valor no estándar. Registra responsable de origen, registro de destino, campo o atributo personalizado de destino, consumidor que continuará, autoridad de escritura y requisito de visibilidad. Excluye valores obsoletos en lugar de conservarlos sin propósito.
Prueba que equipo, informes, aplicaciones e integraciones puedan acceder al valor mediante la interfaz que realmente utilizan.
Ejemplo de recomendación
Para un identificador ERP a nivel de variación, confirma que sigue asociado a la variación vendible y no al Item principal, y verifica que la integración ERP lee exactamente esa ubicación después del cambio.
Condición de aprobación
Cada valor personalizado o propiedad de una integración que se conserve tiene un consumidor identificado, una ubicación estable en el destino, la visibilidad correcta para equipo o API y una propiedad de escritura inequívoca cuando empieza la sincronización.
Mapa de prevención entre problemas
| Área de control | Problemas controlados | Resultado necesario |
|---|---|---|
| Modelo operativo del destino | 1, 4, 6 | Los productos de Square, canales, ubicaciones y responsables de configuración activa son explícitos. |
| Mapa de relaciones del Catalog | 2, 3, 4, 7 | Items, variaciones, modificadores, inventario, Categories, impuestos y descuentos conservan su función. |
| Registro de identidad e integraciones | 5, 9 | El contexto de Customer y sistemas externos sigue siendo utilizable y gobernado. |
| Modelo de evidencia de Orders | 6, 7 | Las transacciones históricas siguen siendo explicables sin confundirse con configuración activa. |
| Inventario de rutas | 4, 8 | El descubrimiento online y las rutas entrantes importantes siguen siendo intencionales. |
Conclusión
La calidad de una migración hacia Square depende de conservar relaciones operativas, no simplemente de importar tipos de registro conocidos. El diseño de la biblioteca de artículos afecta a la venta, el inventario por ubicación afecta a la disponibilidad, el contexto de Customer afecta al servicio, la evidencia de Orders afecta al soporte y las rutas de Square Online afectan al descubrimiento. Cuando cada relación tiene un responsable definido en el destino y una condición concreta de aprobación, los problemas recurrentes se vuelven visibles y se pueden prevenir antes de alterar la operación diaria.
Preguntas frecuentes
¿Por qué Square es diferente de una migración convencional de tienda online?
Square puede conectar el mismo catálogo con Point of Sale, ubicaciones, inventario, Customers, Orders, pagos y venta online. Un registro que parece correcto en un área puede seguir incompleto en otra, por lo que el modelo operativo de destino debe ser explícito.
¿Las variantes del origen siempre deben convertirse en Item Variations de Square?
No automáticamente. Una elección que controla SKU, precio, imagen o inventario suele pertenecer a la estructura de variaciones. Un añadido opcional elegido durante la venta puede encajar como modificador. La función comercial debe determinar la capa de destino.
¿Puede copiarse un mismo total de inventario a todas las ubicaciones de Square?
Solo cuando esa duplicación refleje la regla operativa real. Los negocios con varias ubicaciones normalmente necesitan una asignación aprobada o datos de origen por ubicación. Copiar el mismo total a todas las ubicaciones puede inflar el stock disponible.
¿Los Orders migrados configuran pagos y procesamiento en Square?
No. Los Orders históricos pueden conservar evidencia de transacciones, pero el procesamiento activo de pagos, procesamiento de pedidos, reembolsos y flujos del equipo requiere configuración y responsables independientes en Square.
¿Cómo deben tratarse los campos personalizados en Square?
Conserva únicamente valores que tengan un consumidor que continuará activo. Decide si cada uno pertenece a un campo nativo, grupo, atributo personalizado, aplicación o sistema externo y confirma que las personas o integraciones que lo necesitan pueden acceder al valor.
¿Qué demuestra que la gestión de rutas de Square Online está preparada?
Las URL prioritarias del origen deben resolver a destinos publicados y relevantes, tratando por separado las rutas de Product, Category, campaña y contenido en lugar de redirigirlas indiscriminadamente.