Bei der Bewertung von Shopware als mögliche Zielplattform bestimmt der Migrationsansatz, welcher Next-Cart Migrationsservice und welche unterstützten Maßnahmen für den Weg in dieses Ziel passen.
Der richtige Migrationsansatz für Shopware hängt nicht nur von der Anzahl der zu übertragenden Products, Customers, Orders, Categories, Coupons, Prüfungs, CMS-Inhalte und weiteren Datensätze ab. Shopware bringt strukturelle Entscheidungen zu Vertriebskanälen, Catalog Properties, Varianten, Regeln, Shopping Experiences, Erweiterungen, Custom Fields, Übersetzungen, Storefront-Funktionsweise und Integrationsverantwortung mit. Diese Entscheidungen bestimmen, ob die Migration innerhalb der regulär unterstützten Verarbeitung bleiben kann oder stärker geführte beziehungsweise individuelle Behandlung benötigt.
Der gewählte Ansatz muss zur tatsächlichen operativen Belastung passen. Ein überschaubares Shopware-Ziel mit gewöhnlichen Katalog-, Customer- und Order-Daten kann für Standard Service geeignet sein. Sind Vertriebskanal-Entscheidungen ungeklärt, die Validierung anspruchsvoll oder interne Prüfkapazitäten begrenzt, kann Managed Service die sicherere Wahl sein. Add-ons verfeinern unterstützte Migration durch Datensatz-Filterung, Transformation von Feldwerten oder Feldzuordnung. Custom Service wird relevant, wenn nicht unterstützte Erweiterungsdaten, Custom Fields außerhalb des unterstützten Mapping-Umfangs, individuelle Transformationen, individuelle Plattform-Anforderungen oder externe Systembeziehungen über die Standardfunktionen hinausgehen.
Innerhalb der Next-Cart Migrationsservices muss die Shopware-Nachweis unterstützte Datensätze, Ausführungsverantwortung, klar abgegrenzte Add-on-Anforderungen, Vertriebskanal-Interpretation, Erweiterungsdaten und Custom-Beziehungen voneinander trennen.
Mit Shopware-Komplexität beginnen, nicht mit Paketbezeichnungen
Die Servicewahl sollte beim Migrationsmuster beginnen und nicht bei einem bevorzugten Servicenamen. Shopware kann gewöhnliche Commerce-Datensätze aufnehmen, aber ebenso ein strukturiertes Umfeld bilden, in dem Products, Content, Vertriebskanäle, Regeln, APIs und Integrationen ineinandergreifen. Der Migrationsansatz muss diese Realität abbilden.
| Shopware-Migrationsmuster | Sinnvoller Ausgangspunkt | Warum |
|---|---|---|
| Gewöhnliche unterstützte Datensätze und einfache Zielkonfiguration | Standard Service | Schwerpunkt liegt auf Datentransfer und kundenseitiger Prüfung. |
| Klarer Datenumfang, aber hoher Koordinationsaufwand | Managed Service | Sequenzierung, Prüfunterstützung und Issue-Koordination profitieren von stärkerer Begleitung. |
| Unterstützte Daten mit konkreter Datensatz-Filterung, Feldwert-Transformation oder Feldneuzuordnung | Add-ons | Unterstütztes Migrationsverhalten wird angepasst, ohne zu individueller Entwicklungsarbeit zu werden. |
| Nicht unterstützte Plugins, Custom Fields außerhalb unterstützter Mapping-Grenzen, individuelle Logik oder externe Abhängigkeiten | Custom Service | Arbeit geht über regulär unterstützte Übertragung hinaus und benötigt individuelle Prüfung. |
| Unklares Zielbetriebsmodell | Demo Migration vor endgültiger Bestätigung des Ansatzes | Repräsentative Beispiele zeigen, ob die angenommene Vorgehensweise realistisch ist. |
Damit wird sowohl Over- als auch Underscoping vermieden. Eine einfache Shopware-Migration sollte nicht unnötig zu individuelle Arbeit werden; ein komplexes Shopware-Setup darf umgekehrt nicht allein deshalb als gewöhnlich gelten, weil die Entity-Liste vertraut aussieht.
Wann Standard Service realistisch ist
Standard Service kann passen, wenn Quelldaten gewöhnlich sind, das Shopware-Ziel klar definiert ist und das Unternehmen Vorbereitung und Validierung selbst führen kann. Die Erwartung sollte dann nahe an unterstützten Commerce-Datensätzen und unterstütztem Mapping-Verhalten bleiben.
Typische Signale sind ein beherrschbarer Product-Katalog, verständliche Categories, begrenzte Custom Fields, keine kritischen nicht unterstützten Plugin-Daten, klare Customer- und Order-Erwartungen sowie ein Ziel-Store ohne ungelöste Vertriebskanal- oder Regelkomplexität. Das Team muss Demo-Migration-Ergebnisse und die finalen Migrationsergebnisse gemeinsam mit internen Stakeholdern prüfen können.
| Signal für Standard Service | Trotzdem zu prüfen |
|---|---|
| Products, Customers, Orders, Categories, Coupons, Prüfungs und CMS-Inhalte sind überwiegend gewöhnlich. | Repräsentative Beispiele müssen Core Felder, Beziehungen und Content-Nutzbarkeit belegen. |
| Vertriebskanalmodell ist einfach oder bereits konfiguriert. | Products und Categories müssen im vorgesehenen Storefront-Kontext erscheinen. |
| Varianten und Properties sind verständlich. | Kaufoptionen und Filter müssen nach der Migration klar bleiben. |
| Custom Fields sind begrenzt oder nicht geschäftskritisch. | Wichtige Werte müssen auf unterstütztes Mapping geprüft werden. |
| Erweiterungsabhängigkeiten gehören nicht zum erwarteten Migrationsumfang. | Das Unternehmen muss akzeptieren, welches Verhalten bewusst ausgeschlossen ist. |
Standard Service bedeutet nicht, dass keine Planung nötig ist. Es bedeutet, dass Vorbereitung und Prüfung innerhalb eines unterstützten Migrationspfads ohne dauerhaft geführte Ausführung oder Custom-Development-Prüfung möglich sind.
Wann Managed Service die sicherere Wahl ist
Managed Service ist geeigneter, wenn die Migration grundsätzlich unterstützt sein kann, der Koordinationsaufwand jedoch hoch ist. Bei Shopware können Katalog, SEO, Content, Operations, Finance, Integrationen und technische Stakeholder unterschiedliche Entscheidungen besitzen. Ohne klare Abstimmung kann das Projekt auch dann abdriften, wenn die Daten selbst migrierbar sind.
Managed Service ist sinnvoll, wenn das Zielbetriebsmodell ausreichend klar ist, das Unternehmen aber stärkere Unterstützung bei Sequenzierung, Demo-Migration-Prüfung, Priorisierung von Findings und Bereitschaft-Entscheidungen benötigt. Das gilt auch bei komplexen Quell-Stores, in denen interne Teams nur schwer trennen können, was Data, Configuration, Content, Custom Umfang oder Zielimplementierung ist.
| Signal für Managed Service | Nutzen der Begleitung |
|---|---|
| Mehrere Teams prüfen unterschiedliche Ergebnisse. | Catalog-, SEO-, Content-, Order- und Integrationsreview können abgestimmt werden. |
| Vertriebskanal-, Sprach- oder Content-Kontext ist wesentlich. | Prüfung geht über Datensatz Counts hinaus. |
| Demo Migration bestimmt wichtige Umfangsentscheidungen. | Findings müssen in konkrete nächste Maßnahmen übersetzt werden. |
| Begrenzte Migrationserfahrung | Geführter Prüfung reduziert das Risiko unvollständiger Freigaben. |
| Sensitiver Launch-Termin | Sequenzierung und Issue-Priorisierung werden kritischer. |
Managed Service ersetzt keinen undefinierten Umfang. Am wirksamsten ist er, wenn ausreichend Nachweis zum Start vorliegt, aber Ausführung und Prüfung stärker koordiniert werden müssen.
Wann Add-ons helfen
Add-ons passen, wenn die gewünschte Anpassung innerhalb unterstützten Migrationsverhaltens bleibt. Für Shopware können sie unterstützte Datensätze anhand definierter Feldbedingungen filtern, Feldwerte durch Ausdrücke transformieren oder Quellfelder kompatiblen Zielfeldern neu zuordnen.
Die Grenze lautet: Nutzt die Anforderung einen dieser unterstützten Mechanismen, oder verlangt sie eine nicht unterstützte Datenbehandlung? Müssen Daten aus nicht unterstützten Plugins, Custom Tables, individuellen Feldern oder externen Systemen in eine eigene Zielstruktur übertragen werden, ist Custom Service zu prüfen.
| Add-ons-Kandidat | Warum passend | Wann stattdessen Custom Service |
|---|---|---|
| Data Filter | Unterstützte Datensätze müssen definierte Datensatz-Feld-Bedingungen erfüllen. | Filter hängt von nicht unterstützter Custom Logic oder unzugänglichen Plugin-Daten ab. |
| Data Transformation | Unterstützte Feldwerte werden über definierte Ausdrücke verändert. | Transformation hängt von nicht unterstützten Modulen, externen Systemen oder individueller Logik ab. |
| Advanced Data Mapping | Unterstützte Quellfelder benötigen kompatible Shopware-Zielfelder. | Ziel verlangt nicht unterstütztes Verhalten oder eine nicht unterstützte Struktur. |
Advanced Database Mapping ist für eine Migration nach Shopware nur verfügbar, wenn auch die Quellplattform Open Source ist. Zusätzlich muss die konkrete Feld- oder Datenbankspalten-Zuordnung innerhalb der unterstützten Ziel- und Datentypgrenzen liegen. Die Open-Source-Eigenschaft von Shopware allein reicht nicht aus.
Add-ons erhöhen die Präzision unterstützter Migration. Sie dürfen nicht dazu dienen, individuelle Komplexität in einem Standardpfad zu verstecken.
Wann Custom Service erforderlich ist
Custom Service ist der richtige Pfad, wenn die Migration über unterstütztes Standardverhalten hinausgeht. Aufgrund der Erweiterbarkeit von Shopware ist diese Abgrenzung besonders wichtig. Ein Quell-Store kann plugin-eigene Datensätze, Custom Fields außerhalb unterstützter Mapping-Grenzen, individuelles Storefront-Verhalten, alte Moduldaten, ERP/PIM/CRM-IDs, Marketplace-Referenzen, individuelle Pricing Rules oder Content-Commerce-Strukturen enthalten, die sich nicht sauber im regulären Umfang abbilden lassen.
Custom Service sollte dann geprüft werden, wenn das Unternehmen erklären kann, warum die nicht unterstützten Daten geschäftlich relevant sind und wie sie in Shopware funktionieren sollen. Ziel ist nicht, alles zu migrieren, nur weil es existiert, sondern die geschäftskritische Bedeutung zu bewahren, die Standardumfang nicht abdecken kann.
| Custom-Service-Auslöser | Zu klären |
|---|---|
| Nicht unterstützte App-, Plugin-, Modul- oder Erweiterungsdaten | Wo liegen die Daten, welcher Geschäftsprozess nutzt sie und welches Zielergebnis wird erwartet? |
| Operativ/integrativ wichtige Custom Fields außerhalb unterstützter Mapping-Grenzen | Nach Prüfung von unterstütztem Feld Mapping und ggf. berechtigtem Database Mapping klären, ob Werte in Shopware Custom Fields, externen Systemen oder anderer Zielstruktur liegen sollen. |
| Individuelle Transformationslogik | Welche Bedeutung in der Quelle soll in Shopware entstehen und warum reicht reguläres Mapping nicht? |
| Externe Systemidentifikatoren | Welche IDs müssen für ERP, PIM, CRM, Suche, Marketplace, Fulfillment oder Berichterstattung nutzbar bleiben? |
| individuelle Plattform- oder individuelle Migrationslogik | Welche nicht standardmäßige Quelle/Zielstruktur oder Verarbeitung muss separat entworfen werden? |
Custom Service ist keine allgemeine Bezeichnung für „komplex“. Komplexität kann weiterhin mit Standard Service, Managed Service und Add-ons beherrschbar sein, solange die erforderliche Verarbeitung unterstützt wird.
Demo Migration zur Bestätigung des Ansatzes nutzen
Demo Migration ist der sicherste Weg zu prüfen, ob der vorgeschlagene Ansatz zur tatsächlichen Shopware-Migration passt. Die Stichprobe sollte repräsentative Datensätze enthalten und nicht nur zufällig klein sein. Der Prüfung muss dieselbe Nachweis prüfen wie die Vorbereitung: Vertriebskanäle, Varianten-Products, Properties, Categories, Content Pages, Customers, Orders, Custom Fields und integrationsgebundene Datensätze.
| Finding aus der Demo Migration | Auswirkung auf den Ansatz |
|---|---|
| Core Datensätze migrieren sauber und Samples sind nutzbar. | Standard Service kann weiterhin passend sein. |
| Datensätze migrieren, aber Prüfung-Koordination ist schwierig. | Managed Service kann das Ausführungsrisiko senken. |
| Unterstützte Datensätze benötigen Filterung, Feldwert-Transformation oder Feld-Remapping. | Add-ons können das Migrationsergebnis verbessern. |
| Wichtige Daten fehlen, weil sie nicht unterstützt oder Custom-owned sind. | Custom-Service-Prüfung ist nötig, bevor der vollständige Umfang akzeptiert wird. |
| Zielkonfiguration ist unvollständig. | Das Problem kann Zielbereitschaft statt Migrationsfehler sein. |
Demo Migration ist nicht nur ein Pass/Fail-Ereignis. Sie ist ein Entscheidungspunkt für Servicepfad, Zielbereitschaft und Validierungsverantwortung.
Entity Points und Shopware-Umfang steuern
Entity Points sind relevant, wenn neue berechtigte Datensätze migriert werden. Für Shopware zählt nicht nur, wie viele Datensätze existieren, sondern welche neu sind, welche innerhalb der gekauften Migration und ihres festen Pfads bereits erfasst wurden und welche späteren Migrationsaktionen erstmals neue berechtigte Products, Customers, Orders oder Blog Posts einbeziehen.
Eine spätere Migrationsaktion bedeutet nicht automatisch, dass dieselben bereits gezählten Datensätze erneut zusätzliche Entity Points verbrauchen. Entscheidend ist, ob die Aktion neue berechtigte Datensätze erstmals migriert oder bereits innerhalb derselben gekauften Migration gezählte Datensätze wiederholt.
| Umfangssituation | Auswirkung auf Entity Points |
|---|---|
| Bereits gezählte Products werden über eine spätere Aktion erneut migriert. | Sie sollten nicht allein wegen der Wiederholung als neu Entity-Points-verbrauchend behandelt werden. |
| Nach der früheren Migration kommen neue Products, Customers, Orders oder Blog Posts hinzu. | Neu migrierte berechtigte Datensätze können bei der ersten Migration Entity Points verbrauchen. |
| Custom Fields oder plugin-eigene Daten benötigen besondere Behandlung. | Zuerst unterstütztes Mapping prüfen; übersteigt Plugin Verantwortungship oder benötigte Verarbeitung den Umfang eines Standard Add-on, sind Service Umfang und Custom Service wichtiger als Entity Points. |
| Eine neue Migration ersetzt vorherige Zieldaten. | Replacement setzt die Duplicate-Consumption-Logik für bereits innerhalb der gekauften Migration gezählte Datensätze nicht automatisch zurück. |
| Das Unternehmen ändert vor der Fortsetzung die Konfiguration. | Servicepfad und Validierungsumfang müssen neu geprüft werden, nicht nur der Punkteverbrauch. |
Entity Points sollten ausschließlich zur Planung gezählter Kapazität verwendet werden. Sie ersetzen keine Servicepfad-Entscheidung.
Optionen für spätere Migrationen für Shopware
Die Shopware-Launch-Planung kann nach Demo Migration, nach geänderten Vertriebskanal- oder Katalogentscheidungen oder nach neuen Products, Customers, Orders, Blog Posts, Übersetzungen, Medien und kommerziellen Änderungen auf der Quellplattform weitere Migrationstätigkeit erfordern. Die Aktion muss dazu passen, ob die bisherige Konfiguration weiterhin richtig ist, unterstützte Migrationsregeln geändert werden müssen oder das Zielergebnis einen neuen Ausgangspunkt benötigt.
| Additional Migration Option | Wann sie für Shopware passt | Was erneut validiert werden muss |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Akzeptierte Filter, Mappings und Konfiguration bleiben gültig; Hauptbedarf ist die Verarbeitung neu berechtigter Datensätze oder späterer Änderungen an der Quelle. | Neue Products/Varianten, Properties, Medien, Customers, Orders, Übersetzungen, Content sowie Regressionstestfälle in betroffenen Vertriebskanälen. |
| Continue the Migration with a New Configuration | Demo Migration oder Zielprüfung zeigt, dass Filter, Mapping, Custom-Feld-Platzierung, Translation Handling, Content-Umfang oder unterstützte Datenkonfiguration geändert werden müssen. | Jede betroffene Product-Familie, Variantenbeziehung, Property Group, Kanalzuordnung, jedes Custom Field, jeder übersetzte Wert, Order-Sample und jede Content-Struktur, die von der Änderung beeinflusst wird. |
| Perform a New Migration | Das bisherige Zielergebnis ist keine zuverlässige Basis mehr, die Zielumgebung wurde zurückgesetzt oder Umfang und Annahmen haben sich wesentlich verändert. | Vollständiger akzeptierter Umfang, Replacement-Verhalten, Kanalsichtbarkeit, Product-Beziehungen, Customers, Orders, Medien, Content, URLs und extension-sensitive Outputs. |
Shopware-Revalidierung bleibt proportional zur Aktion. Eine Fortsetzung mit gleicher Konfiguration konzentriert sich auf neue Datensätze und Regressionstestfälle. Eine neue Konfiguration konzentriert sich auf die geänderten Mappings beziehungsweise den Umfang und deren Wirkung über Vertriebskanäle hinweg. Perform a New Migration verlangt breiten Nachweis, dass das neu aufgebaute Ziel weiterhin nutzbar ist. Rules, Payment, Shipping, Tax, Shopping Experiences, Extension-Konfiguration, Themes, Integrationen und anderes Zielverhalten bleiben von regulärer Migrationsausgabe getrennt, sofern sie nicht ausdrücklich in einem vereinbarten Umfang enthalten sind.
Shopware-Servicepfad mit Entscheidungsgates festlegen
Eine Shopware-Serviceentscheidung sollte vor Full Migration vier plattformspezifische Gates bestehen. Das Katalog-Gate muss belegen, dass Parent-Child-Product-Beziehungen, Varianten, Properties, Medien, Übersetzungen und Vertriebskanal-Sichtbarkeit eine unterstützte Zielbedeutung besitzen. Das Commercial Gate trennt migrierte Datensätze von Shopware Rules, Pricing, Tax, Payment, Shipping und Promotion-Konfiguration. Das Ecosystem Gate identifiziert Custom Fields, Extensions, Shopping Experiences, APIs und externes System-IDs außerhalb gewöhnlicher Datensatz-Migration. Das Governance Gate bestätigt Verantwortungship für Zielkonfiguration, Regressionstests und Launch-Freigabe.
| Decision Gate | Nachweis für einen unterstützten Pfad | Eskalationssignal |
|---|---|---|
| Katalog und Vertriebskanäle | Repräsentative Products und Kanalzuordnungen bleiben nutzbar. | Wichtige Beziehungen erfordern nicht unterstützte Transformation oder Custom Extraction. |
| Kommerzielles Verhalten | Historische Daten sind lesbar; aktive Regeln werden separat konfiguriert. | Quelllogik muss aus Custom Rules, Plugins oder externen Systemen rekonstruiert werden. |
| Content und Erweiterungen | CMS-Inhalte und unterstützte Felder haben definierte Ziele. | Shopping Experiences, Extension Tables oder Custom Fields tragen geschäftskritische Daten ohne Standardziel. |
| Validierung und Verantwortungship | Das Unternehmen kann Samples über betroffene Kanäle hinweg freigeben. | Akzeptanz kann ohne individuelle Analyse oder Expert Handle nicht definiert werden. |
Das Bestehen dieser Gates verlangt nicht den teuersten Servicepfad, sondern den richtigen. Managed Service passt, wenn Umfang unterstützt, die Koordination aber anspruchsvoll ist. Custom Service passt, wenn das erwartete Ergebnis selbst individuelle Behandlung benötigt.
Den richtigen Pfad wählen
Der richtige Shopware-Migrationsansatz passt zur Daten-Nachweis, Zielbereitschaft, internen Prüfkapazität und zum Risiko nicht unterstützten Umfangs. Die Entscheidung sollte erst nach Prüfung von Katalog, Vertriebskanälen, Content, kommerzieller Logik, Custom Fields, Extensions, Integrationen und Demo-Migration-Ergebnissen getroffen werden.
| Wenn die Migration ... hat | Bevorzugen | Darauf achten |
|---|---|---|
| gewöhnliche unterstützte Datensätze und klare Zielkonfiguration | Standard Service | Validierungsverantwortung nicht unterschätzen. |
| unterstützten Umfang, aber hohen Koordinationsaufwand | Managed Service | Begleitung ersetzt keinen klaren Umfang. |
| konkrete unterstützte Datensatz-Filterung, Feldwert-Transformation oder Feld-Remapping-Anforderungen | Add-ons | Nicht unterstützte benutzerdefinierte Daten nicht als Add-on behandeln. |
| plugin-eigene, Custom- oder externes System-Daten | Custom Service | Veraltete Daten ohne Business Value nicht unnötig migrieren. |
| unklare Komplexität | Demo Migration als Entscheidungsnachweis | Keine Schlussfolgerung aus zu wenigen Samples ziehen. |
Eine belastbare Serviceentscheidung erleichtert die Validierung. Wenn nach der Auswahl weiterhin unklar ist, was mit wichtigen Products, Rules, Content, Custom Fields oder Integrationen geschehen soll, ist der Ansatz noch nicht bereit.
Fazit
Der richtige Shopware-Migrationsansatz entsteht aus dem Verhältnis zwischen unterstützten Daten, Zielbetriebsmodell, Prüfkapazität und Custom-Umfangsrisiko. Standard Service kann bei gewöhnlichen Daten und klarer Konfiguration funktionieren. Managed Service hilft bei höherem Koordinations- und Validierungsrisiko. Add-ons verfeinern unterstütztes Migrationsverhalten. Custom Service behandelt nicht unterstützte, individuelle, erweiterungseigene oder anderweitig bespoke Anforderungen.
Shopware belohnt klare Entscheidungen. Wenn Catalog-Samples, Vertriebskanäle, kommerzielle Regeln, Content-Prioritäten, Custom Fields, Integrationen, Demo-Migration-Findings, Entity-Points-Auswirkungen und spätere Migrationsaktionen vor dem Launch verstanden sind, lässt sich der Ansatz nachvollziehbar auswählen und später zuverlässig prüfen.
Häufige Fragen
Wann reicht Standard Service für Shopware aus?
Standard Service kann ausreichen, wenn unterstützte Datensätze gewöhnlich sind, die Zielkonfiguration klar ist, Custom Fields begrenzt sind, Erweiterungsdaten nicht zum erwarteten Umfang gehören und das Unternehmen Vorbereitung und Validierung selbst übernehmen kann.
Wann sollte eine Shopware-Migration Managed Service verwenden?
Managed Service ist sinnvoll, wenn die Migration unterstützt ist, die Koordination aber schwierig wird, mehrere Teams unterschiedliche Ergebnisse prüfen, Demo-Migration-Findings geführte Interpretation benötigen oder ein enger Launch-Termin stärkere Sequenzierung verlangt.
Was ist bei Shopware der Unterschied zwischen Add-ons und Custom Service?
Add-ons verändern unterstützte Filterung, Feldwert-Transformation oder Feld Mapping. Custom Service behandelt nicht unterstützte Erweiterungsdaten, Custom Fields außerhalb unterstützter Mapping-Grenzen, individuelle Transformationen, individuelle Plattform-Anforderungen, externe System-IDs oder eigene Migrationslogik jenseits der Standardfähigkeit.
Warum sollte Demo Migration den Servicepfad beeinflussen?
Demo Migration zeigt anhand repräsentativer Shopware-Fälle, ob Datensätze und Beziehungen sauber migrieren, welche Zielkonfiguration noch fehlt, ob Add-ons nötig sind und ob nicht unterstützte Daten in Custom-Service-Prüfung übergehen müssen.
Werden Shopware Rules, Vertriebskanal-Einstellungen und Erweiterungen durch die Datenmigration betriebsbereit?
Nein. Migrierte Datensätze können unterstützte Daten bewahren, aber Rules, Vertriebskanal-Konfiguration, Zahlung, Versand, Steuern, Storefront-Funktionsweise und Erweiterungsimplementierung müssen separat eingerichtet und validiert werden, sofern sie nicht ausdrücklich Bestandteil eines vereinbarten Custom Umfang sind.