Wenn Squarespace als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn Squarespace als Zielplattform vorgesehen ist, sollte die Vorbereitung bereits vor dem ersten Migrationslauf klären, wie der Commerce-Katalog in die umfassendere Website eingebettet wird. Jedes Product gehört zu einer Store Page, während physische, Service-, Gift Card- und Download Products unterschiedliche Varianten- und Bestandslogik besitzen. Contacts, Orders, Transactions, Pages, Blog Posts, Navigation, Extensions und Website-Design bleiben ebenfalls eigenständige Datensatzfamilien.
Für jede erforderliche Vorbereitungsmaßnahme sollten eine verantwortliche Person, belastbare Nachweise und eine klare Bereitschaftsbedingung dokumentiert werden. So wird verhindert, dass ein vollständiger Product-Export mit einer vollständigen Store Page verwechselt, ein Contact als Abo- oder Mitgliedschaftsberechtigung behandelt oder historische Zahlungsinformation mit aktueller Checkout-Konfiguration gleichgesetzt wird.
Squarespace-Website und Store-Page-Modell festlegen
Definieren Sie die vorgesehene Beziehung zwischen Website, Store Pages, Products, Inhalten, Navigation und verbundenen Systemen.
| Vorbereitungsbereich | Zu dokumentierende Entscheidung | Verantwortlicher | Nachweis der Bereitschaft |
|---|---|---|---|
| Website-Struktur | Domains, Locale, Währung, Navigation, Pages, Blog und Commerce-fähige Bereiche | Website-Verantwortlicher | Website- und Routenplan |
| Store Pages | Welche Store Page welche Product-Familie verwaltet | Commerce-Verantwortlicher | Matrix für Store-Page-Zuordnungen |
| Product-Typen | Umgang mit physischen, Service-, Gift Card- und Download Products | Merchandising-Verantwortlicher | Inventar der Product-Typen |
| Kundenmodell | Contacts, Abonnenten, Spender, Customers, Konten und externe CRM-Beziehungen | Kundenverantwortlicher | Contact-Klassifizierungsmatrix |
| Order- und Finanzmodell | Orders, Subscription Orders, Transactions, Erstattungen und externe Referenzen | Operations/Finance | Paket mit historischen Nachweisen |
| Extension-Modell | Verantwortung für Fulfillment, Abonnements, Mitgliedschaften, Buchungen, Steuern, Marketing und Analytics | Technischer Verantwortlicher | Abhängigkeitsregister |
Das Modell ist bereit, wenn jeder wesentliche Commerce- und Inhaltsdatensatz einem vorgesehenen Squarespace- oder externen Eigentümer zugewiesen ist und jede Product-Familie eine definierte Store Page besitzt.
Zugänge, Quellarchive und wiederherstellbare Nachweise vorbereiten
Sammeln Sie:
- Administratorzugang zur Quelle und die erforderlichen Website- und Commerce-Berechtigungen in Squarespace;
- datierte Exporte oder Sicherungen für Products, Customers, Orders, Inhalte, Abonnenten und relevante individuelle Daten;
- Product-Bilder, Download-Dateien, Seitenmedien und Quellinhaltsarchive;
- Inventare für Store Pages, Navigation, Domains und URLs;
- Nachweise zu Extensions, APIs, Webhooks und externen Systemen;
- externe Kennungen für Products, Contacts, Orders und Transactions;
- einen Verantwortlichen für Änderungen an Products, Contacts, Orders, Inhalten und Bestand während des Migrationsfensters.
| Nachweiselement | Warum es wichtig ist | Bereitschaftsbedingung |
|---|---|---|
| Zugangsprotokoll | Bestätigt, dass relevante Bereiche in Quelle und Ziel geprüft werden können | Erforderliche Berechtigungen sind verfügbar |
| Datiertes Quellarchiv | Bewahrt einen wiederherstellbaren Referenzzustand | Exporte lassen sich öffnen und besitzen ein Datum |
| Medien- und Dateiarchiv | Schützt Product-Bilder, Seitenmedien und Downloads | Dateien lassen sich ihren verantwortlichen Datensätzen zuordnen |
| Store-Page-Inventar | Verhindert, dass Products der falschen Commerce-Seite zugeordnet werden | Jede Product-Familie besitzt eine Ziel-Store-Page |
| Register externer IDs | Schützt Kontinuität mit CRM, Fulfillment, Buchhaltung oder Marketplaces | Jeder Schlüssel ist der richtigen Entität zugeordnet |
| Änderungsprotokoll | Erfasst Änderungen in der Quelle nach dem Archivdatum | Neue und geänderte Datensätze haben verantwortliche Personen |
Kann eine Anwendung oder ein externes System keinen Export bereitstellen, dokumentieren Sie die Einschränkung und den zuständigen Verantwortlichen, statt den Bereich stillschweigend aus der Vorbereitung zu entfernen.
Product-Typen, Varianten, Bilder und Bestand vorbereiten
Squarespace unterstützt physische, Service-, Gift Card- und Download Products. Physische und Service Products können Varianten verwenden; Bestandsdatensätze gelten für physische und Service-Varianten und können verfolgt oder unbegrenzt sein. Download Products besitzen Dateibeziehungen, verwenden aber nicht dasselbe Variantenmodell.
Bereiten Sie repräsentative Beispiele vor für:
- jeden Product-Typ, den das Unternehmen nutzt;
- einfache Products und Products mit vielen Varianten;
- Product-Attribute wie Farbe, Größe oder Gewicht;
- Beziehungen zwischen Varianten-SKU, Preis, Bestand und Bild;
- herunterladbare Dateien und erwartete Zugriffsrechte;
- Service Products und gegebenenfalls Buchungs- oder externe Terminplanungsabhängigkeiten;
- Geschenkkartenhistorie oder aktuelle Guthaben, sofern relevant;
- Bundles, Abonnements, Personalisierung oder von Extensions verwaltetes Verhalten;
- Kennungen aus ERP, PIM, Warehouse, Marketplace und Fulfillment.
| Verhalten in der Quelle | Vorbereitungsentscheidung | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Physisches oder Service Product besitzt Varianten | Product- und Variantenverantwortung definieren | Parent-/Varianten-IDs, Attribute, SKU, Preis, Bestand und Bilder | Jede Kombination besitzt eine vorgesehene Squarespace-Variante |
| Download Product | Verantwortung für Product, Datei und Auslieferung definieren | Quelldatei, Product-ID, Zugriffsregeln und Order-Beispiel | Die Dateibeziehung hat einen benannten Verantwortlichen |
| Service Product nutzt Terminplanung | Product-Daten von Buchungs- oder externen Terminplanungsdatensätzen trennen | Beispiele für Service und Termin | Verantwortung für Terminplanung ist dokumentiert |
| Geschenkkarte oder gespeicherter Wert vorhanden | Historischen und aktuellen Eigentümer definieren | Beispiele für Code/Guthaben und Finance-Verantwortlicher | Umgang mit gespeichertem Wert ist ausdrücklich festgelegt |
| Product-Verhalten wird von Extension verwaltet | Fortbestehende Extension oder externes System identifizieren | Zugehöriges Product und Konfigurationsnachweise | Erforderliche Datensätze sind im Abhängigkeitsregister enthalten |
Der Bereich ist bereit, wenn jede Product-Familie einen Typ, eine Store Page, ein Variantenmodell, eine Bestandsbehandlung, einen Medien-/Dateiverantwortlichen und externe Schlüssel besitzt.
Store Pages, Categories, Navigation und Produktfindung vorbereiten
Jedes Squarespace Product gehört zu einer Store Page. Store-Page-Categories und Navigation sind jedoch getrennte Strukturen. Da die Products API Store-Page-Kategoriezuordnungen nicht bereitstellt, müssen Nachweise für Product-Gruppierung und Produktfindung im Storefront direkt aus der Quelle vorbereitet werden.
Sammeln Sie:
- Namen, Kennungen, URLs und Product-Zuordnungen der Store Pages;
- Product Categories und Merchandising-Gruppen innerhalb jeder Store Page;
- Hauptnavigation, sekundäre Navigation, Footer-Links und Landingpages;
- Filter, Attribute, interne Links und Kampagnen-Collections;
- besonders wichtige Einkaufspfade und Quell-URLs;
- Weiterleitungen und Entscheidungen zur Stilllegung.
| Bereich der Produktfindung | Verantwortlicher | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Store Page | Commerce-/Website-Verantwortlicher | Liste der Store Pages und Product-Zuordnungen | Jedes Product besitzt eine vorgesehene Store Page |
| Category oder Gruppierung | Merchandising-Verantwortlicher | Beispiele für Product-Mitgliedschaft und öffentliche Routen | Bedeutung der Gruppe ist unabhängig von Navigation dokumentiert |
| Navigation | Website-Verantwortlicher | Menübaum und Ziellinks | Store Pages, Categories, Pages und externe Links besitzen vorgesehene Positionen |
| Landingpage-Inhalt | Redaktioneller Verantwortlicher | Seiteninhalt, Medien, Metadaten und Product-Referenzen | Kampagnen- und dauerhafte Pfade haben definierte Verantwortliche |
| Weiterleitung | SEO-Verantwortlicher | Ledger für Quell- und Ziel-URLs | Jeder priorisierte Pfad besitzt ein freigegebenes Ergebnis |
Gehen Sie nicht davon aus, dass die Migration von Products automatisch Store-Page-Categories, Menüplatzierung oder Käuferpfade wiederherstellt. Diese Beziehungen brauchen eigene Nachweise und Verantwortliche.
Contacts, Adressbücher, Abonnenten und Customer-Identität vorbereiten
Die Squarespace Contacts API stellt Personen dar, die mit der Website verbunden sind, darunter Customers, Mailinglisten-Abonnenten, Spender und andere Website-Teilnehmer. Contacts können Adressbücher und Marketing-Präferenzen besitzen; die Contact ID entspricht der Customer ID, auf die Orders verweisen.
Bereiten Sie vor:
- registrierte Customers, Gastkäufer, Abonnenten, Spender und andere Contacts;
- Beispiele für doppelte E-Mail-Adressen oder mehrdeutige Identitäten;
- Contact-Adressbücher und Standard-Lieferadressen;
- Marketing-Präferenzen und Einwilligungsnachweise;
- Customer-/Contact-IDs, die von Orders verwendet werden;
- Erwartungen an Kontozugriff;
- Mitgliedschafts-, Abo-, Loyalitäts-, Buchungs- oder CRM-Datensätze, die an anderer Stelle verwaltet werden;
- externe Contact- und Customer-Kennungen.
| Identitätsfall | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Customer mit Orders | Customer Operations | Contact ID, Adressbuch und Order-Beispiele | Order-Beziehungen verwenden die vorgesehene Contact-Identität |
| Gastkäufer | Customer Operations | E-Mail-, Order- und Adress-Momentaufnahmen | Gasthistorie ist dokumentiert, ohne ein Konto zu erfinden |
| Abonnent oder Spender | Marketing-/Fundraising-Verantwortlicher | Einwilligungs-, Listen- und Aktivitätskontext | Nicht-kommerzielle Identität wird nicht standardmäßig als Retail-Customer behandelt |
| Teilnehmer an Mitgliedschaft oder Abonnement | Anwendungsverantwortlicher | Plan-, Berechtigungs-, Verlängerungs- oder Zugriffsdatensätze | Die spezialisierte Beziehung hat einen fortbestehenden Eigentümer |
| Externer CRM-Contact | Integrationsverantwortlicher | CRM-ID und Matching-Regeln | Systemübergreifende Identität ist dokumentiert |
Authentifizierung und Kontozugriff sollten getrennt von der Contact-Identität vorbereitet werden. Ein Contact-Datensatz reproduziert für sich allein weder ein Quellpasswort noch eine Mitgliedschaftsberechtigung oder ein Anwendungsprofil.
Historische Orders, Subscription Orders und Transactions vorbereiten
Wählen Sie Orders aus, die einmalige und wiederkehrende Käufe, Product-/Variantenzeilen, Customer IDs, Adressen, Rabatte, Steuern, Versand, Fulfillment, Erstattungen und externe Referenzen sichtbar machen. Bereiten Sie Transactions separat vor, da Finanzdokumente Zahlungen, Erstattungen, Gebühren und Gateway-Fehler zu einer Order oder Spende enthalten können.
| Historischer Bereich | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Einmalige Order | Product-/Variantenzeilen, Customer, Summen, Status und Fulfillment | Die Transaktion lässt sich anhand des Quellpakets erklären |
| Subscription Order | Abo-Kontext, Verlängerungshistorie, Products und Customer | Historische Wiederholung ist von aktueller Abo-Konfiguration getrennt |
| Zahlung und Erstattung | Transaction-Dokument, Zahlungsart, Erstattung und Fehlerbeispiele | Finanzhistorie ist mit der richtigen Order verbunden |
| Fulfillment | Versand, Tracking, erfüllte Mengen und externe IDs | Vergangener Lieferkontext ist nachvollziehbar |
| Guest Order | E-Mail, Adresse und Order-Beziehung | Gastidentität bleibt von einem dauerhaften Konto getrennt |
| Externe Order | Kanal-, ERP-, Buchhaltungs- oder Support-ID | Abstimmungsschlüssel bleiben an der richtigen Order |
Historische Orders und Transactions erhalten vergangenen Commerce. Aktuelle Zahlungsanbieter, Checkout, Steuern, Versand, Rabatte, Abo-Abrechnung und Fulfillment-Konfiguration bleiben eigenständige Vorbereitungsaufgaben der jeweils verantwortlichen Teams.
Inhalte, Blog Posts, Medien, Domains und URLs vorbereiten
Squarespace Commerce ist häufig in eine inhaltsorientierte Website eingebettet. Bereiten Sie vor:
- CMS Pages, Blog Posts, Store-Page-Inhalte, Product-Beschreibungen und Landingpages;
- Autoren, Datumsangaben, Tags, Categories, Medien und interne Links;
- Inventare für Bilder, Videos, Download-Dateien und Alt-Texte;
- primäre Domain, sekundäre Domains, Locale, Währung und Analytics-Verantwortung;
- URLs für Products, Store Pages, Inhalte, Blog Posts und Kampagnen;
- Metadaten, kanonische Beziehungen, Weiterleitungen und stillgelegte Pfade;
- Navigation, Footer- und Kampagnenlinks.
| Inhaltsbereich | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| CMS Page | Redaktioneller Verantwortlicher | Inhalt, Medien, Metadaten, Route und Navigationskontext | Jede Page besitzt ein vorgesehenes Ziel und eine Route |
| Blog Post | Redaktioneller Verantwortlicher | Inhalt, Autor/Datum, Medien, Tags/Categories und URL | Redaktionelle Historie und Route sind dokumentiert |
| Product-/Store-Page-Inhalt | Commerce-Verantwortlicher | Beschreibung, Bilder, Gruppierung und Page-Zuordnung | Inhalt bleibt mit dem richtigen Commerce-Objekt verbunden |
| Domain und Route | SEO-/Website-Verantwortlicher | Domain- und URL-Ledger | Jeder priorisierte Pfad besitzt ein Ziel oder eine Stilllegungsentscheidung |
| Template- oder Blockabhängigkeit | Website-Designer | Inventar für Layout, Block, Formular, Einbettung oder Code | Darstellungsarbeit ist von migriertem Inhalt getrennt |
Ein Inhaltsdatensatz ist bereit, wenn Body, Medien, Route, Verantwortlicher und vorgesehene Darstellungsebene bekannt sind. Das reine Kopieren von Text ist kein vollständiger Vorbereitungsnachweis.
Extensions, APIs, Webhooks und externe Systeme inventarisieren
Erstellen Sie ein Abhängigkeitsregister für Fulfillment, Abonnements, Mitgliedschaften, Buchungen, E-Mail-Marketing, CRM, Buchhaltung, Steuern, Versand, Reviews, Loyalitätsprogramme, Marketplaces, Spenden, Analytics und individuelle Anwendungen.
Dokumentieren Sie für jede Abhängigkeit:
- den Geschäftszweck;
- betroffene Products, Contacts, Orders, Transactions, Inhalte oder Dateien;
- führendes System und externe IDs;
- Verfügbarkeit von Export oder API;
- verantwortliche Person für die Konfiguration;
- Entscheidung über fortbestehendes Ziel, Ersatz oder Stilllegung;
- Quellnachweise, die vor der Konfiguration des Zielprozesses benötigt werden.
Das Register ist bereit, wenn jedes aktive, von einer Extension verwaltete Feld bzw. jeder entsprechende Datensatz einen benannten Eigentümer, eine übergeordnete Entität, einen fortbestehenden Verbraucher, eine dauerhafte Kennung und wiederherstellbare Quellnachweise besitzt, ohne allein von der Storefront-Darstellung abhängig zu sein.
Repräsentative Testmuster für die Migration auswählen
| Muster | Zweck der Vorbereitung |
|---|---|
| Physisches Product mit Varianten | Macht Attribute, SKU-, Bild- und Bestandsbeziehungen sichtbar |
| Service Product | Zeigt die Trennung zwischen Product-Daten und Terminplanung bzw. externer Service-Verantwortung |
| Download Product | Zeigt Beziehungen zwischen Product, Datei und Order-Zugriff |
| Product auf einer priorisierten Store Page | Zeigt Eigentum von Store Page, Category, Navigation und URL |
| Contact mit mehreren Adressen und Orders | Zeigt Contact ID, Adressbuch und Customer-Beziehung |
| Subscription Order oder erstattete Order | Zeigt Wiederholung, Transactions, Erstattung und Summen |
| CMS Page oder Blog Post | Zeigt Eigentum von Inhalt, Medien, Metadaten und Route |
| Von Extension verwalteter Datensatz | Zeigt fortbestehende Anwendung und externe Kennungen |
Dokumentieren Sie für jedes Muster die Quell-ID, gegebenenfalls die Quell-URL, den Product-Typ, die Store Page, den geschäftlichen Grund, den vorgesehenen Squarespace-Eigentümer, bekannte Ausschlüsse, externe Schlüssel und den verantwortlichen Prüfer.
Bereitschaft für Squarespace abschließend prüfen
| Bereitschaftsfrage | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Sind Zugänge und Quellarchive wiederherstellbar? | Zugangsprotokoll und datierte Exporte/Sicherungen | Erforderliche Datensätze lassen sich unabhängig von der Live-Quelle prüfen |
| Sind Website- und Store-Page-Verantwortung definiert? | Website-/Store-Page-Matrix | Jede Product-Familie und jeder Inhaltsbereich besitzt einen Verantwortlichen |
| Sind Product-Typen und Varianten vorbereitet? | Inventar der Product-Typen und Varianten | Physische, Service-, Gift Card- und Download-Fälle sind dokumentiert |
| Sind Contacts und Orders verbunden? | Beispiele für Contact-/Order-Beziehungen | Identität, Adressen und historische Transaktionen sind verständlich |
| Sind Transactions und Extensions inventarisiert? | Finanznachweise und Abhängigkeitsregister | Erstattungen, Zahlungen und anwendungsverwaltete Datensätze besitzen benannte Verantwortliche |
| Sind Inhalte und URLs vorbereitet? | Inhalts- und Routen-Ledger | Pages, Blog Posts, Store Pages, Medien und Weiterleitungen besitzen vorgesehene Ziele |
| Sind repräsentative Migrationsmuster ausgewählt? | Muster-Ledger | Komplexität von Katalog, Identität, Order, Transaktion, Inhalt und Extensions ist abgedeckt |
| Sind offene Punkte kontrolliert? | Entscheidungsprotokoll | Jeder offene Punkt besitzt Verantwortlichen und Fälligkeitsdatum |
Die Vorbereitung ist abgeschlossen, wenn keine kritische Entscheidung zu Store Page, Product-Typ, Variante, Contact, Order, Transaction, Inhalt, Route oder Extension mehr von einer undokumentierten Annahme abhängt.
Fazit
Die Vorbereitung auf Squarespace sollte ein gemeinsames Nachweispaket für Website und Commerce hervorbringen. Products müssen der richtigen Store Page und dem passenden Product-Typ zugeordnet sein; Varianten und Bestand müssen ihre Beziehungen behalten; Contacts dürfen nicht mit spezialisierten Konto- oder Mitgliedschaftsprogrammen verwechselt werden; Orders und Transactions müssen historischen Kontext bewahren; Inhalte und Routen brauchen klare Verantwortliche.
Sind diese Entscheidungen vor dem repräsentativen Migrationstest dokumentiert, kann die Prüfauswahl die vorgesehene Squarespace-Website realistisch abbilden, ohne importierte Commerce-Datensätze mit Website-Design oder aktueller Checkout-Konfiguration zu verwechseln.
Häufige Fragen
Was sollte für Squarespace zuerst vorbereitet werden?
Beginnen Sie mit der Zuordnung von Website und Store Pages. Legen Sie fest, welche Store Page jede Product-Familie verwaltet und welche Pages, Blog Posts, Domains, Contacts und externen Systeme zum Ziel gehören.
Warum müssen Squarespace Product-Typen separat vorbereitet werden?
Physische, Service-, Gift Card- und Download Products besitzen nicht dieselben Varianten-, Bestands-, Datei-, Fulfillment- oder Anwendungsbeziehungen. Für jeden Typ werden repräsentative Quellnachweise benötigt.
Wie sollten Store-Page-Categories vorbereitet werden?
Erfassen Sie sie direkt zusammen mit Product-Mitgliedschaften, Routen und Merchandising-Zweck. Sie werden nicht über die Products API bereitgestellt und dürfen nicht allein aus Product-Datensätzen abgeleitet werden.
Sind Squarespace Contacts und Customers getrennte Identitäten?
Contacts stellen Personen dar, die mit der Website verbunden sind, darunter Customers, Abonnenten und Spender. Dieselbe Contact ID kann als Customer ID in einer Order erscheinen; spezialisierte Mitgliedschaften oder Abonnements können dennoch von einer anderen Anwendung verwaltet werden.
Warum sollten Orders und Transactions getrennt vorbereitet werden?
Orders erklären gekaufte Artikel und Fulfillment, während Transaction-Dokumente Zahlungen, Erstattungen, Gebühren und Gateway-Fehler erklären. Für vollständigen historischen Kontext werden beide benötigt.
Wann ist die Squarespace-Vorbereitung abgeschlossen?
Sie ist abgeschlossen, wenn Zugänge, Store Pages, Product-Typen, Varianten, Bestand, Contacts, Orders, Transactions, Inhalte, Routen, Extensions, Prüfmuster und offene Entscheidungen jeweils verantwortliche Personen und wiederherstellbare Nachweise besitzen.