Si Squarespace se selecciona como plataforma de destino, la preparación debe establecer cómo encaja el catálogo comercial dentro del sitio web más amplio antes de ejecutar cualquier migración. Cada Product pertenece a una Store Page, mientras que los Products físicos, de servicio, de tarjeta regalo y descargables tienen comportamientos diferentes para variantes e inventario. Contacts, Orders, Transactions, Pages, Blog Posts, navegación, extensiones y diseño del sitio también siguen siendo familias de registros independientes.
La preparación debe registrar cada acción necesaria junto con su responsable, la evidencia que la respalda y una condición clara para considerarla lista. Esto evita confundir una exportación completa de Products con una Store Page completa, tratar un Contact como si fuera un derecho de suscripción o membresía, o interpretar datos históricos de pago como configuración actual del proceso de compra.
Confirmar el modelo de sitio y Store Pages de Squarespace
Define la relación prevista entre el sitio web, Store Pages, Products, contenido, navegación y sistemas conectados.
| Área de preparación | Decisión que debe registrarse | Responsable | Evidencia de preparación |
|---|---|---|---|
| Estructura del sitio | Dominios, configuración regional, moneda, navegación, Pages, Blog y áreas con comercio habilitado | Responsable del sitio | Mapa del sitio y de rutas |
| Store Pages | Qué Store Page es propietaria de cada familia de Product | Responsable de comercio | Matriz de asignación a Store Pages |
| Tipos de Product | Tratamiento de Products físicos, de servicio, tarjeta regalo y descargables | Responsable de presentación comercial | Inventario por tipo de Product |
| Modelo de clientes | Contacts, suscriptores, donantes, Customers, cuentas y relaciones con CRM externo | Responsable de clientes | Matriz de clasificación de Contacts |
| Modelo de Orders y finanzas | Orders, Orders de suscripción, Transactions, reembolsos y referencias externas | Operaciones/finanzas | Paquete de evidencia histórica |
| Modelo de extensiones | Propiedad de procesamiento de pedidos, suscripciones, membresías, reservas, impuestos, marketing y analítica | Responsable técnico | Registro de dependencias |
El modelo está preparado cuando cada registro importante de comercio y contenido tiene un propietario previsto en Squarespace o en un sistema externo, y cada familia de Product tiene una Store Page asignada.
Preparar accesos, archivos del origen y evidencia recuperable
Reúne:
- acceso de administración al origen y los permisos necesarios del sitio y comercio en Squarespace;
- exportaciones o copias de respaldo fechadas de Products, Customers, Orders, contenido, suscriptores y datos personalizados relevantes;
- imágenes de Product, archivos descargables, recursos multimedia de páginas y archivos de contenido del origen;
- inventarios de Store Pages, navegación, dominios y URL;
- evidencia de extensiones, API, webhooks y sistemas externos;
- identificadores externos de Product, Contact, Order y transacciones;
- un responsable de los cambios en Products, Contacts, Orders, contenido e inventario durante la ventana de migración.
| Elemento de evidencia | Por qué importa | Condición de preparación |
|---|---|---|
| Registro de accesos | Confirma que pueden inspeccionarse las áreas necesarias del origen y destino | Los permisos requeridos están disponibles |
| Archivo fechado del origen | Conserva un estado de referencia recuperable | Las exportaciones se abren correctamente e incluyen fecha |
| Archivo de recursos y ficheros | Protege imágenes de Products, recursos de páginas y descargas | Los archivos pueden relacionarse con los registros que los poseen |
| Inventario de Store Pages | Evita asignar Products a una página comercial incorrecta | Cada familia de Product tiene una Store Page de destino |
| Registro de IDs externos | Protege la continuidad de CRM, procesamiento, contabilidad o mercados en línea | Cada clave está asignada a la entidad correcta |
| Registro de cambios | Captura actualizaciones del origen posteriores a la fecha del archivo | Los registros nuevos o modificados tienen un responsable definido |
Si una aplicación o sistema externo no puede proporcionar una exportación, registra la limitación y el responsable en lugar de omitirla de la preparación.
Preparar tipos de Product, variantes, imágenes e inventario
Squarespace admite Products físicos, de servicio, de tarjeta regalo y descargables. Los Products físicos y de servicio pueden usar variantes; los registros de inventario se aplican a variantes físicas y de servicio y pueden estar controlados o ser ilimitados. Los Download Products tienen relaciones con archivos, pero no utilizan el mismo modelo de variantes.
Prepara ejemplos representativos para:
- cada tipo de Product utilizado por el negocio;
- Products simples y con múltiples variantes;
- atributos de Product como color, talla o peso;
- relaciones de SKU, precio, stock e imagen de variante;
- archivos descargables y expectativas de acceso;
- Products de servicio y cualquier dependencia de reservas o programación externa;
- historial de tarjetas regalo o saldos actuales cuando corresponda;
- paquetes, suscripciones, personalización o funcionamiento perteneciente a extensiones;
- identificadores de ERP, PIM, almacenes, mercados en línea y procesamiento de pedidos.
| Funcionamiento del origen | Decisión de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Product físico o de servicio con variantes | Definir propiedad de Product y variantes | IDs padre/variante, atributos, SKU, precio, stock e imágenes | Cada combinación tiene una variante prevista en Squarespace |
| Download Product | Definir propiedad del Product, archivo y entrega | Archivo del origen, ID de Product, reglas de acceso y ejemplo de Order | La relación con el archivo tiene un propietario identificado |
| Product de servicio con programación | Separar datos del Product de registros de reserva o programación externa | Ejemplos de servicio y cita | La responsabilidad de programación está documentada |
| Existe tarjeta regalo o valor almacenado | Definir propietario histórico y actual | Ejemplos de código/saldo y responsable financiero | El tratamiento del valor almacenado está explícito |
| El funcionamiento del Product pertenece a una extensión | Identificar la extensión o sistema externo que continuará | Evidencia de Product y configuración relacionada | Los registros necesarios aparecen en el registro de dependencias |
El área está preparada cuando cada familia de Product tiene tipo, Store Page, modelo de variantes, tratamiento de inventario, propietario de recursos/archivos y clave externa definidos.
Preparar Store Pages, Categories, navegación y descubrimiento de Products
Cada Product de Squarespace pertenece a una Store Page. Sin embargo, las Categories de Store Page y la navegación son estructuras separadas. La Products API no proporciona las asignaciones de Category de Store Page, por lo que la evidencia del origen sobre agrupación de Products y descubrimiento en la tienda debe prepararse directamente.
Reúne:
- nombres, identificadores, URL y asignaciones de Products de las Store Pages;
- Categories de Product y grupos comerciales utilizados dentro de cada Store Page;
- navegación principal y secundaria, enlaces de pie de página y páginas de entrada;
- filtros, atributos, enlaces internos y colecciones de campañas;
- rutas de compra de alto valor y URL del origen;
- redirecciones y decisiones sobre rutas que se retirarán.
| Área de descubrimiento | Responsable | Evidencia necesaria | Condición de preparación |
|---|---|---|---|
| Store Page | Responsable de comercio/sitio | Lista de Store Pages y asignaciones de Products | Cada Product tiene una Store Page prevista |
| Category o agrupación | Responsable de presentación comercial | Pertenencia de Products y ejemplos de rutas públicas | El significado del grupo está documentado independientemente de la navegación |
| Navegación | Responsable del sitio | Árbol de menús y enlaces de destino | Store Pages, Categories, Pages y enlaces externos tienen ubicaciones previstas |
| Contenido de entrada | Responsable editorial | Contenido de página, recursos, metadatos y referencias a Products | Las rutas de campaña y permanentes tienen propietarios definidos |
| Redirecciones | Responsable SEO | Registro de URL origen/destino | Cada ruta prioritaria tiene un resultado aprobado |
No asumas que migrar Products recrea automáticamente Categories de Store Page, ubicación en menús o recorridos de compra. Estas relaciones necesitan evidencia y responsables propios.
Preparar Contacts, libretas de direcciones, suscriptores e identidad de Customer
La Contacts API de Squarespace representa personas asociadas con el sitio, incluidos Customers, suscriptores de listas de correo, donantes y otros participantes. Contacts puede incluir libretas de direcciones y preferencias de marketing, y el ID de Contact corresponde al ID de Customer referenciado por Orders.
Prepara:
- Customers registrados, compradores invitados, suscriptores, donantes y otros Contacts;
- ejemplos de correos o identidades duplicadas;
- libretas de direcciones de Contact y direcciones de envío predeterminadas;
- preferencias de marketing y evidencia de consentimiento;
- IDs Customer/Contact utilizados por Orders;
- expectativas de acceso a cuentas;
- registros de membresías, suscripciones, fidelización, reservas o CRM pertenecientes a otros sistemas;
- identificadores externos de Contact y Customer.
| Caso de identidad | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Customer con Orders | Operaciones de clientes | ID de Contact, libreta de direcciones y ejemplos de Orders | Las relaciones con Orders usan la identidad Contact prevista |
| Comprador invitado | Operaciones de clientes | Correo, Order e instantáneas de direcciones | El historial como invitado está documentado sin inventar una cuenta |
| Suscriptor o donante | Responsable de marketing/recaudación | Consentimiento, lista y contexto de actividad | La identidad no comercial no se trata por defecto como Customer minorista |
| Participante de membresía o suscripción | Responsable de aplicación | Plan, derecho, renovación o registros de acceso | La relación especializada tiene un propietario que continuará |
| Contact externo de CRM | Responsable de integración | ID CRM y reglas de coincidencia | La identidad entre sistemas está documentada |
La autenticación y el acceso a la cuenta deben prepararse por separado de la identidad Contact. Un registro Contact por sí solo no reproduce una contraseña del origen, un derecho de membresía ni un perfil de aplicación.
Preparar Orders históricos, Orders de suscripción y Transactions
Selecciona Orders que expongan compras únicas y por suscripción, líneas de Product y variantes, IDs de Customer, direcciones, descuentos, impuestos, envíos, procesamiento, reembolsos y referencias externas. Prepara Transactions por separado porque los documentos financieros pueden contener pagos, reembolsos, comisiones y errores de pasarela relacionados con un Order o una donación.
| Área histórica | Evidencia necesaria | Condición de preparación |
|---|---|---|
| Order único | Líneas de Product/variante, Customer, totales, estado y procesamiento | La transacción puede explicarse desde el paquete del origen |
| Order de suscripción | Contexto de suscripción, historial de renovaciones, Products y Customer | La recurrencia histórica se diferencia de la configuración activa de suscripción |
| Pago y reembolso | Documento Transaction, tipo de pago, reembolso y ejemplos de error | El historial financiero está conectado con el Order correcto |
| Procesamiento | Envío, seguimiento, cantidades procesadas e IDs externos | El contexto de entrega anterior es comprensible |
| Order como invitado | Correo, dirección y relación con Order | La identidad invitada sigue separada de una cuenta persistente |
| Order externo | Canal, ERP, ID contable o de soporte | Las claves de conciliación siguen asociadas al Order correcto |
Los Orders y Transactions históricos conservan el comercio pasado. Los procesadores de pago actuales, proceso de compra, impuestos, envíos, descuentos, facturación de suscripciones y configuración de procesamiento siguen siendo preparación separada bajo los equipos responsables.
Preparar contenido, Blog Posts, recursos multimedia, dominios y URL
El comercio en Squarespace suele formar parte de un sitio orientado al contenido. Prepara:
- CMS Pages, Blog Posts, contenido de Store Pages, descripciones de Products y páginas de entrada;
- autores, fechas, etiquetas, categorías, recursos multimedia y enlaces internos;
- inventarios de imágenes, vídeo, archivos descargables y texto alternativo;
- dominio principal, dominios secundarios, configuración regional, moneda y responsabilidad de analítica;
- URL de Product, Store Page, contenido, Blog Post y campañas;
- metadatos, relaciones canónicas, redirecciones y rutas retiradas;
- navegación, pie de página y enlaces de campañas.
| Área de contenido | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| CMS Page | Responsable editorial | Contenido, recursos, metadatos, ruta y contexto de navegación | Cada Page tiene destino y ruta previstos |
| Blog Post | Responsable editorial | Cuerpo, autor/fecha, recursos, etiquetas/categorías y URL | El historial editorial y la ruta están documentados |
| Contenido de Product/Store Page | Responsable de comercio | Descripción, imágenes, agrupación y propiedad de página | El contenido sigue asociado al objeto comercial correcto |
| Dominio y ruta | Responsable SEO/sitio | Registro de dominios y URL | Cada ruta prioritaria tiene un destino o decisión de retirada |
| Dependencia de plantilla o bloque | Diseñador del sitio | Inventario de diseño, bloques, formularios, elementos incrustados o código | El trabajo de presentación está separado del contenido migrado |
Un registro de contenido está preparado cuando se conocen su cuerpo, recursos, ruta, propietario y capa de presentación prevista. Copiar solo el texto no constituye una preparación completa.
Inventariar extensiones, API, webhooks y sistemas externos
Crea un registro de dependencias que abarque procesamiento de pedidos, suscripciones, membresías, reservas, marketing por correo, CRM, contabilidad, impuestos, envíos, reseñas, fidelización, mercados en línea, donaciones, analítica y aplicaciones personalizadas.
Para cada dependencia, registra:
- propósito comercial;
- Products, Contacts, Orders, Transactions, contenido o archivos afectados;
- sistema autoritativo e IDs externos;
- disponibilidad de exportación o API;
- responsable de configuración;
- decisión sobre destino continuado, sustitución o retirada;
- evidencia del origen necesaria antes de configurar el flujo de destino.
El registro está preparado cuando cada campo o registro activo perteneciente a una extensión tiene propietario identificado, entidad padre, consumidor que continuará, identificador duradero y evidencia del origen recuperable sin depender únicamente de lo que se muestra en la tienda.
Seleccionar muestras representativas para la prueba de migración
| Muestra | Propósito de preparación |
|---|---|
| Product físico con variantes | Exponer relaciones entre atributos, SKU, imágenes e inventario |
| Product de servicio | Exponer datos de Product frente a propiedad de programación o servicio externo |
| Download Product | Exponer relaciones Product–archivo y acceso desde Order |
| Product asignado a una Store Page prioritaria | Exponer propiedad de Store Page, Category, navegación y URL |
| Contact con varias direcciones y Orders | Exponer ID Contact, libreta de direcciones y relación Customer |
| Order de suscripción o reembolsado | Exponer recurrencia, Transactions, reembolso y totales |
| CMS Page o Blog Post | Exponer propiedad de contenido, recursos, metadatos y ruta |
| Registro perteneciente a extensión | Exponer la aplicación que continuará y los identificadores externos |
Para cada muestra, registra el ID del origen, URL del origen cuando corresponda, tipo de Product, Store Page, motivo comercial, propietario previsto en Squarespace, exclusiones conocidas, claves externas y revisor responsable.
Completar la verificación de preparación para Squarespace
| Pregunta de preparación | Evidencia necesaria | Condición de preparación |
|---|---|---|
| ¿Los accesos y archivos del origen son recuperables? | Registro de acceso y exportaciones/copias fechadas | Los registros necesarios pueden inspeccionarse independientemente del origen activo |
| ¿Está definida la propiedad del sitio y Store Pages? | Matriz de sitio/Store Pages | Cada familia de Product y área de contenido tiene propietario |
| ¿Están preparados los tipos de Product y variantes? | Inventario de tipos y variantes | Los casos físicos, de servicio, tarjeta regalo y descargables están documentados |
| ¿Están conectados Contacts y Orders? | Ejemplos de relaciones Contact/Order | La identidad, direcciones y transacciones históricas son comprensibles |
| ¿Están inventariados Transactions y extensiones? | Evidencia financiera y registro de dependencias | Reembolsos, pagos y registros de aplicaciones tienen propietarios identificados |
| ¿Están preparados contenido y URL? | Registro de contenido y rutas | Pages, Blog Posts, Store Pages, recursos y redirecciones tienen destinos previstos |
| ¿Se han seleccionado muestras representativas? | Registro de muestras | Se cubre la complejidad de catálogo, identidad, Order, transacción, contenido y extensiones |
| ¿Los elementos sin resolver están controlados? | Registro de decisiones | Cada punto abierto tiene responsable y fecha límite |
La preparación está completa cuando ninguna decisión crítica sobre Store Page, tipo de Product, variante, Contact, Order, Transaction, contenido, ruta o extensión depende de un supuesto sin documentar.
Conclusión
La preparación de una migración hacia Squarespace debe producir un paquete de evidencia del sitio web y del comercio. Los Products deben asignarse a la Store Page y al tipo de Product correctos; las variantes y el inventario deben mantener sus relaciones; Contacts debe seguir separado de programas especializados de cuenta; Orders y Transactions deben conservar contexto histórico; y el contenido o las rutas deben tener propietarios claros.
Cuando estas decisiones están documentadas antes de la prueba de migración representativa, el conjunto de muestras puede reflejar el sitio Squarespace previsto sin confundir registros comerciales importados con diseño del sitio o configuración activa del proceso de compra.
Preguntas frecuentes
¿Qué debe prepararse primero para Squarespace?
Empieza por el mapa de propiedad del sitio web y las Store Pages. Define qué Store Page es propietaria de cada familia de Product y qué Pages, Blog Posts, dominios, Contacts y sistemas externos forman parte del destino.
¿Por qué deben prepararse por separado los tipos de Product de Squarespace?
Los Products físicos, de servicio, de tarjeta regalo y descargables no comparten las mismas relaciones de variantes, inventario, archivos, procesamiento o aplicaciones. Cada tipo necesita evidencia representativa del origen.
¿Cómo deben prepararse las Categories de Store Page?
Recógelas directamente junto con la pertenencia de Products, sus rutas y su propósito comercial. No están disponibles mediante la Products API y no deben inferirse únicamente a partir de registros Product.
¿Squarespace Contacts y Customers son identidades separadas?
Contacts representa personas asociadas con el sitio, incluidos Customers, suscriptores y donantes. El mismo ID de Contact puede aparecer como ID de Customer en un Order, pero membresías o suscripciones especializadas pueden seguir perteneciendo a otra aplicación.
¿Por qué deben prepararse Orders y Transactions por separado?
Orders explica los artículos comprados y el procesamiento, mientras que los documentos Transaction explican pagos, reembolsos, comisiones y errores de pasarela. Ambos son necesarios para disponer de contexto histórico completo.
¿Cuándo está completa la preparación para Squarespace?
Está completa cuando accesos, Store Pages, tipos de Product, variantes, inventario, Contacts, Orders, Transactions, contenido, rutas, extensiones, muestras y decisiones pendientes tienen responsables definidos y evidencia recuperable.