Bei der Bewertung von VirtueMart als möglicher Zielplattform richtet sich die Wahl des Migrationsansatzes nach Datenumfang, Zielanforderungen und Validierungsbedarf. Die Wahl des richtigen Migrationsansatzes für VirtueMart erfordert ein Verständnis dafür, wie Commerce-Datensätze mit Joomla, Custom Fields, Shopper-Gruppen, Berechnungsregeln, Zahlungs- und Versand-Plugins, Templates und Erweiterungen zusammenwirken. Ein Shop kann gewöhnliche Produkte und Bestellungen enthalten und zugleich Custom Fields für Varianten, Plugins für Transaktionskontext, Shopper-Gruppen für Preislogik sowie Joomla-Menüs oder -Module für die Shop-Navigation benötigen. Diese Beziehungen bestimmen den passenden Service-Pfad stärker als die reine Anzahl der Datensätze.
Standard Service kann für saubere unterstützte Daten geeignet sein, wenn der Kunde den Service selbst bedienen und validieren kann. Managed Service ist sicherer, wenn Ausführung und Prüfung anspruchsvoll sind. Add-ons decken klar begrenzte Anforderungen an Datensatzfilterung, Werttransformation oder Feldzuordnung innerhalb unterstützten Verhaltens ab. Custom Service behandelt nicht unterstützte Datensätze, Erweiterungstabellen, Custom Fields mit individueller Interpretationsanforderung, externe Kennungen und individuelle Migrationslogik.
Innerhalb der Next-Cart Migrationsservices sollten die VirtueMart-Nachweise zwischen unterstützten Commerce-Datensätzen, expertengestützter Ausführung, begrenzten Add-ons, Joomla-Abhängigkeiten und erweiterungsspezifischer individueller Behandlung unterscheiden.
Den VirtueMart-Betriebsumfang definieren
VirtueMart ist eine Joomla-E-Commerce-Erweiterung mit eigenen Strukturen für Produkte, Kategorien, Kunden, Bestellungen, Hersteller, Bestand, Gutscheine, Steuern, Berechnungsregeln, Zahlung, Versand und Konfiguration. Die Joomla-Umgebung stellt Benutzer, Zugriffe, Menüs, Sprachen, Templates, Module und Website-Routing bereit. Plugins und Custom Fields können Kaufverhalten, Preis, Versand, Zahlung und Bestelldetails verändern.
| Umfangsbereich | Signal für geringere Komplexität | Signal für höhere Komplexität |
|---|---|---|
| Produktmodell | Einfache Produkte mit Standardkategorien, Preisen, Bestand und Bildern | Parent-Child-Produkte, Custom Fields, Variantenverhalten, Downloads, individuelle Preislogik oder Plugin-erzeugte Beziehungen |
| Shopper-Modell | Normale Shopper und Adressen | Shopper-Gruppen, Gruppenpreise, individuelle Shopper-Felder, Zugriffsregeln oder externe Kontokennungen |
| Bestellhistorie | Standardpositionen, Summen, Status sowie Zahlungs- und Versandlabels | Plugin-eigene Transaktionsdetails, individuelle Bestellfelder, Teilzahlungen, eigene Statuslogik oder externe Fulfillment-Verknüpfungen |
| Berechnung | Konventionelle Steuern und Rabatte | Komplexe Berechnungsregeln, Shopper-Gruppen-Bedingungen, eigene Plugins oder quellenspezifische Preislogik |
| Joomla-Kontext | Einfache Menü- und Template-Beziehungen | Mehrsprachiges Routing, Module, Overrides, individuelle Komponenten, komplexe URLs oder gemeinsame Inhaltsabhängigkeiten |
Der Service-Pfad sollte erst gewählt werden, nachdem der Händler festgelegt hat, welche Betriebsbereiche nach der Migration weiterhin nutzbar sein müssen. Das Ziel darf nicht so behandelt werden, als würde es jedes VirtueMart-Plugin oder jede Joomla-Implementierung reproduzieren, nur weil die zugrunde liegenden Produkt- und Bestelldatensätze vorhanden sind.
Wann Standard Service ausreichen kann
Standard Service kann geeignet sein, wenn der Migrationspfad unterstützt wird und die benötigten Datensätze in das normale Migrationsverhalten passen. Bei diesem Next-Cart Service ist der Kunde für Konfiguration, Migrationsausführung und Validierung verantwortlich.
Ein guter Kandidat für Standard Service hat typischerweise:
- erkennbare Produkte, Kategorien, Hersteller, Kunden, Bestellungen und Gutscheine;
- eindeutige Produktkennungen, Preise, Bestände und Bilder;
- begrenzte Nutzung von Custom Fields und Parent-Child-Beziehungen;
- normale Shopper-Datensätze und Adressen;
- verständliche Bestellsummen, Status, Zahlungslabels und Versandlabels;
- einen definierten Zielansatz für Steuern, Versand, Zahlung und Checkout-Konfiguration;
- geringe Abhängigkeit von Erweiterungstabellen oder individuellen Joomla-Komponenten;
- ein Team, das Ergebnisse von Demo Migration und Full Migration prüfen kann.
Standard Service bedeutet nicht, dass Payment Gateways, Versand-Plugins, Berechnungsregeln, Templates oder Joomla-Module neu erstellt werden. Diese Bereiche gehören zur Zielkonfiguration oder Implementierung, sofern der vereinbarte Migrationsumfang nicht ausdrücklich unterstützte Datensätze daraus einschließt.
Ein großer konventioneller Katalog kann mit dem passenden Entity Points Plan weiterhin für Standard Service geeignet sein. Ein kleiner Katalog kann Custom Service benötigen, wenn Custom Fields mit nicht standardisierter Interpretationsanforderung, Plugins oder externe Systeme die eigentliche geschäftliche Bedeutung tragen.
Wann Managed Service die sicherere Wahl ist
Managed Service eignet sich, wenn die Daten grundsätzlich unterstützt werden, der Händler aber Next-Cart-Spezialisten für Ausführung und koordinierte Validierung benötigt. VirtueMart-Projekte profitieren davon häufig, wenn Commerce-Verantwortlicher, Joomla-Administrator und Implementierungspartner unterschiedliche Teams sind.
Managed Service kann sicherer sein, wenn:
- der Händler die Migration nicht sicher selbst bedienen kann;
- der Shop einen großen Katalog oder eine lange Bestellhistorie besitzt;
- Shopper-Gruppen, mehrere Sprachen oder verschiedene Produktmuster koordinierte Stichproben erfordern;
- der Launch-Zeitplan wenig Spielraum für Ausführungsfehler lässt;
- Quelldaten unterstützt, aber inkonsistent sind;
- mehrere Teams Katalog-, Kunden-, Bestell-, Content- und SEO-Ergebnisse freigeben müssen;
- Expert Handle als Teil des Service-Plans benötigt wird.
Managed Service verändert die Ausführungsverantwortung, nicht die Plattformunterstützung. Nicht unterstützte Custom-Field-Logik, Erweiterungsdaten oder Beziehungen zu externen Systemen benötigen weiterhin eine Prüfung durch Custom Service.
Wann Add-ons den Ansatz unterstützen können
Add-ons sind sinnvoll, wenn die Kernmigration unterstützt wird und eine klar begrenzte Anforderung das gewünschte Ergebnis verändert. Beispiele sind:
- Bedingungen auf Produkt-, Kunden- oder Bestellfeldern über Data Filter anwenden;
- Ausdrücke verwenden, um unterstützte Feldwerte über Data Transformation zu transformieren;
- unterstützte Standard-Quellfelder mit unverändertem Wert über Advanced Data Mapping auf kompatible unterstützte Zielfelder abbilden;
- unterstützte Quell-Datenbankspalten mit unveränderten Werten über Advanced Database Mapping auf kompatible VirtueMart-Datenbankspalten abbilden, sofern auch die Quellplattform Open Source ist;
- unterstützte Content- oder SEO-bezogene Datensätze auswählen;
- jeden gefilterten Datensatzbestand, transformierten Wert und jedes neu zugeordnete Feld gegen ein definiertes Ergebnis validieren.
Add-ons sollten nicht verwendet werden, um individuelle Extraktion aus VirtueMart-Plugin-Tabellen oder maßgeschneiderte Logik für nicht unterstützte Felder zu beschreiben. Ein unterstütztes Standard-Quellfeld mit unverändertem Wert auf ein kompatibles unterstütztes Zielfeld umzulegen kann in Advanced Data Mapping passen. Bei einer Migration zu VirtueMart kann unterstützte Datenbankspalten-Zuordnung nur dann in Advanced Database Mapping passen, wenn die Quellplattform ebenfalls Open Source ist. Die Rekonstruktion eines Custom-Field-Plugins, das Produktauswahl oder Preislogik steuert, benötigt normalerweise eine Prüfung durch Custom Service und kann zusätzlich separate Zielimplementierung erfordern.
Die Entscheidung sollte an der Grenze zwischen unterstütztem Migrationsverhalten und angepasster nicht standardisierter Arbeit ausgerichtet werden.
Wann Custom Service geprüft werden sollte
Custom Service sollte geprüft werden, wenn das benötigte Ergebnis von Daten oder Logik außerhalb standardmäßig unterstützter Strukturen abhängt. Bei VirtueMart entsteht dieser Druck häufig durch Custom Fields, deren benötigte Behandlung den unterstützten Zuordnungsumfang überschreitet, durch Plugins, Berechnungsregeln, Joomla-Erweiterungen und langjährig gewachsene Anpassungen.
Eskalationssignale sind unter anderem:
- individuelle Produktfelder oder Plugins für Varianten, Personalisierung, Bundles oder Preislogik;
- Parent-Child-Produktbeziehungen, die eine individuelle Umstrukturierung benötigen;
- Shopper-Gruppen-Preise oder Zugriffslogik ohne direktes Zieläquivalent;
- individuelle Shopper-Felder oder Kontobeziehungen;
- Steuer- und Berechnungsregeldaten, die Transformation statt historischer Referenz benötigen;
- Zahlungs- oder Versand-Plugin-Tabellen mit benötigten Transaktionsdetails;
- individuelle Bestellfelder, Statushistorie, Erstattungen oder externe Fulfillment-Referenzen;
- Joomla-Module, Komponenten, Aliasse oder mehrsprachige Beziehungen, die das benötigte Ergebnis beeinflussen;
- ERP-, Buchhaltungs-, Marktplatz-, Warehouse- oder CRM-Kennungen;
- Datenbankspaltenanforderungen außerhalb der unterstützten Bedingungen für Advanced Database Mapping oder modifizierter VirtueMart-Code;
- eine individuelle Plattform oder individuelle Migrationslogik.
Custom Service umfasst nicht automatisch VirtueMart-Installation, Joomla-Upgrades, Plugin-Entwicklung, Rekonstruktion von Templates oder Overrides, Einrichtung von Steuerregeln, Zahlungs- und Versandkonfiguration, Deployment von Integrationen oder den vollständigen Aufbau eines Zielshop. Diese Verantwortlichkeiten müssen ausdrücklich vereinbart werden.
Entity Points und VirtueMart-Umfang planen
Entity Points dienen der Kapazitätsplanung für berechtigte migrierte Datensätze. Bei späteren VirtueMart-Aktivitäten bleiben bereits gezählte berechtigte Datensätze auf demselben Migrationspfad einmal gezählt; Komplexität durch Joomla, Custom Fields, Shopper-Gruppen und Plugins wird separat bewertet. Kategorien, Hersteller, Bewertungen, Gutscheine, Custom Fields, Shopper-Gruppen, Berechnungsregeln, Zahlungs-Plugins, Versand-Plugins, CMS Pages und externe Kennungen können die Komplexität erhöhen, ohne eigene gezählte Datenkategorien zu werden.
Für VirtueMart zählen neue berechtigte Products, Customers, Orders und Blog Posts beim ersten Migrieren zu Entity Points. Joomla-Inhalte, Custom Fields, Shopper-Gruppen, Berechnungsregeln, Plugin-Datensätze und externe Kennungen können Komplexität hinzufügen, ohne zusätzliche gezählte Datensatztypen zu erzeugen; eine spätere Aktion auf demselben Pfad zählt bereits berücksichtigte Datensätze nicht erneut.
| Umfangsbedingung | Auswirkung auf Entity Points | Auswirkung auf Komplexität |
|---|---|---|
| Viele konventionelle Produkte | Erfordert passende Kapazität | Kann Standard bleiben, wenn Produktbedeutung klar ist |
| Wenige Produkte mit komplexen Custom Fields außerhalb des unterstützten Zuordnungsumfangs | Geringeres Volumen | Kann Custom Service erfordern |
| Neue Bestellungen vor dem Launch | Können beim ersten Migrieren Entity Points verbrauchen | Erfordern Validierung von Status, Summe, Zahlung und Versand |
| Bereits vorhandene Datensätze werden erneut verarbeitet | Kein doppelter Verbrauch allein wegen einer weiteren Aktion | Zielkonfiguration muss weiterhin gültig bleiben |
Entity Points sollten vor Full Migration bewertet werden, dürfen aber nicht als Maß für Plugin- oder Anpassungskomplexität in VirtueMart dienen.
Was Demo Migration klären sollte
Demo Migration sollte die anspruchsvollsten VirtueMart-Datensätze prüfen. Repräsentative Stichproben sollten umfassen:
- einfache Produkte sowie Produkte mit Parent-Child- oder Custom-Field-Beziehungen;
- Produkte mit unterschiedlichen Preisen, Bestandsregeln, Herstellern, Kategorien und Bildern;
- Shopper aus wichtigen Shopper-Gruppen;
- Kunden mit individuellen Shopper-Feldern oder mehreren Adressen;
- Bestellungen mit Steuern, Rabatten, Gutscheinen, Zahlung, Versand, Statusänderungen und ungewöhnlichen Summen;
- Datensätze mit Plugin-eigenen oder externen Systemkennungen;
- mehrsprachige Produkte, Kategorien, Inhalte und URLs;
- priorisierte Joomla-Menüs, Aliasse, CMS Pages und Blog Posts.
Demo Migration sollte belegen, ob der gewählte Ansatz nutzbare Produkt-, Kunden- und Bestellbedeutung bewahrt. Sie sollte außerdem zeigen, welche Lücken zu folgenden Kategorien gehören:
- Verantwortlichkeiten der Zielkonfiguration;
- begrenzte Add-on-Anforderungen;
- Anforderungen an Custom Service;
- separate Joomla- oder VirtueMart-Implementierungsarbeit.
Der Service-Pfad sollte vor Full Migration angepasst werden, wenn die Stichprobe zeigt, dass Custom Fields, Shopper-Gruppen, Berechnungsregeln oder Plugin-Datensätze unterschätzt wurden.
Optionen für spätere Migrationen für VirtueMart
Optionen für spätere Migrationen unterstützen spätere Aktivitäten, wenn die Quelle aktiv bleibt oder der Händler das Zielergebnis verändert. Alle drei Aktionen bleiben innerhalb des festen Quellplattform-Zielplattform-Migrationspfads des gekauften Migrationsservice. Ein anderer Plattformpfad erfordert einen separat gekauften Migrationsservice.
| Aktuelle Aktion | Geeignete Situation | Fokus der VirtueMart-Revalidierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Akzeptierter Umfang und Zuordnungen bleiben gültig und spätere Datensätze sollen dieselbe Konfiguration verwenden. | Neue Products, Customers, Orders, Blog Posts, Custom-Field-Werte, Shopper-Gruppen, URLs und externe Kennungen. |
| Continue the Migration with a New Configuration | Der Migrationspfad bleibt gleich, aber unterstützte Filter, Zuordnungen oder Zieleinstellungen müssen geändert werden. | Produktbeziehungen, Custom-Field-Zuordnung, Shopper-Behandlung, Bestellstatus, Content-Auswahl, URLs und Ausschlüsse. |
| Perform a New Migration | Ein eigenständiges Zielergebnis ist erforderlich, statt die frühere Einrichtung fortzuführen; der gekaufte Quellplattform-Zielplattform-Migrationspfad bleibt unverändert. | Vollständiger Produkt-, Shopper-, Bestell-, Content-, Joomla-, Plugin-, SEO- und Abnahmeumfang. |
Diese Aktionen installieren VirtueMart nicht, erstellen Plugins nicht neu, konfigurieren keine Steuern, Zahlung oder Versand, bauen keine Templates neu auf und deployen keine Integrationen automatisch. Sie arbeiten innerhalb des vereinbarten Migrationsserviceumfangs.
Datenübertragung von VirtueMart- und Joomla-Konfiguration trennen
VirtueMart-Projekte lassen sich leichter abgrenzen, wenn migrierte Datensätze von der Konfiguration und Implementierung getrennt werden, die den Zielshop betriebsfähig machen. Der Service-Pfad sollte Verantwortung explizit zuweisen.
| Anforderung | Primäre Verantwortung | Migrationsbetrachtung |
|---|---|---|
| Unterstützte Product-, Customer-, Order- und Blog-Posts-Datensätze | Migrationsservice | Plattformunterstützung, Entity Points, Zuordnung und Abnahmekriterien bestätigen. |
| Kategorien, Hersteller, Custom-Field-Werte, Shopper-Beziehungen und historische Summen | Migration und Validierung | Bestimmen, welche Beziehungen unterstützt sind und welche angepasste Behandlung benötigen. |
| Steuern, Berechnungsregeln, Währungen, Zahlung, Versand, Status und Checkout | VirtueMart-Konfiguration und Provider | Historischen Kontext im vereinbarten Umfang bewahren; Live-Verhalten separat konfigurieren. |
| Joomla-Benutzer, Menüs, Sprachen, Module, Templates und Aliasse | Website-Implementierung | Mit migrierten Datensätzen koordinieren, ohne einen Joomla-Site-Rebuild als enthaltenen Migrationsumfang zu behandeln. |
| Custom-Field-, Zahlungs-, Versand- und Berechnungs-Plugins | Erweiterungs- oder Entwicklungsverantwortlicher | Individuelle Datenextraktion von Plugin-Installation und Verhaltensrekonstruktion trennen. |
| ERP-, Buchhaltungs-, Fulfillment-, Marktplatz- und CRM-Verbindungen | Integrationsverantwortlicher | Vereinbarte Kennungen bewahren und Systeme unabhängig neu deployen oder verbinden. |
Beispielsweise kann eine Bestellung mit Zahlungslabel und historischer Summe migriert werden, während das Live-Zahlungs-Plugin separat eingerichtet werden muss. Ein Produkt kann einen Custom-Field-Wert bewahren, während Zielselektor oder Preisverhalten weiterhin Plugin-Konfiguration benötigen. Das sind keine Widersprüche, sondern unterschiedliche Verantwortungsschichten.
Diese Klassifikation sollte sich in Abnahmekriterien widerspiegeln. Die Migrationsabnahme prüft vereinbarte Daten und Beziehungen. Die Implementierungsabnahme der Zielplattform prüft Live-Steuern, Zahlung, Versand, Checkout, Templates und Integrationen. Custom Service sollte nur für konkret identifizierte nicht standardisierte Daten oder individuelle Transformationsanforderungen eingesetzt werden.
Szenariobasierte Service-Diagnose
Szenario 1: Konventionelle VirtueMart-Datensätze. Produkte, Shopper und Bestellungen nutzen Standardstrukturen, Custom Fields sind einfach und der Händler kann den Prozess selbst steuern. Standard Service kann geeignet sein, nachdem Demo Migration repräsentative Datensätze bestätigt hat.
Szenario 2: Standardumfang mit hohem Koordinationsaufwand. Mehrere Shopper-Gruppen, Sprachen, eine große Bestellhistorie und ein fester Launch-Termin erfordern Spezialistenausführung und Prüfung durch mehrere Teams. Managed Service kann sicherer sein, obwohl die Daten unterstützt bleiben.
Szenario 3: Begrenzte unterstützte Anpassungen. Der Händler muss ausgewählte Produkte anhand von Produktfeldbedingungen filtern, Bestellbereiche über Bestellfeldbedingungen ausschließen, unterstützte Standard-Quellfelder mit unveränderten Werten auf kompatible unterstützte Zielfelder abbilden oder berechtigte Datenbankspalten über Advanced Database Mapping zuordnen, wenn die Quellplattform ebenfalls Open Source ist. Data Filter, Advanced Data Mapping oder Advanced Database Mapping können diese definierten Anforderungen lösen, ohne jede VirtueMart-Anpassung als individuelle Migrationsarbeit zu behandeln.
Szenario 4: Plugin-gesteuertes Produktverhalten. Custom Fields oder Plugins bestimmen Varianten, Personalisierung, Bundles oder Preislogik. Prüfen Sie zunächst unterstützte Feldzuordnung und Data Transformation; Custom Service sollte geprüft werden, wenn benötigte Plugin-eigene Daten, Beziehungen, Interpretation oder Transformation die Grenzen des Standard Add-on überschreiten. Installation und Shop-Verhalten des Plugins in der Zielplattform bleiben Implementierungsaufgaben, sofern sie nicht ausdrücklich enthalten sind.
Szenario 5: Historische Bestellungen hängen von Plugin-Details ab. Zahlungs-, Versand-, Teilzahlungs- oder externe Fulfillment-Datensätze liegen außerhalb normaler Bestellfelder. Die benötigte historische Bedeutung sollte mit Beispielen dokumentiert und vor Full Migration durch Custom Service geprüft werden.
Szenario 6: Änderungen am Folgeumfang. Wenn das akzeptierte Zuordnung weiterhin korrekt ist, verwenden Sie Last Used Configuration. Wenn unterstützte Produkt-, Shopper-, Bestell- oder Content-Behandlung geändert werden muss, verwenden Sie New Configuration. Wenn der Händler ein eigenständiges Zielergebnis benötigt, wählen Sie Perform a New Migration und wiederholen Sie die vollständige Validierung.
Ein Szenario sollte Datensatzkennungen, erwartete Zielergebnisse und das für alle Nicht-Migrationsaufgaben verantwortliche Team enthalten. Diese Nachweise machen den gewählten Ansatz proportional zum tatsächlichen Risiko statt zum allgemeinen Ruf oder Alter der Plattform.
Abschließende Entscheidung über den VirtueMart-Service-Pfad
| Nachweis | Wahrscheinlicher Service-Pfad |
|---|---|
| Unterstützte Datensätze, normale Produkt- und Shopper-Strukturen, kundengeführte Bedienung | Standard Service |
| Unterstützter Umfang mit hohem Ausführungs-, Koordinations- oder Validierungsaufwand | Managed Service |
| Klar begrenzte unterstützte Anforderungen an Datensatzfilterung, Werttransformation oder Feldzuordnung | Standard oder Managed Service mit Add-ons |
| Custom-Field-Anforderungen außerhalb unterstützten Add-on-Verhaltens, Plugin-Tabellen, Berechnungslogik, individuelle Transformation oder externe Systemabhängigkeiten | Custom Service, gegebenenfalls mit Expert Handle und vereinbarten Add-ons |
Die Entscheidung sollte vor Full Migration bestätigt und über Demo Migration getestet werden. Der stärkste Ansatz ist der leichteste Service-Pfad, der die benötigte geschäftliche Bedeutung bewahren und ein vom Händler verlässlich validierbares Zielergebnis erzeugen kann. Der genehmigte Plan sollte gewählten Service, Add-ons, Anforderungen an Custom Service, Entity Points Plan, Validierungsverantwortliche, Zielkonfiguration, Plugin-Verantwortlichkeiten und Additional Migration Option benennen. Jede noch nicht belegte Custom-Field- oder Plugin-Abhängigkeit bleibt offen, bis repräsentative Nachweise bestehen.
Fazit
Die Wahl des VirtueMart-Migrationsansatzes hängt vom Zusammenspiel unterstützter Commerce-Datensätze, Joomla-Kontext, Custom Fields außerhalb des unterstützten Zuordnungsumfangs, Shopper-Gruppen, Berechnungsregeln, Plugins und Zielkonfiguration ab. Standard Service eignet sich für saubere unterstützte Pfade. Managed Service reduziert den Ausführungsaufwand. Add-ons behandeln klar begrenzte unterstützte Anforderungen. Custom Service adressiert angepasste und nicht standardisierte Anforderungen.
Bei späteren VirtueMart-Aktivitäten sollte die Konfiguration nur so lange beibehalten werden, wie die akzeptierten Annahmen zu Joomla, Custom Fields, Shopper-Gruppen und Plugins weiterhin gelten; andernfalls muss die Konfiguration überarbeitet oder ein eigenständiges Migrationsergebnis erzeugt werden.
Häufige Fragen
Kann VirtueMart Standard Service verwenden?
Ja. Standard Service kann funktionieren, wenn der Migrationspfad unterstützt wird, Products, Customers und Orders erkennbare Strukturen verwenden und der Kunde den Service eigenständig bedienen und validieren kann.
Wann sollte Managed Service für eine VirtueMart-Migration gewählt werden?
Managed Service ist sinnvoll, wenn die Daten grundsätzlich unterstützt sind, Ausführung, Koordination oder Validierung aber anspruchsvoll sind, insbesondere über Commerce- und Joomla-Teams hinweg.
Können Add-ons VirtueMart-Custom-Fields behandeln?
Nur wenn die Anforderung innerhalb einer unterstützten Add-on-Grenze liegt. Ein unterstütztes Standard-Quellfeld kann mit unverändertem Wert über Advanced Data Mapping auf ein kompatibles unterstütztes Zielfeld abgebildet und ein unterstützter Wert über einen definierten Data Transformation-Ausdruck transformiert werden. Bei einer Migration zu VirtueMart kann unterstützte Datenbankspalten-Zuordnung nur dann Advanced Database Mapping verwenden, wenn die Quellplattform ebenfalls Open Source ist. Plugin-gesteuerte Custom Fields, deren benötigte Behandlung den unterstützten Zuordnungsumfang überschreitet, oder individuelles Produktverhalten benötigen normalerweise eine Prüfung durch Custom Service.
Was sollte Demo Migration für VirtueMart belegen?
Sie sollte Produktbeziehungen, Custom Fields, Shopper-Gruppen-Kontext, Kunden- und Bestellbedeutung, mehrsprachige Inhalte, URLs und Plugin-verknüpfte Kennungen belegen und alle Lücken vor Full Migration klassifizieren.
Welche Additional Migration Option passt zu einem VirtueMart-Folgevorhaben?
Verwenden Sie bei VirtueMart die akzeptierte Konfiguration nur weiter, wenn Annahmen zu Produkten, Custom Fields, Shopper-Gruppen und Plugins weiterhin gelten. Ändern Sie die Konfiguration, wenn unterstützte Zuordnungen angepasst werden, und verwenden Sie Perform a New Migration, wenn auf demselben gekauften Quellplattform-Zielplattform-Migrationspfad ein eigenständiges Zielergebnis erforderlich ist. Ein anderer Plattformpfad erfordert einen separat gekauften Migrationsservice.