Wie du einen ESX-Server zu QBCore migrierst

Direkte Antwort: Die Migration von ESX zu QBCore ist ein kontrolliertes Rewrite mit Datenmigration, kein bloßer Framework-Wechsel. Baue einen sauberen QBCore-Staging-Server auf, inventarisiere jede ESX-Abhängigkeit, definiere eine explizite Feld-für-Feld-Datenzuordnung, portiere Ressourcen gegen die aktuellen APIs, übe das Rollback und schalte erst nach bestandenen Referenz- und Gameplay-Prüfungen um.

Was abgebildet werden muss

Oberfläche	Migrationsentscheidung	Akzeptanznachweis
Spieleridentität	Ordne Legacy-Identifier und Charaktere ohne Kollisionen den QBCore-Citizen-IDs zu.	Jeder Spieler in der Stichprobe wird genau einem vorgesehenen Charakterdatensatz zugeordnet.
Geld und Konten	Ordne jedes Konto explizit zu; gehe nicht von gleichen Namen oder gleicher Semantik aus.	Die Summen vor und nach der Migration stimmen für eine eingefrorene Stichprobe überein.
Jobs und Ränge	Lege für jeden aktiven Job und Rang eine Zuordnung fest, einschließlich Ersatzwerten für Arbeitslose.	Berechtigungen und Gehaltszahlungen entsprechen der freigegebenen Zuordnung.
Gegenstände und Inventar	Ordne Namen, Metadaten, Gewicht, Plätze und Lagerbesitz zu.	Keine verwaisten Gegenstandsnamen; Inventare bleiben nach dem erneuten Verbinden erhalten.
Fahrzeuge und Immobilien	Ordne Besitzschlüssel, Garagen und Zustandsfelder zu. Erhalte dabei Kennzeichen und löse Konflikte ausdrücklich auf.	Besitzdatensätze bleiben eindeutig und zugänglich.
Eigene Ressourcen	Ersetze ESX-Callbacks, Ereignisse und Spieler-APIs durch dokumentierte QBCore-Entsprechungen.	Jeder vollständige Ressourcenablauf besteht den Test in der Testumgebung.

Ablauf der Migration

1. Pausiere Schema- und Ressourcenänderungen; erstelle eine wiederherstellbare Sicherung der Datenbank und Dateien.
2. Richte QBCore anhand seiner gepflegten Installationsvorlage oder seines Repositorys in einer isolierten Testumgebung ein.
3. Exportiere eine Schemaübersicht und erstelle eine versionierte Zuordnung für Identitäten, Konten, Jobs, Gegenstände, Fahrzeuge und eigene Tabellen.
4. Gestalte Umwandlungen idempotent und führe sie ausschließlich auf einer entbehrlichen Datenbankkopie aus.
5. Portiere Ressourcen einzeln anhand der aktuellen QBCore-Dokumentation; verlasse dich nicht auf blindes Ersetzen von Ereignisnamen.
6. Gleiche Zeilenzahlen, Eindeutigkeit, Summen und verwaiste Verweise ab. Teste anschließend Spielabläufe, erneutes Verbinden und Neustarts.
7. Probe die Rücknahme. Stoppe beim Umstieg Schreibzugriffe, erstelle eine letzte Sicherung, wiederhole den erprobten Ablauf und prüfe das Ergebnis, bevor du Verbindungen wieder zulässt.

Kopiere keine allgemeine SQL-Vorlage

Die Schemata von ESX und QBCore unterscheiden sich je nach Version, Installationsvorlage, Inventar und eigenen Ressourcen. Eine allgemeine CREATE TABLE- oder INSERT-Anweisung kann unbemerkt Metadaten verwerfen oder ungültige Standardwerte erzeugen. Leite die SQL-Migration aus den beiden tatsächlich installierten Schemata ab, prüfe Einschränkungen und bewahre eine Zuordnung alter zu neuen Identitäten für Support und Prüfung auf.

Umfang und Einschränkungen

Dies ist ein Kontrollplan für die Migration, kein ausführbares SQL für einen unbekannten Server. Er schätzt keinen Zeitbedarf und verspricht keine verlustfreie Umwandlung. Verschlüsselte oder durch Escrow geschützte Ressourcen lassen sich möglicherweise nicht portieren. Prüfe vor Beginn Lizenzen, aktuelle Framework-APIs und die Migrationsrechte jedes Pakets.

Primäre Quellen

• Cfx.re: Frameworks
• ESX: offizielles esx_core-Repository
• QBCore: offizielles qb-core-Repository
• Qbox: offizielle Dokumentation