Wenn OpenCart als mögliche Zielplattform bewertet oder bereits für die Migration vorgesehen ist, muss die Validierung beweisen, dass der migrierte Shop als klare und beherrschbare Commerce-Umgebung funktioniert. Eine allgemeine Prüfung der Datensatzanzahl reicht nicht aus. Products können vorhanden sein, Categories können angezeigt werden, Customer-Konten können erscheinen und SEO-Keywords können auflösen, während Customers trotzdem die richtige Product-Option nicht sicher auswählen, den vorgesehenen Category-Pfad nicht finden, falsche gruppenabhängige Behandlung erhalten oder der Shop nach dem Launch nicht vertrauenswürdig funktioniert.
OpenCart-Validierung sollte deshalb Bedeutung und Verhalten prüfen. Entscheidend ist, ob Product-, Options-, Attribut-, Filter-, Category-, Customer-, SEO-, Erweiterungs- und Layoutstrukturen im Ziel das beabsichtigte Einkaufserlebnis tragen. Die stärkste Prüfung kombiniert risikoreiche Stichproben mit betrieblicher Kontrolle, damit der Zielshop nicht nur befüllt, sondern auch nutzbar, erklärbar und sicher verwaltbar ist.
Was die OpenCart-Validierung beweisen muss
Validierung ist am stärksten, wenn sie fragt, ob die migrierten Daten weiterhin den vorgesehenen Kaufpfad unterstützen. Der Zielshop sollte nicht als Sammlung isolierter Datensätze bewertet werden, sondern als zusammenhängende Shopoberfläche, in der Products, Categories, Filter, Kundengruppen, SEO-Keywords, Erweiterungen und Layoutentscheidungen zusammenwirken.
Die wichtigste Frage lautet: Kann der Händler erklären, welche Aufgabe jede migrierte Struktur in OpenCart erfüllen soll, und kann die Zielumgebung diese Aufgabe nachweisbar erfüllen? Product-Optionen müssen Kaufentscheidungen verständlich machen. Attribute sollen Products erklären und vergleichbar machen. Filter sollen Product-Mengen sinnvoll eingrenzen. Categories müssen Navigation unterstützen. SEO-Keywords müssen zu eindeutigen und passenden Zielseiten führen. Kundengruppen sollen relevante unterschiedliche Behandlung erhalten. Erweiterungen und Modifikationen sind funktionale Abhängigkeiten und keine bloßen dekorativen Zusätze.
| Validierungsbereich | Was bewiesen werden muss | Typischer falscher Pass |
|---|---|---|
| Products und Optionen | Customers können das vorgesehene kaufbare Ergebnis eindeutig auswählen. | Product-Datensätze existieren, aber Pflicht- oder Auswahlentscheidungen sind unklar. |
| Attribute und Filter | Beschreibende und navigierende Daten unterstützen Vergleich und Eingrenzung. | Werte sind vorhanden, helfen aber nicht bei Entscheidungen in der Shopoberfläche. |
| Categories und Hersteller | Customers erreichen die richtigen Product-Mengen über natürliche Pfade. | Category-Namen existieren, Product-Platzierung ist jedoch schwach. |
| Kundengruppen | Customer-Kontext erhält erwartete Prices, Rabatte, Zugriff oder Segmentierung. | Customers wurden importiert, Gruppenverhalten wurde aber nicht getestet. |
| SEO-Keywords und Routen | Wichtige URLs führen zum richtigen kommerziellen Ziel. | URLs laden, führen jedoch auf schwächere oder falsche Zielseiten. |
| Erweiterungen und Layouts | Zielverhalten unterstützt weiterhin Merchandising, kaufnahen Kontext, Auswertungen oder Vertrauen. | Erweiterungsdaten sind vorhanden, das benötigte Verhalten fehlt. |
Dieses Nachweismodell verhindert, dass eine technisch vollständige Migration freigegeben wird, bevor der Shop für Customers und interne Teams tatsächlich einsatzbereit ist.
Validierungspriorität 1: Product-Optionen und kaufbare Ergebnisse
Product-Prüfung sollte mit den Datensätzen beginnen, bei denen Auswahl am ehesten ihre Bedeutung verlieren kann. Da OpenCart Product-Informationen und Customer-Optionen trennt, reichen Name, SKU, Preis, Beschreibung, Bild und Category allein nicht aus. Die Validierung muss zeigen, dass auswählbare Werte weiterhin zum richtigen kaufbaren Ergebnis führen.
Früh geprüft werden sollten Products mit Pflichtoptionen, preisverändernden oder bestandsrelevanten Optionen, Datei- oder Texteingaben sowie Quellvariantenlogik. Ein einfaches Product kann problemlos bestehen, während umsatzstarke komplexe Products versteckte Fehler enthalten. Die Stichprobe sollte Bestseller, margenstarke Products, Products mit mehreren Auswahlmöglichkeiten, individuellem Input und besonders präzisem Optionsverhalten enthalten.
| Product-Muster | Validierungsfokus | Fehlersignal |
|---|---|---|
| Products mit Pflichtoption | Pflichtauswahl erscheint und verhindert unvollständigen Kauf korrekt. | Customers können unvollständige Products hinzufügen oder gültige Auswahl nicht abschließen. |
| Preisverändernde Optionen | Preiswirkung entspricht der Geschäftslogik. | Auswahl verändert Preis falsch oder gar nicht. |
| Bestandsrelevante Optionen | Bestand folgt dem tatsächlichen Verkaufsmodell. | Ausverkaufte Auswahl bleibt verfügbar oder gültige Auswahl verschwindet. |
| Text-/Dateieingabe | Customer-Eingaben bleiben verständlich und nutzbar. | Felder fehlen, sind unklar oder werden nicht wie erwartet gespeichert. |
| Quellvarianten als Optionen | Zielstruktur bleibt nachvollziehbar. | Variantenbedeutung wird in unverständlichen Optionslabels zusammengedrückt. |
Ein Product besteht nicht schon deshalb, weil es vorhanden ist. Es besteht, wenn Customers die beabsichtigte Auswahl erkennen, in sinnvoller Reihenfolge treffen, Preis- und Bestandswirkung verstehen und den Kaufpfad ohne Raten abschließen können.
Validierungspriorität 2: Attribute, Filter und Product-Verständnis
OpenCart-Attribute und -Filter müssen getrennt validiert werden, weil sie unterschiedliche Aufgaben erfüllen. Attribute beschreiben und vergleichen Products. Filter helfen Customers, Product-Listen einzugrenzen. Werden Quelldaten ohne diese Unterscheidung übernommen, kann der Shop vollständig wirken und gleichzeitig die Produktsuche verschlechtern.
Prüfen Sie Attributgruppen, Attributwerte, Filtergruppen, Filterwerte und Product-Zuordnungen auf fachliche Sinnhaftigkeit. Besonders wichtig sind Categories, in denen technische Spezifikationen, Größen, Kompatibilitätsdaten, Herstellerinformationen oder andere strukturierte Merkmale die Kaufentscheidung unterstützen.
Ein starker Test führt von Category-Navigation über Filterung bis zum Product-Vergleich. Können Customers eine Liste mit sinnvollen Filtern eingrenzen und anschließend Unterschiede anhand verständlicher Attribute bewerten, erfüllt die Struktur ihre Funktion. Wirken Filter willkürlich oder Attribute unlesbar, besteht Korrekturbedarf.
| Struktur | Validierungsfrage | Zu vermeiden |
|---|---|---|
| Attribute | Unterstützen Spezifikationen Product-Verständnis oder Vergleich? | Attribute als beliebigen migrierten Text behandeln. |
| Attributgruppen | Sind Spezifikationen für Customers logisch gruppiert? | Unabhängige Merkmale in einen Block mischen. |
| Filter | Bieten sie sinnvolle Eingrenzung innerhalb von Categories? | Filter, die vorhanden sind, aber nicht zur Kaufabsicht passen. |
| Hersteller | Unterstützt Marken-/Herstellerkontext Navigation und Vertrauen? | Herstellerdaten sind vorhanden, aber von Product-Pfaden getrennt. |
Diese Prüfung ist besonders wichtig, wenn der Quellshop individuelle Felder, erweiterungsgesteuerte Filter oder improvisierte Variantenstrukturen nutzte. Native OpenCart-Felder können Informationen speichern; Validierung muss zeigen, dass deren Shopoberflächen-Bedeutung weiterhin nützlich ist.
Validierungspriorität 3: Kontinuität von Categories, Herstellern und Navigation
Category-Validierung sollte Customer-Pfade prüfen. Ein Category-Baum kann auf Record-Ebene korrekt migriert sein und dennoch die Art verändern, wie Customers Products finden. Product-Platzierung, Parent-Child-Beziehungen, Sortierung, Herstellerkontext, Menüsichtbarkeit und Filterverfügbarkeit bestimmen gemeinsam die Qualität der Navigation.
Die Stichprobe sollte stark besuchte und umsatzrelevante Categories, tiefe Unterstrukturen, filterabhängige Bereiche sowie Categories mit wichtigem Herstellerkontext enthalten. Reviewer sollten wie Customers vorgehen: Shopoberfläche öffnen, Product-Menge eingrenzen, Products öffnen, Details vergleichen und prüfen, ob die Category weiterhin eine konsistente Product-Gruppe vermittelt.
| Prüfpunkt | Starkes Bestehenskriterium |
|---|---|
| Parent-Child-Struktur | Customers können natürlich von breiter Category zu spezifischer Product-Menge gelangen. |
| Product-Zuordnung | Wichtige Products erscheinen im richtigen kommerziellen Kontext. |
| Filterverfügbarkeit | Eingrenzung entspricht den Product-Merkmalen, die Customers tatsächlich vergleichen. |
| Herstellerbeziehung | Markenkontext unterstützt bei Bedarf Navigation und Vertrauen. |
| SEO-Ziel | Category-Routen erhalten kommerzielle Bedeutung, nicht nur technische Erreichbarkeit. |
Gerade die vergleichsweise einfache OpenCart-Oberfläche kann ein falsches Sicherheitsgefühl erzeugen. Eine Category sollte erst bestehen, wenn sie mindestens denselben sinnvollen Navigationspfad wie im Quellshop ermöglicht.
Validierungspriorität 4: Kundengruppen und unterschiedliche Customer-Behandlung
Customer-Prüfung darf nicht bei vorhandenen Konten enden. OpenCart-Kundengruppen beeinflussen Organisation und können Rabatte, Sonderpreise oder andere differenzierte Behandlung steuern. Nutzt der Quellshop Großhandelsgruppen, Retail-Gruppen, Mitgliedspreise, Segmente oder Freigabeprozesse, muss der Zielkontext gezielt geprüft werden.
Testen Sie repräsentative Customers aus jeder relevanten Gruppe. Prüfen Sie Identität, Adressen, sichtbare Order-Historie, Gruppenzuordnung und gruppenabhängige Shopoberflächen-Ergebnisse. Sind Kundengruppen mit Rabatten, Sonderpreisen, Steuererwartungen oder Zugriff verbunden, benötigen diese Beziehungen eigene Nachweise statt eines allgemeinen Importchecks.
| Customer-Szenario | Validierungsfokus |
|---|---|
| Retail-Customers | Kontoidentität, Adressen, Order-Sichtbarkeit, gewöhnliches Shopverhalten. |
| Wholesale-/Trade-Customers | Gruppenzuordnung und abweichende Pricing- oder Zugriffserwartungen. |
| Customers mit historischen Orders | Order-Zuordnung, Statusbedeutung, Summen und Vertrauen in die Kontohistorie. |
| Customers mit Rabatten/Sonderpreisen | Funktioniert gruppenabhängige Geschäftslogik wie vorgesehen? |
Customer-Gruppenfehler sind oft weniger sichtbar als Product-Fehler. Sie können verborgen bleiben, bis ein bestimmter Customer sich anmeldet oder falsche Konditionen erhält.
Validierungspriorität 5: Orders, Status, Summen und Vertrauen
OpenCart-Order-Validierung muss zeigen, dass historische Orders verständlich und verlässlich bleiben. Name und Gesamtsumme allein reichen nicht. Erforderlich ist genügend Kontext für Customer Service, Buchhaltung, Auftragsabwicklung und das Vertrauen von Customers in ihre Kontohistorie.
Die Stichprobe sollte aktuelle und ältere Orders, hochwertige Orders, Orders mit Rabatten, komplexeren Steuer- und Versandpositionen, unterschiedlichen Status sowie wichtigen Kundengruppen umfassen. Prüfen Sie Customer-Zuordnung, Product-Zeilen, Optionslabels, Summen, Steuer- und Versanddarstellung, Statusbedeutung, Zahlungs-/Versandreferenzen soweit relevant und Sichtbarkeit im Customer-Konto.
Ein häufiger Fehler ist die Freigabe allein aufgrund gleicher Order-Anzahl. Stattdessen sollte ein Mitarbeiter die Order öffnen und nachvollziehen können, was gekauft wurde, welche Optionen gewählt wurden, wie sich der gezahlte Betrag zusammensetzt und wie der historische Status nach dem Launch zu interpretieren ist.
Validierungspriorität 6: SEO-Keywords, Routen und Qualität des Ziels
SEO-Validierung sollte auf Zielqualität ausgerichtet sein. OpenCart-SEO-Keywords können Products, Categories, Herstellern und Informationsseiten zugeordnet sein, doch Eindeutigkeit und richtige Zielseite sind wichtiger als bloße Wertepräsenz. Eine erreichbare Seite ist kein Pass, wenn sie Customer oder Suchmaschine auf eine schwächere, doppelte oder nicht mehr passende kommerzielle Absicht führt.
Die Stichprobe sollte stark besuchte Product- und Category-Seiten, Herstellerseiten, Informationsseiten, Kampagnenziele und bekannte Backlink-Ziele enthalten. Prüfen Sie für jede Route Erreichbarkeit, richtigen Inhalt, erhaltene kommerzielle Absicht und mögliche Keyword-Kollisionen.
| URL-/SEO-Prüfung | Was bewiesen werden muss |
|---|---|
| Product-SEO-Keywords | Hochwertige Product-Ziele bleiben klar und eindeutig. |
| Category-SEO-Keywords | Category-Routen unterstützen den vorgesehenen Navigationskontext. |
| Herstellerrouten | Markenbezogener Traffic landet in einem sinnvollen Product-Kontext. |
| Informationsseiten | Richtlinien-, Informations- und Vertrauensseiten bleiben erreichbar. |
| Redirect-sensitive Seiten | Wichtige externe oder suchgetriebene Pfade verlieren ihre Absicht nicht. |
SEO-Validierung sollte nicht zu einer generischen Redirect-Checkliste werden. Sie muss bestätigen, dass Keyword- und Routenentscheidungen weiterhin zum Katalog passen, den Customers tatsächlich verwenden.
Validierungspriorität 7: Erweiterungen, Modifikationen, Themes und Layouts
Viele OpenCart-Shops nutzen Erweiterungen, Modifikationen, Themes, individuelle Module oder Layoutzuordnungen. Manche betreffen nur Darstellung, andere Product-Daten, Kaufabschluss, Auswertungen, Feeds, Versand, Zahlung, Suche, Filter oder Kundenerlebnis. Validierung muss die geschäftskritischen Abhängigkeiten identifizieren und prüfen, ob das Ziel deren Ergebnis weiterhin unterstützt.
Erweiterungsverhalten darf nicht als gewöhnlicher Datensatztransfer vorausgesetzt werden. Jede Abhängigkeit wird nach Geschäftsbedeutung klassifiziert. Liegt eine erweiterungserzeugte Struktur außerhalb unterstützten Migrationsverhaltens, kann sie nicht standardisierte Prüfung, Zielkonfiguration oder manuelle Implementierung nach der Migration benötigen.
| Abhängigkeit | Validierungsfrage |
|---|---|
| Katalogerweiterungen | Funktionieren Product-, Options-, Filter- oder Darstellungsresultate weiterhin? |
| Erweiterungen für Kaufabschluss, Zahlung und Versand | Sind kritische Annahmen des Kaufpfads erhalten oder neu aufgebaut? |
| Feed- und Integrationsmodule | Sind Export-, Auswertungs-, Marktplatz- oder Synchronisationserwartungen noch gültig? |
| Theme-/Layoutänderungen | Werden migrierte Daten in einem brauchbaren Zielkontext dargestellt? |
| Modifikationen oder individueller Code | Ist das individuelle Verhalten vor Launch-Freigabe identifiziert? |
Diese Priorität verhindert, dass ein erweiterungsintensiver Shop so behandelt wird, als läge seine gesamte Geschäftslogik ausschließlich in nativen Product-, Category-, Customer- und Order-Datensätzen.
Repräsentative, breitere und spätere OpenCart-Ergebnisse validieren
Repräsentative Prüfungen sollten jene OpenCart-Strukturen abdecken, die kommerzielles Verhalten am stärksten verändern können: ein Product mit Pflicht- und optionaler Auswahl, Text-/Dateieingabe soweit verwendet, Preis- und Gewichtseffekt, eine filterabhängige Category, ein Customer in kommerziell relevanter Gruppe, eine Order mit mehreren Summenpositionen und Status, eine SEO-sensitive Route und ein Record mit Erweiterungs-, Event- oder Modifikationsabhängigkeit.
Die breitere Ausführung muss Vollständigkeit und Konsistenz über den freigegebenen Scope beweisen. Sie sollte seltene Optionstypen, deaktivierte Products, tiefe Categories, doppelte oder Gast-Customers, ältere Orders, individuelle Status, Returns soweit im Scope, Informationsseiten, Stores einer Multi-Store-Installation sowie Records aus Modulen oder externen Systemen umfassen. Historische Order-Nachweise bleiben strikt getrennt von aktiver Payment-, Shipping-, Steuer-, Subscription-, Return-, E-Mail- und Konfiguration des Kaufabschlusses.
| Nachweisstufe | OpenCart-Nachweis | Fehlersignal |
|---|---|---|
| Repräsentativer Migrationstest | Komplexe Products, Filter, Kundengruppen, Orders, Routen und erweiterungseigene Felder zeigen die vorgesehene Interpretation. | Die Stichprobe beweist nur einfache Products und gewöhnliche Orders. |
| Breitere Migrationsausführung | Vollständiger Scope und Ausnahmefälle folgen den freigegebenen Product-, Customer-, Order-, Routen- und Store-Beziehungen. | Summen stimmen, seltene Optionen, alte Orders, individuelle Status oder Erweiterungsrecords bleiben aber unerklärt. |
| Launch-Nachweise | Admin- und Shopoberflächen-Szenarien sind wiederholbar; jedes offene Thema besitzt Verantwortlichen und Entscheidung. | Der Zielshop benötigt weiterhin den Quellshop oder undokumentiertes Erweiterungsverhalten zur Interpretation. |
Eine spätere Migrationsaktion öffnet die jeweils betroffene Nachweisgrenze erneut:
| Spätere Aktion | OpenCart-Revalidierungsgrenze |
|---|---|
| Unter der akzeptierten Konfiguration fortfahren | Spätere Products, Optionen, Customers, Orders, Blog Posts, SEO-Routen, Store-Zuordnungen und Erweiterungsreferenzen gegen das freigegebene Modell prüfen. |
| Mit überarbeiteter Konfiguration fortfahren | Nachweise für jedes geänderte Filtering, Mapping, jede Datenkategorieauswahl, Optionsentscheidung, Store-Scope-Regel, individuelle Feldbehandlung und Routenregel wiederholen. |
| Ein eigenständiges neues Migrationsergebnis erzeugen | Für das eigenständige Ergebnis eine neue repräsentative und breitere Nachweisbasis erstellen. |
OpenCart-Nachweise als Pass, Watch oder Block klassifizieren
Die Launch-Freigabe sollte auf Szenarioebene Pass, Watch oder Block verwenden. Jedes Ergebnis muss das konkrete geprüfte Product, die Option, Category, Kundengruppe, Order, SEO-Route, Erweiterung, Modifikation, Event, Layout oder individuelle Feld identifizieren.
| Entscheidungsstatus | OpenCart-Nachweis | Bedeutung für den Launch |
|---|---|---|
| Pass | Migrierter Record und relevante OpenCart-Beziehungen funktionieren in Admin und Shopoberfläche wie vorgesehen. | Der geprüfte Bereich unterstützt den Launch. |
| Watch | Daten sind nutzbar, aber eine dokumentierte nicht blockierende Aufgabe zu Layout, Theme, Erweiterung, Merchandising, Inhalte oder Konfiguration bleibt offen. | Launch kann mit Verantwortlichem und Follow-up-Bedingung erfolgen. |
| Block | Ein wesentliches Product ist nicht konfigurier- oder kaufbar, Kundengruppenverhalten ist falsch, Order-Historie irreführend, eine priorisierte Route fällt aus oder vereinbarte Ausgabe ist unbrauchbar. | Freigabe stoppt für den betroffenen Bereich. |
Gekaufte freigegebene Migrationsergebnisse müssen gegen vereinbarte Filter, Mappings oder Konfiguration geprüft werden. Vereinbarte nicht standardisierte Ausgabe wird gegen akzeptierte erweiterungseigene Daten, individuelle Tabellen, Felder, externe Identifier, transformierte Optionen oder besondere Beziehungen geprüft. Eine OpenCart-Erweiterung kann weiterhin separat installiert und konfiguriert werden müssen, selbst wenn ihre historischen oder referenziellen Daten korrekt migriert wurden.
Die finale Übergabe sollte Migrationskorrekturen, OpenCart-Konfiguration, Theme-/Layout-Arbeit, Erweiterungsverantwortung, manuelle Bereinigung, akzeptierte Unterschiede und separate Implementierung voneinander trennen. So werden korrekt migrierte Daten nicht unnötig verändert und offene Betriebsprobleme nicht fälschlich als Pass behandelt.
Fazit
OpenCart-Validierung muss beweisen, dass die Zielplattform kommerziell nutzbar bleibt und nicht nur Daten enthält. Die stärkste Prüfung konzentriert sich auf Product-Auswahl, Katalognavigation, Kundengruppen, Vertrauenswürdigkeit historischer Orders, SEO-Routen, Erweiterungsabhängigkeiten und belastbare Launch-Nachweise. Jeder Bereich sollte zeigen, ob OpenCart die migrierten Daten so ausdrückt, dass Customers und interne Teams sie sicher nutzen können.
Für einen stabileren Launch beginnt die Prüfung mit Records, deren Bedeutung am ehesten kippen kann: optionsreiche Products, filterabhängige Categories, Kundengruppen, wichtige SEO-Routen, historische Orders und durch Erweiterungen geprägtes Verhalten. Bestehen diese Bereiche mit klaren Nachweisen, ist das Migrationsergebnis deutlich belastbarer.
Häufige Fragen
Welche OpenCart-Products sollten in repräsentativen Testnachweisen enthalten sein?
Products mit Pflicht- und optionaler Auswahl, Preis- oder Gewichtsanpassungen, Text-/Dateieingabe, filterrelevanten Attributen, mehreren Categories, Kundengruppenwirkung und erweiterungseigenen Feldern. Einfache Products allein zeigen die wichtigsten OpenCart-Beziehungsrisiken nicht.
Warum werden OpenCart-Attribute, -Filter und -Optionen getrennt validiert?
Optionen steuern Customer-Auswahl und können Preis, Gewicht oder Pflichtinput beeinflussen. Attribute beschreiben Products; Filter unterstützen die Produktsuche. Eine Migration kann die Labels erhalten und sie trotzdem der falschen Funktion zuordnen.
Wie sollten historische OpenCart-Orders validiert werden?
Prüfen Sie Positionen, gewählte Optionen, Summen, Rabatte, Steuern, Versand, Zahlungslabels, Status, Daten, Customer-Kontext und externe Referenzen. Lesbare historische Orders beweisen nicht, dass aktuelle Payment-, Shipping-, Steuer-, Return- oder Konfiguration des Kaufabschlusses bereit ist.
Was unterscheidet Watch von Block bei einer erweiterungsabhängigen Feststellung?
Watch gilt, wenn die migrierten Daten korrekt sind und nur eine dokumentierte nicht blockierende Erweiterungs- oder Layoutkonfiguration fehlt. Block gilt, wenn die fehlende Beziehung ein wichtiges Product, einen Customer, eine Order, eine Route oder vereinbarte Ausgabe unbrauchbar oder irreführend macht.
Wie sollten OpenCart-Modifikationen und Events in der Validierung behandelt werden?
Identifizieren Sie das Geschäftsverhalten und die Records, für die sie verantwortlich sind. Prüfen Sie migrierte Daten und externe Identifier getrennt von der Code-Implementierung. Quellmodifikationen oder Events werden nicht automatisch als gewöhnliche Daten übertragen.
Was muss nach einer späteren OpenCart-Migrationsaktion erneut validiert werden?
Jede betroffene Option, jeder Filter, jede Kundengruppe, Order, Store-Zuordnung, SEO-Route, jeder Erweiterungsrecord und jedes individuelle Feld. Geänderte Konfiguration oder ein eigenständiges neues Ergebnis erfordern eine breitere Nachweisbasis als eine unveränderte Fortsetzung.