Si AmeriCommerce se selecciona como plataforma de destino, la preparación debe hacer comprensible el funcionamiento de la tienda de origen antes de cerrar la configuración de la migración. Una instalación puede combinar varias Stores, restricciones mediante catálogos activos, Customer Types, variantes, Product Groups, kits, precios avanzados, campos personalizados, contenido y sistemas externos. Una exportación muestra qué registros existen, pero no explica qué Store controla cada registro, qué regla de comprador modifica su funcionamiento ni qué identificador debe seguir disponible para otro sistema.
El objetivo de la preparación es convertir esas relaciones en evidencia controlada de la tienda de origen. Cada área principal debe indicar qué acción debe completarse, quién es responsable de la respuesta, qué evidencia debe aportarse y qué condición permite considerar el área preparada. Así, el estado de origen queda explícito antes de comenzar la configuración de la migración.
Establecer el acceso y definir el límite operativo de AmeriCommerce
Comience documentando la cuenta exacta de AmeriCommerce y todas las Stores incluidas en el alcance. Registre el acceso administrativo, los identificadores de Store, dominios activos, monedas, idiomas, contexto fiscal, responsable actual del tema y personal encargado del catálogo, Customers, Orders, marketing e integraciones. Cuando varias Stores compartan datos o utilicen catálogos activos diferentes, la preparación debe mostrar qué configuraciones y registros son globales y cuáles pertenecen a una Store concreta.
Las exportaciones de AmeriCommerce pueden filtrarse por Store y configurarse con columnas seleccionadas. Conserve los criterios utilizados para cada exportación, de modo que posteriormente cada archivo pueda vincularse con una Store, fecha y conjunto de campos concretos. No suponga que una exportación combinada conserva automáticamente la propiedad de los registros por Store.
| Acción | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Enumerar todas las Stores y dominios incluidos | Administrador de comercio | Lista de Stores, identificadores, dominios, estado y finalidad comercial | Cada Store incluida tiene una función y un responsable definidos. |
| Confirmar el acceso compatible en origen | Responsable de acceso | Registro del acceso administrativo, permisos de exportación y contacto técnico | Los registros necesarios pueden obtenerse desde la cuenta correcta. |
| Documentar el funcionamiento compartido y específico de cada Store | Responsable de plataforma | Comparación entre Stores que cubra catálogos, precios, contenido y configuraciones | Los datos compartidos pueden distinguirse de los específicos de cada Store. |
| Fijar los criterios de exportación | Responsable de datos | Nombre de exportación, filtro de Store, fecha, columnas seleccionadas y hash del archivo | Cada archivo de origen puede reproducirse y explicarse. |
| Iniciar un registro de cambios en origen | Responsable del proyecto | Registro fechado de cambios en catálogo, Customers, Orders, URL e integraciones | Los cambios posteriores a la captura de evidencia no se perderán. |
Preparar Products, variantes, grupos, kits y relaciones de precio
Los Products de AmeriCommerce pueden utilizar variantes, inventario de variantes, Product Groups, kits, precios avanzados, reglas por cantidad, precios según Customer Type y campos personalizados. Estas estructuras no deben reducirse a una sola fila de Product durante la preparación. El equipo debe identificar qué registros representan opciones vendibles, cuáles representan una presentación agrupada y cuáles dependen de una relación de precios o inventario.
Cree un inventario de Products que incluya Product ID, número de artículo o SKU, estado, visibilidad por Store, ubicación en catálogos activos, Categories, fabricante, precio base, clase fiscal, cantidad, peso, imágenes, contenido, variantes, relaciones de Product Group, componentes de kits, reglas de precio e identificadores externos. Seleccione ejemplos de cada patrón de Product que sea materialmente distinto.
| Patrón de origen | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Variantes de Product | Registrar Variant Groups, valores, orden de presentación, obligatoriedad, efectos en el precio y asignación al Product | Exportación de variantes y páginas representativas de Products | El vocabulario de selección y la propiedad del Product están completos. |
| Inventario de variantes | Registrar SKU, cantidad, precio, imagen, peso y estado a nivel de combinación cuando se utilicen | Matriz de combinaciones y muestra de stock | Las combinaciones vendibles gestionadas de forma independiente son visibles. |
| Product Groups | Registrar Products principal/secundarios, tipo de grupo, posibilidad de venta, precios, inventario y tratamiento de envío | Exportación de relaciones del grupo y capturas de pantalla | El agrupamiento no se confunde con una variante simple. |
| Kits u ofertas ensambladas | Registrar Products componentes, cantidades, funcionamiento del precio, supuestos de stock y notas de procesamiento de pedidos | Lista de kits y ejemplos de componentes | El significado de los componentes y su responsabilidad operativa están documentados. |
| Precios avanzados o según Customer Type | Registrar alcance del comprador, umbral de cantidad, fechas, fórmula o importe y Products afectados | Matriz de reglas de precios | Los precios condicionales son explícitos y no se infieren a partir de etiquetas. |
| Campos personalizados de Product | Clasificar cada campo como descriptivo, operativo, controlado por una integración u obsoleto | Diccionario de campos con valores de ejemplo | Los campos importantes para el negocio tienen un tratamiento y responsable definidos. |
No combine nombres de opciones o reglas de precio parecidos únicamente para simplificar el origen. Dos etiquetas que parecen equivalentes pueden diferir por Store, Customer Type, responsabilidad sobre el stock o uso en sistemas externos.
Documentar Stores, catálogos activos, Categories y mecanismos de descubrimiento
AmeriCommerce puede restringir por Store el catálogo visible mediante la configuración de catálogos activos. Los Customer Types también pueden afectar la visibilidad de Products, el contenido, las redirecciones, los descuentos y el tratamiento del envío. Por tanto, la preparación necesita algo más que un árbol de Categories: requiere un mapa de visibilidad que muestre qué compradores pueden descubrir qué Products en cada Store.
Prepare la jerarquía de Categories con identificadores, elemento superior, estado, asociación a Store, estado dentro del catálogo activo, Products asignados, contenido, imágenes, orden y URL importantes. Registre los menús de navegación, landing pages, rutas de fabricantes, mecanismos de descubrimiento basados en atributos y enlaces internos por separado de los registros de Categories que los sustentan.
| Área de descubrimiento | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Catálogo activo por Store | Administrador de plataforma | Capturas o exportaciones del catálogo activo de cada Store | El límite de Categories visible en cada Store está documentado. |
| Jerarquía de Categories | Responsable del catálogo | Exportación padre-hijo y lista de Categories que se conservarán | Cada Category conservada tiene un elemento superior y finalidad conocidos. |
| Ubicación de Products | Responsable de merchandising | Evidencia de asignación Product-to-Category y por Store | La ubicación compartida y las restricciones por Store son visibles. |
| Visibilidad según Customer Type | Responsable B2B o de cuentas | Ejemplos de Products y Categories restringidos | Las reglas de acceso de compradores están vinculadas a registros reales. |
| Menús y landing pages | Responsable de la tienda online | Mapa de navegación, capturas y rutas enlazadas | Las rutas de presentación se distinguen de la estructura del catálogo. |
| URL prioritarias | Responsable de SEO | Lista de rutas de Products, Categories, contenido y campañas | Cada ruta de alto valor tiene una decisión documentada. |
Preparar Customers, Customer Types, cuentas y direcciones
Los Customer Types de AmeriCommerce pueden influir en precios, descuentos, redirecciones al iniciar sesión, recompensas, contenido personalizado, métodos de envío y Products ocultos. Por ello, un Customer Type debe prepararse como una relación de reglas de negocio y no solo como un nombre de grupo. Registre qué Customers activos pertenecen a cada tipo y qué modifica ese tipo.
Prepare los Customers con identificadores, nombres, direcciones de correo electrónico, estado de acceso, direcciones de facturación y envío, datos de empresa, Customer Type, situación fiscal, estado de suscripción o comunicación, campos personalizados, responsable comercial o de cuenta e identificadores externos. Identifique correos duplicados, direcciones compartidas por empresas, cuentas inactivas y registros cuyo Customer Type ya no refleje el uso comercial actual.
| Área de Customer | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Identidad | Resolver o documentar patrones de correo duplicado y compartido | Registro de excepciones de Customers | Las excepciones de identidad tienen responsable y tratamiento. |
| Customer Types | Registrar pertenencia y todas las reglas afectadas de precio, visibilidad, redirección, envío o contenido | Matriz de reglas de Customer Types | Cada tipo tiene un significado comercial documentado. |
| Direcciones | Separar direcciones reutilizables de Customer de las capturadas al realizar cada Order | Ejemplos de direcciones de Customer y Order | Los datos actuales de cuenta no se mezclan con el historial de transacciones. |
| Contexto fiscal y de exención | Registrar estado, responsable de la evidencia y Customers afectados | Lista de muestras de estado fiscal | El tratamiento fiscal especial no se reduce a una simple etiqueta. |
| Campos personalizados e identificadores externos | Identificar sistema responsable y uso en procesos posteriores | Diccionario de campos y referencias de integraciones | Los identificadores operativos siguen siendo rastreables. |
Preparar Orders, estados, totales y contexto histórico
La preparación de Orders debe conservar la evidencia que necesitan atención al cliente, finanzas, procesamiento de pedidos y equipos de cuentas. Seleccione Orders de cada Store e incluya ejemplos con variantes, Product Groups o kits, precios según Customer Type, descuentos, diferencias fiscales, envíos divididos o poco habituales, reembolsos, cancelaciones, ajustes manuales, notas y referencias externas.
Conserve los criterios de exportación de Orders e incluya los campos necesarios para interpretar líneas, direcciones, estados, etiquetas de pago y envío, impuestos, descuentos, cargos y totales. Las etiquetas históricas deben documentarse como contexto de origen; no deben tratarse como instrucciones para configurar los métodos actuales de pago o envío en la plataforma de destino.
| Área de Order | Acción | Evidencia | Condición de preparación |
|---|---|---|---|
| Propiedad de Store | Incluir el identificador de Store en la evidencia del Order | Lista de muestra de Orders entre Stores | Cada muestra puede vincularse con la Store correcta. |
| Historial de estados | Registrar etiquetas, secuencia, significado para el personal y visibilidad para el Customer | Diccionario de estados y Orders representativos | Los estados históricos pueden interpretarse de forma coherente. |
| Detalle de líneas | Incluir variantes seleccionadas, contexto de kit o grupo, cantidad, SKU y precio | Muestras de líneas de Order | La configuración comprada sigue siendo comprensible. |
| Totales y ajustes | Identificar impuestos, envío, descuentos, cargos, créditos, reembolsos y líneas manuales | Inventario de componentes del total | Los ajustes materiales tienen un significado de origen conocido. |
| Referencias externas | Registrar identificadores de ERP, contabilidad, CRM, procesamiento de pedidos o marketplaces | Orders dependientes de integraciones | Los requisitos de consulta en sistemas posteriores están documentados. |
No modifique Orders históricos únicamente para uniformarlos. Registre las anomalías por separado cuando ayuden a explicar la transacción original.
Inventariar contenido, integraciones, automatizaciones y datos personalizados
Prepare el contenido y las dependencias como inventarios separados. La evidencia de contenido debe incluir páginas, blog o contenido educativo, formularios, imágenes, descargas, metadatos, requisitos de canonical, enlaces internos y redirecciones. La evidencia de dependencias debe incluir ERP, contabilidad, CRM, impuestos, envío, inventario, procesamiento de pedidos, marketplaces, analítica, correo electrónico y sistemas de información de Products.
Para cada integración o proceso automatizado, registre el sistema responsable, dirección del flujo de datos, programación o desencadenante, identificadores utilizados, campos leídos o escritos y lo que debe ocurrir durante el periodo de migración. Los campos personalizados o scripts deben clasificarse según su finalidad comercial y no recopilarse sin interpretación.
| Dependencia | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| ERP o contabilidad | Responsable de finanzas o sistemas | Identificadores de artículos, Customers, Orders, facturas e impuestos | Se conocen las claves necesarias para las consultas. |
| Inventario o procesamiento de pedidos | Responsable de operaciones | Códigos de almacén, IDs de proveedores, autoridad sobre existencias y referencias de envíos | La propiedad del stock y del procesamiento de pedidos está explícita. |
| CRM o proceso comercial | Responsable de sistemas de ventas | Campos de empresa, contacto, gestor de cuenta y contrato | Las relaciones de cuenta están documentadas. |
| Marketing y analítica | Responsable de marketing | Segmentos, rutas de campañas, referencias de seguimiento y campos de consentimiento | Los datos de marketing tienen una decisión clara de inclusión. |
| Funcionamiento personalizado en origen | Desarrollador o agencia | Scripts, campos personalizados, tablas ocultas, tareas programadas y procedimientos manuales | El funcionamiento no estándar tiene un responsable y un tratamiento definidos. |
Preparar exportaciones, archivos multimedia, copias de seguridad y control de cambios
Cree un archivo de evidencia fechado y organizado, no una colección dispersa de archivos. Guarde las exportaciones de Products, Customers, Orders, Categories, contenido, precios, campos personalizados e integraciones junto con archivos multimedia, capturas de pantalla, criterios de exportación y notas explicativas. Mantenga intactos los archivos originales y realice cualquier limpieza o análisis sobre copias de trabajo.
| Conjunto de evidencia | Contenido requerido | Condición de preparación |
|---|---|---|
| Exportaciones de datos | Archivos de origen, criterios de exportación, filtros de Store, fecha, correspondencia de campos y checksum | Los archivos están completos y se puede identificar su procedencia. |
| Archivo multimedia | Recursos de Product, Category, contenido, documentos y archivos descargables | Los archivos originales pueden vincularse con los registros de origen. |
| Evidencia de configuración | Capturas o informes de Store, catálogo activo, Customer Type, precios, estados e impuestos | Las reglas que no aparecen en exportaciones ordinarias están documentadas. |
| Nota de copia de seguridad y recuperación | Copias disponibles de la plataforma, exportaciones descargadas, archivo multimedia y contactos de la cuenta | La evidencia de origen puede recuperarse si surgen dudas. |
| Registro de cambios | Products, Customers, Orders, URL, reglas e integraciones nuevos o modificados después de la captura | Los cambios posteriores en origen pueden conciliarse. |
Seleccionar registros representativos para las pruebas de migración
Seleccione deliberadamente registros representativos para las pruebas de migración. La muestra debe contener tanto registros ordinarios como estructuras con mayor probabilidad de revelar un problema de alcance o correspondencia. En AmeriCommerce, normalmente incluye registros de diferentes Stores, catálogos activos, Customer Types, patrones de Product y contextos de integración.
| Grupo de muestra | Incluir | Finalidad de preparación |
|---|---|---|
| Products | Product simple, Product con variantes, Product con inventario por variante, Product Group, kit, Product restringido y Product con precios avanzados | Exponer relaciones distintas de catálogo y precio. |
| Customers | Comprador predeterminado, Customer Type especial, cuenta exenta de impuestos, empresa o cuenta gestionada y excepción de correo duplicado | Representar diferencias de identidad y reglas de comprador. |
| Orders | Diferentes Stores, estados, descuentos, casos fiscales, reembolsos, líneas de grupos o kits y referencias externas | Conservar el contexto operativo histórico. |
| Contenido y URL | Rutas prioritarias de Products, Categories, páginas, campañas y redirecciones | Preparar decisiones de rutas y contenido. |
| Integraciones | Registros de Product, Customer y Order que contengan IDs externos | Confirmar que la evidencia de origen necesaria está incluida. |
Para cada muestra, redacte una breve expectativa de origen que describa las relaciones, campos, archivos vinculados e identificadores que hacen que el registro sea representativo.
Completar la revisión de preparación para AmeriCommerce
La preparación está completa cuando la evidencia de origen permite responder a las preguntas que determinan el alcance de la migración. El equipo debe poder identificar cada Store, explicar las reglas de catálogos activos y Customer Types, distinguir las estructuras de Products, interpretar Orders históricos, localizar archivos multimedia y contenido, y nombrar al responsable de cada integración relevante.
| Revisión final | Condición de preparación |
|---|---|
| Alcance de Stores | Cada Store incluida y cada límite de datos compartidos están documentados. |
| Catálogo | Las estructuras de Products, reglas de precio, visibilidad y Categories están representadas mediante evidencia. |
| Customers | Se comprenden Customer Types, excepciones de identidad, direcciones, contexto fiscal e IDs externos. |
| Orders | Pueden interpretarse la Store propietaria, los estados, líneas, totales y referencias externas. |
| Contenido y URL | Se han registrado páginas prioritarias, archivos multimedia, metadatos y decisiones sobre rutas. |
| Dependencias | Integraciones, automatizaciones y datos personalizados tienen responsables y tratamientos definidos. |
| Entradas | Están disponibles exportaciones, archivos multimedia, criterios, checksums, copias de seguridad y registro de cambios. |
| Muestras | Los registros representativos cubren patrones ordinarios y complejos de la tienda de origen. |
Conclusión
La preparación para una migración hacia AmeriCommerce debe revelar cómo se relacionan Stores, catálogos activos, Customer Types, estructuras de Products, precios, Orders, contenido y sistemas externos. El mejor paquete de preparación no es la exportación más grande, sino el conjunto de evidencia que conserva la propiedad y el significado de esas relaciones.
Cuando el acceso, las exportaciones, las reglas de negocio, las muestras representativas y el control de cambios están completos, la configuración de la migración puede partir de información de origen documentada en lugar de suposiciones.
Preguntas frecuentes
¿Deben combinarse las exportaciones de AmeriCommerce de todas las Stores?
Solo cuando la Store propietaria siga siendo explícita. Mantenga con cada archivo el filtro de Store, los criterios de exportación y el identificador de Store para que todavía puedan distinguirse los registros compartidos de los específicos.
¿Por qué deben documentarse los Customer Types por separado de los Customers?
Porque los Customer Types pueden afectar precios, descuentos, contenido, redirecciones, envío y visibilidad de Products. La pertenencia al tipo, por sí sola, no explica la regla que este controla.
¿Qué Products deben priorizarse durante la preparación?
Incluya Products simples, variantes, Products con inventario por variante, Product Groups, kits, Products restringidos, casos de precios avanzados y registros con identificadores externos.
¿Deben eliminarse los Products antiguos o inactivos antes de la migración?
No de forma automática. Clasifíquelos como incluir, excluir, archivar o revisar por el negocio. Eliminarlos primero puede borrar evidencia necesaria para comprender Orders históricos o integraciones.
¿Qué debe conservarse junto con los Orders históricos?
Conserve la Store propietaria, configuración de líneas, estados, direcciones, totales, descuentos, impuestos, etiquetas de pago y envío, notas y referencias externas necesarias para los equipos operativos.
¿Cómo deben tratarse los cambios en origen después de crear las exportaciones?
Mantenga un registro de cambios fechado e identifique al responsable de cada área modificada. El registro debe cubrir cambios de catálogo, Customers, Orders, URL, precios e integraciones que puedan alterar el conjunto de evidencia preparado.