Wenn Joomla als Zielplattform bewertet oder ausgewählt wird, hängt der richtige Migrationsansatz davon ab, welche Strukturen und Beziehungen diese Zielumgebung erhalten muss. Eine einfache Inhaltsmigration kann überschaubar bleiben, wenn Articles, Categories, Menus, Users und Media sauber strukturiert sind. Anspruchsvollere Projekte können dagegen Access Levels, mehrsprachige Beziehungen, Module Assignments, Template-Abhängigkeiten, Commerce-Komponenten, erweiterungseigene Datensätze, benutzerdefinierte Felder, individuelle Tabellen oder maßgeschneiderte Integrationen umfassen.
Joomla sollte deshalb nicht nur nach Datensatzvolumen bewertet werden. Dieselbe Anzahl Articles kann eine einfache redaktionelle Website, einen geschützten Mitgliederbereich, eine mehrsprachige öffentliche Website oder eine Commerce-verbundene Installation darstellen. Vor der Entscheidung zwischen Standard Service, Managed Service, Add-ons oder Custom Service sollten daher Datenverantwortung, Beziehungen, Ausführungsverantwortung und der erforderliche Validierungsnachweis bewertet werden.
Innerhalb der Next-Cart Migrationsservices müssen Joomla-Nachweise unterstützte Content- und Commerce-Datensätze von Ausführungsverantwortung, erweiterungseigenen Daten und Zielimplementierung trennen.
Mit der Verantwortung für den Joomla-Scope beginnen
Die Auswahl des Ansatzes sollte mit einer Klassifizierung des erwarteten Migrationsumfangs beginnen. Manche Datensätze gehören Joomla Core, andere Erweiterungen. Wieder andere gehören zu Templates, Modules, individuellen Komponenten oder Integrationen. Der passende Service-Pfad wird klarer, wenn jeder Datenbereich einen Besitzer und eine Zielerwartung hat.
| Scope-Bereich | Typischer Besitzer | Bedeutung für den Ansatz |
|---|---|---|
| Articles, Categories, Menus, Users, Media, Tags, benutzerdefinierte Felder | Joomla Core | Kann in Standard Service passen, wenn unterstützt, sauber und leicht validierbar. |
| Modules, Template Assignments, Overrides, Layout-Abhängigkeiten | Joomla-Konfigurations- und Darstellungsebene | Kann Zielkonfiguration, manuellen Neuaufbau, Managed-Service-Koordination oder bei individuellem Datenverhalten eine Custom-Service-Prüfung erfordern. |
| Commerce Products, Customers, Orders, Coupons, Tax, Shipping, Payment, Stock | Commerce-Erweiterung oder individuelle Komponente | Erfordert eine erweiterungsspezifische Scope-Prüfung; nicht unterstützte Datensätze können Custom Service benötigen. |
| Forms, Directories, Downloads, Memberships, Galleries, SEO-/Routing-Tools | Erweiterungseigene Systeme | Nur einschließen, wenn unterstützt oder bewusst für Custom Service abgegrenzt. |
| Individuelle Tabellen, individuelle Komponenten, externe IDs, maßgeschneiderte Geschäftsregeln | Individuelle Implementierung | Starkes Signal für Custom Service. |
Diese Klassifizierung verhindert, dass der Ansatz entweder zu leicht oder unnötig schwer gewählt wird. Nicht jede Joomla-Migration benötigt Custom Service, erweiterungseigene oder individuell implementierte Daten dürfen aber nie in einem generischen Content-Scope versteckt werden.
Joomla-Scope dem passenden Service-Pfad zuordnen
Joomla-Komplexität darf nicht automatisch in einen intensiveren Service-Pfad übersetzt werden. Zuerst sind unterstützte Core-Datensätze, Ausführungsaufwand, klar begrenzte Zuordnung- oder Filteranforderungen und erweiterungseigene bzw. individuelle Daten mit besonderem Behandlungsbedarf zu unterscheiden.
| Service-Pfad | Geeigneter Joomla-Fall | Joomla-spezifische Grenze |
|---|---|---|
| Standard Service | Unterstützte Joomla-Core-Datensätze mit sauberer Struktur sowie kundenseitig geführter Vorbereitung und Validierung | Der Kunde bestätigt Content, Menus, Users, Media, Metadata und Zielverhalten. |
| Managed Service | Unterstützter Scope mit höherem Koordinationsbedarf und strukturierter Validierung | Managed-Ausführung macht nicht unterstützte Extension- oder Custom-Component-Datensätze nicht automatisch unterstützt. |
| Add-ons | Begrenzter unterstützter Bedarf mit Bedingung auf Datenkategorie/Feld, Feldwertausdruck oder kompatiblem Ziel für ein unterstütztes Quellfeld | Der Bedarf passt zu Data Filter, Advanced Data Mapping, Data Transformation oder einem berechtigten Advanced Database Mapping und bleibt innerhalb unterstützten Verhaltens. |
| Custom Service | Individuelle Komponenten, Extension Tables, maßgeschneiderte Beziehungen, Page-Builder-Daten, externe IDs oder andere nicht standardmäßige Datensätze mit individueller Extraktion oder Transformation | Installation von Ziel-Erweiterungen, Theme-Arbeit, Live-Integration und operative Konfiguration bleiben getrennt, sofern sie nicht ausdrücklich eingeschlossen sind. |
Eine Joomla-Website mit vielen Articles kann weiterhin in Standard oder Managed Service passen, wenn Datensätze und Beziehungen unterstützt und klar dokumentiert sind. Eine kleinere Website kann dagegen Custom Service benötigen, wenn geschäftskritische Bedeutung in individuellen Komponenten, Extension Tables, maßgeschneiderten Routen oder externen Systemreferenzen liegt. Entscheidend sind Struktur und Verantwortung der benötigten Daten, nicht die sichtbare Größe der Website.
Wann Standard Service ausreichen kann
Standard Service kann geeignet sein, wenn die erwartete Joomla-Migration innerhalb unterstützter Datensätze bleibt, die Source-Struktur sauber ist und der Händler Vorbereitung und Validierung zuverlässig übernehmen kann. Besonders realistisch ist dies, wenn Joomla primär als CMS verwendet wird und gewöhnliche Content-Datensätze, Categories, Menus, Users, Media, Aliases, Metadata, Tags und unterstützte Felder benötigt werden.
| Bereitschaftssignal für Standard Service | Bedeutung für Joomla |
|---|---|
| Core-Content-Datensätze sind organisiert und aktuell. | Articles, Categories, Menus und Media lassen sich ohne umfangreiche Bereinigung prüfen. |
| Menus und URLs sind verständlich. | Route- und SEO-Validierung kann anhand klarer Beispiele erfolgen. |
| Users und Access Levels sind einfach. | Identitäts- und Sichtbarkeitsverhalten lässt sich leichter bestätigen. |
| Mehrsprachige Struktur ist begrenzt oder gut dokumentiert. | Sprachspezifische Seiten und Menus können ohne individuelle Interpretation validiert werden. |
| Erweiterungseigene Datensätze werden nicht benötigt oder liegen außerhalb des Scopes. | Das Projekt bleibt innerhalb unterstützten Joomla-Core-Verhaltens. |
| Der Händler kann Demo-Migration-Beispiele prüfen. | Kundengeführte Validierung ist realistisch. |
Standard Service sollte nicht allein deshalb gewählt werden, weil eine Website klein aussieht. Auch eine kleine Joomla-Website kann tiefere Behandlung benötigen, wenn sie von Page Builder, Membership-Erweiterung, individueller Komponente, geschützten Inhaltsregeln, individuellem Routing oder einer Commerce-Erweiterung mit nicht unterstützten Datensätzen abhängt.
Wann Managed Service sicherer ist
Managed Service kann sicherer sein, wenn der Scope grundsätzlich unterstützt ist, Koordinations- und Ausführungsrisiken aber hoch sind. Joomla-Websites enthalten häufig Beziehungen, die in einer sinnvollen Reihenfolge geprüft werden müssen: Menus vor Routenvalidierung, Users vor Access-Prüfung, Modules vor Seitenzusammenstellung und Extension Setup vor der Bewertung von Komponenten-Daten.
| Signal für Managed Service | Joomla-Szenario |
|---|---|
| Viele Beziehungen benötigen koordinierte Prüfung. | Articles, Menus, Modules, Users, Access Levels und Media müssen gemeinsam bewertet werden. |
| Stakeholder haben wenig Migrationskapazität. | Das interne Team kann Migration Actions und Stichprobenprüfung nicht zuverlässig steuern. |
| URL- und SEO-Kontinuität ist geschäftskritisch. | Hochwertige Routen, Redirects, Aliases, Menu Metadata und Language URLs benötigen strukturierte Prüfung. |
| Mehrsprachige Struktur ist aktiv. | Sprachspezifische Menus, Modules, Associations und Defaults brauchen sorgfältige Validierung. |
| Joomla ist mit Commerce- oder Membership-Verhalten verbunden. | Core-CMS- und erweiterungseigene Datensätze müssen geprüft werden, ohne Verantwortlichkeiten zu vermischen. |
| Launch-Timing erfordert zusätzliche Migration Activity. | Nach einem ersten Lauf können neue Datensätze entstehen und kontrollierte Revalidierung benötigen. |
Managed Service hilft bei der Ausführungskoordination. Er macht nicht unterstützte Extension-Datensätze nicht automatisch unterstützt und ersetzt nicht die Validierung durch den Händler. Dieser muss weiterhin bestätigen, dass das Ziel-Joomla-Ergebnis den tatsächlichen Geschäftsbetrieb unterstützt.
Wann Add-ons die richtige Unterstützung sind
Add-ons eignen sich, wenn der Bedarf spezifisch, unterstützt und klar begrenzt ist. In einer Joomla-Migration können damit Datensätze anhand feldbasierter Bedingungen pro Datenkategorie gefiltert, Feldwerte über Expressions transformiert oder unterstützte Standard-Quellfelder auf kompatible unterstützte Zielfelder umgelegt werden, während der Wert unverändert bleibt.
| Add-on-Bedarf | Joomla-Beispiel | Grenzbedingung |
|---|---|---|
| Data Filter | Unterstützte Article-, User-, Media-, Category- oder andere Record-Field-Bedingungen verwenden, um passende Datensätze ein- oder auszuschließen. | Filterung darf keine Datensätze entfernen, die für Routen, Zugriff, SEO oder Erweiterungsbeziehungen benötigt werden. |
| Data Transformation | Expressions verwenden, um unterstützte Joomla-bezogene Feldwerte während der Migration zu transformieren. | Expression und erwarteter Wert müssen innerhalb der unterstützten Capability liegen. |
| Advanced Data Mapping | Unterstützte Standard-Quellfelder auf andere unterstützte Joomla-Felder abbilden, während der Wert unverändert bleibt. | Die Zuordnung muss Bedeutung erhalten und innerhalb unterstützten Feldverhaltens bleiben; Tax ist ausgeschlossen. |
| Advanced Database Mapping | Unterstützte Source-Datenbankspalten auf kompatible Joomla-Datenbankspalten abbilden, während Werte unverändert bleiben. | Dieses Add-on ist nur verfügbar, wenn Quellplattform und Joomla als Zielplattform beide Open-Source sind. Jede Zielspalte muss den Quellwert darstellen können; Tax ist ausgeschlossen. |
| Begrenzte Sonderbehandlung | Einen klar definierten unterstützten Bedarf mit begrenztem Scope behandeln. | Sind Daten nicht unterstützt, app-/erweiterungseigen oder individuell, ist Custom Service geeigneter. |
Add-ons ersetzen Custom Service nicht. Alte Articles anhand einer unterstützten Feldbedingung zu filtern kann zu Data Filter passen. Nicht unterstützte Membership-Regeln aus einer individuellen Erweiterung zu migrieren wird nicht dadurch zu einem Add-on-Fall, dass Joomla-Datensätze beteiligt sind.
Wann Custom Service geprüft werden sollte
Custom Service sollte geprüft werden, wenn die Joomla-Migration nicht unterstützte Datensätze, individuelle Komponenten, individuelle Tabellen, erweiterungseigene Daten außerhalb der Standardabdeckung, maßgeschneiderte Transformation, externe Systemkennungen oder Anpassungen an individueller Migrationslogik umfasst. Das ist besonders relevant bei über Jahre erweiterten Websites, deren geschäftskritische Daten außerhalb von Joomla Core liegen.
| Auslöser für Custom Service | Warum sich der Ansatz ändert |
|---|---|
| Individuelle Komponenten oder Datenbanktabellen | Die Datenstruktur folgt möglicherweise weder Joomla Core noch unterstütztem Extension-Verhalten. |
| Erweiterungseigene Datensätze außerhalb Standard-Coverage | Datensätze können individuelle Extraktion, Interpretation oder Zuordnung benötigen. |
| Page-Builder- oder Layout-Daten, die editierbar bleiben müssen | Ausgabe kann Darstellungslogik statt normaler Article Content sein. |
| Membership-, Booking-, Form-, Event- oder Directory-Datensätze | Geschäftsbedeutung kann von erweiterungsspezifischen Tabellen und Regeln abhängen. |
| Commerce-Komponenten-Daten außerhalb unterstützten Scopes | Products, Customers, Orders, Payment-/Shipping-Logik oder benutzerdefinierte Felder können erweiterungsspezifische Prüfung benötigen. |
| Externe IDs und Integrationen | ERP-, CRM-, Accounting-, Access- oder Kennungen für das Berichtswesen können maßgeschneiderten Erhalt erfordern. |
| Individuelle Routing- oder SEO-Regeln | URLs können von Plugins, Overrides oder individuellem SEF-Verhalten abhängen. |
Custom Service sollte anhand konkreter Beispiele abgegrenzt werden. Nützlich sind mindestens ein Custom-Component-Datensatz, ein erweiterungseigener Datensatz, eine User-/Customer-Beziehung, ein Routenbeispiel, ein Custom-Field-Beispiel und ein erwartetes Zielergebnis. Ohne Beispiele wird der Bedarf zu ungenau für belastbare Schätzung oder Validierung.
Wie Demo Migration die Ansatzwahl steuern sollte
Demo Migration ist für Joomla keine allgemeine Vorschau. Sie sollte zeigen, ob der gewählte Ansatz Beziehungen erhalten kann. Eine kleine Auswahl kann offenlegen, ob Standard Service ausreicht, Managed Service sicherer ist, Add-ons benötigt werden oder Custom Service geprüft werden sollte.
| Demo-Beispiel | Welche Entscheidung es unterstützen soll |
|---|---|
| Standard-Article mit Media und Metadata | Bestätigt grundlegende Content-Übertragung und Lesbarkeit der Felder. |
| Seite mit Menu-Verknüpfung | Prüft Route, Alias, Menu Hierarchy, Metadata und Seitenkontext. |
| Beispiel geschützter Inhalte | Prüft Bedeutung von User Group und Access Level. |
| Mehrsprachige Seite | Prüft Sprachzuweisung, Menu-Beziehung und Association-Verhalten. |
| Module-abhängige Seite | Prüft, ob Inhalte außerhalb des Haupt-Article-Bodys separat eingerichtet werden müssen. |
| Erweiterungseigener Datensatz | Entscheidet, ob der Datensatz unterstützt, ausgeschlossen, neu aufgebaut oder individuell abgegrenzt wird. |
| Commerce-Beispiel | Prüft, ob Products, Customers, Orders oder Shop-Routen erweiterungsspezifische Behandlung benötigen. |
| benutzerdefiniertes Feld oder externe ID | Zuerst unterstützte Zuordnung prüfen. Advanced Data Mapping kann bei kompatibler Feldneuzuordnung passen; bei Open-Source-Quellplattform → Open-Source-Zielplattform Joomla kann Advanced Database Mapping für einen berechtigten Datenbankfall passen. Custom Service erst prüfen, wenn der Bedarf diese unterstützten Grenzen überschreitet. |
Zeigt Demo Migration, dass wichtige Datensätze vorhanden sind, Seitenverhalten, Routen, Access Levels oder Erweiterungsdaten aber keinen Sinn ergeben, ist der Ansatz zu leicht. Dann muss der Scope korrigiert werden statt blind fortzufahren.
Entity Points und Joomla-Scope-Planung
Entity Points unterstützen die Planung, ersetzen aber keine Scope-Bewertung. Product-, Customer-, Order- und Blog-Posts-Datensätze können Entity Points verbrauchen, wenn sie erstmals migriert werden und diese Entitätskategorien auf den gewählten Scope anwendbar sind. Joomla-Content, Commerce-Erweiterungsdaten oder individuell implementierte Datensätze müssen unabhängig davon auf Supportability und Validierungsaufwand geprüft werden.
Eine spätere Migration Action kann neue berechtigte Datensätze erstmals migrieren. Datensätze, die innerhalb der gekauften Migration bereits gezählt wurden, verbrauchen nicht erneut Entity Points, nur weil auf demselben Migrationspfad eine weitere Migration Action stattfindet, selbst wenn eine neue Migration ein früheres Zielergebnis ersetzt. Diese Regel ist von der operativen Entscheidung zu trennen, was die neue Aktion erreichen soll.
| Planungsfrage | Warum sie wichtig ist |
|---|---|
| Welche berechtigten Datensätze sind neu in der gekauften Migration? | Neue berechtigte Datensätze können Entity Points verbrauchen. |
| Welche Datensätze wurden bereits zuvor gezählt? | Sie sollten nicht erneut Entity Points verbrauchen, nur weil auf demselben Pfad eine weitere Aktion erfolgt. |
| Muss das Zielergebnis fortgeführt oder ersetzt werden? | Die operative Aktion beeinflusst Validierungsumfang, nicht nur Entity-Points-Planung. |
| Sind Joomla-Datensätze Standard, erweiterungseigen oder individuell? | Entity-Points-Planung beweist keine Supportability. |
Entity Points sollten nur dort erscheinen, wo sie dem Händler helfen, den Scope zu verstehen. Sie dürfen nicht zum Zentrum der Joomla-Ansatzentscheidung werden.
Optionen für spätere Migrationen und Launch-Timing
Joomla-Projekte verändern sich häufig weiter, während Migration Review läuft. Nach einem früheren Lauf können neue Articles, Users, Media Files, Menu Items, Redirects, Form Submissions, Products, Orders oder individuelle Datensätze entstehen. Die nächste Aktion sollte danach gewählt werden, was sich geändert hat und ob das frühere Zielergebnis erhalten oder ersetzt werden soll.
| Aktuelle Aktion | Wann einsetzen | Joomla-Schwerpunkt der Revalidierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Neue berechtigte Datensätze sollen mit derselben genehmigten Zuordnung, Filterung und Konfiguration ergänzt werden. | Neue Inhalte, Users, Products, Orders, Media und Routes bestätigen, ohne bereits akzeptierte Beziehungen unnötig neu zu öffnen. |
| Continue the Migration with a New Configuration | Zuordnung, Filterung, Feldbehandlung oder unterstützte Konfiguration muss geändert werden. | Jedes betroffene Article Field, jede Menu-Beziehung, Access Rule, Language Association, jeder Commerce-Datensatz und jedes Custom-Field-Ziel neu validieren. |
| Perform a New Migration | Das frühere Zielergebnis soll ersetzt werden, weil sich Scope, Zielstruktur oder Acceptance Baseline wesentlich geändert hat. | Die vollständige repräsentative Stichprobe erneut prüfen, einschließlich Menus, Aliases, Access, Mehrsprachigkeit, Extension Boundaries, URLs und Commerce-Datensätzen. |
Erweiterungseigene Daten, die sich weiter verändern, müssen weiterhin auf Supportability geprüft werden. Optionen für spätere Migrationen machen nicht unterstützte Datensätze nicht unterstützt und ersetzen Custom Service nicht, wenn individuelle Extraktion, maßgeschneiderte Transformation oder individuelle Migrationslogik benötigt wird.
Signale, dass der Joomla-Ansatz zu leicht ist
Ein Joomla-Ansatz ist zu leicht, wenn beziehungsabhängige Daten wie gewöhnlicher Content behandelt werden. Das Problem erscheint nicht zwingend in Datensatzanzahlen. Es zeigt sich, wenn das Ziel Datensätze enthält, aber Seitenbedeutung, Routing, Zugriff, Erweiterungsdatensätze oder Geschäftsabläufe nicht reproduzieren kann.
| Warnsignal | Wahrscheinliche Reaktion |
|---|---|
| Menus und Aliases fehlen in Vorbereitung oder Validierung. | Scope vor Full Migration stärken. |
| User Groups und Access Levels werden als normale Kontofelder angenommen. | Beispiele für geschützte Inhalte und Permission Checks ergänzen. |
| Mehrsprachiger Content wird nur nach Article-Anzahl geprüft. | Sprachspezifische Menus, Modules, Associations und Defaults validieren. |
| Erweiterungseigene Datensätze werden ohne Bestätigung der Unterstützung aufgelistet. | Add-ons, Custom Service, Ausschluss oder manuellen Neuaufbau prüfen. |
| Individuelle Komponenten oder Tabellen enthalten geschäftskritische Daten. | Zu Custom-Service-Bewertung wechseln. |
| Demo-Migration-Beispiele enthalten nur einfache Content-Datensätze. | Route-, Access-, Module-, Multilingual-, Extension- und Custom-Beispiele ergänzen. |
| Das Team kann nicht erklären, was eine spätere Migration Action ändern soll. | Continuation- oder New-Migration-Erwartungen vor Launch festlegen. |
Diese Warnsignale sollten vor Full Migration gelöst werden. Andernfalls kann das Ziel gut gefüllt aussehen und trotzdem für echtes Publishing, Access Control, Commerce oder Operations unzuverlässig bleiben.
Den praktikablen Joomla-Pfad wählen
Der praktikable Pfad ist der leichteste Ansatz, der das Zielergebnis zuverlässig schützt. Standard Service passt bei unterstütztem, sauberem und gut validierbarem Joomla-Scope. Managed Service hilft, wenn Koordination und Beziehungsprüfung schwierig sind. Add-ons unterstützen Record Filtering, Field-Value Transformation oder Field Remapping innerhalb unterstützter Grenzen. Custom Service wird benötigt, wenn nicht unterstützte Extension-Daten, individuelle Komponenten, benutzerdefinierte Felder außerhalb unterstützter Zuordnung, externe Identifikatoren oder maßgeschneiderte Transformation behandelt werden müssen.
Ein Joomla-Ansatz ist bereit, wenn der Händler benennen kann:
- welche Joomla-Core-Datensätze migriert werden sollen;
- welche erweiterungseigenen Datensätze im oder außerhalb des Scopes liegen;
- welche Zielsettings, Templates, Modules, Menus, Access Rules oder Extensions separat konfiguriert werden müssen;
- ob Add-ons oder Custom Service benötigt werden;
- was die Demo-Migration-Beispiele beweisen müssen;
- wie spätere Migration Activity vor dem Launch behandelt wird.
Fazit
Den richtigen Joomla-Migrationsansatz zu wählen bedeutet mehr, als anhand von Datensatzanzahlen einen Service zu wählen. Joomla-Websites kombinieren Content, Menus, Routes, Users, Access Levels, Modules, Templates, Media, mehrsprachige Beziehungen, Extensions, benutzerdefinierte Felder mit Anforderungen jenseits unterstützter Zuordnung, mögliche Commerce-Komponenten und individuelle Implementierungslogik. Der sicherste Ansatz klärt Verantwortungen, trennt unterstützte Datensätze von Zielkonfiguration, hält Add-ons und Custom Service auseinander, nutzt Demo Migration als Beziehungstest und plant spätere Migration Activity vor dem Launch.
Der stärkste Joomla-Ansatz ist nicht der schwerste. Es ist der Ansatz, der die tatsächlich benötigten Strukturen schützt und zugleich nicht unterstützte Annahmen sowie unnötigen Custom Scope vermeidet.
Häufige Fragen
Welche Nachweise sollten für eine Custom-Service-Prüfung bei einer Joomla-Migration vorbereitet werden?
Bereiten Sie konkrete Beispiele aus individuellen Komponenten, erweiterungseigenen Tabellen und Builder-/Layout-Daten vor, die nach der Migration nutzbar bleiben müssen. Jedes Beispiel sollte auf öffentliche oder administrative Nutzung, vorgesehene Zielrepräsentation und den erforderlichen Acceptance-Nachweis zurückgeführt werden.
Wann sollte Managed Service für Joomla erwogen werden?
Managed Service ist hilfreich, wenn der Migrationsumfang unterstützt ist, das Koordinationsrisiko aber hoch bleibt. Joomla Menus, Modules, Access Levels, mehrsprachige Datensätze, Redirects und Extension Setup können sorgfältige Reihenfolge und Stakeholder Review erfordern.
Wie unterscheiden sich Add-ons und Custom Service bei einer Joomla-Migration?
Add-ons unterstützen klar begrenztes Record Filtering, Field-Value Transformation oder Field Remapping innerhalb unterstützten Verhaltens. Custom Service ist für nicht unterstützte Extension-Daten, individuelle Komponenten, benutzerdefinierte Felder mit nicht standardmäßiger Interpretation jenseits unterstützter Zuordnung, externe IDs, maßgeschneiderte Transformation oder Anpassungen individueller Migrationslogik vorgesehen.
Was sollte Demo Migration für Joomla beweisen?
Demo Migration sollte zeigen, dass repräsentative Datensätze ihre Bedeutung behalten: Articles, Routes, Menus, Access Levels, mehrsprachige Seiten, Modules, erweiterungseigene Datensätze, gegebenenfalls Commerce-Beispiele sowie benutzerdefinierte Felder oder externe IDs, wenn sie Teil des erwarteten Ergebnisses sind.