{"id":199542,"date":"2025-10-02T15:33:52","date_gmt":"2025-10-02T13:33:52","guid":{"rendered":"https:\/\/fivemx.com\/?p=199542"},"modified":"2026-08-15T19:30:00","modified_gmt":"2026-08-15T17:30:00","slug":"so-migrieren-sie-esx-qbcore","status":"publish","type":"post","link":"https:\/\/rpcrate.com\/de\/how-to-migrate-esx-qbcore\/","title":{"rendered":"Wie du einen ESX-Server zu QBCore migrierst"},"content":{"rendered":"

Direkte Antwort:<\/strong> Die Migration von ESX zu QBCore ist ein kontrolliertes Rewrite mit Datenmigration, kein blo\u00dfer Framework-Wechsel. Baue einen sauberen QBCore-Staging-Server auf, inventarisiere jede ESX-Abh\u00e4ngigkeit, definiere eine explizite Feld-f\u00fcr-Feld-Datenzuordnung, portiere Ressourcen gegen die aktuellen APIs, \u00fcbe das Rollback und schalte erst nach bestandenen Referenz- und Gameplay-Pr\u00fcfungen um.<\/p>\n

Was abgebildet werden muss<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n
Oberfl\u00e4che<\/th>\nMigrationsentscheidung<\/th>\nAkzeptanznachweis<\/th>\n<\/tr>\n<\/thead>\n
Spieleridentit\u00e4t<\/th>\nOrdne Legacy-Identifier und Charaktere ohne Kollisionen den QBCore-Citizen-IDs zu.<\/td>\nJeder Spieler in der Stichprobe wird genau einem vorgesehenen Charakterdatensatz zugeordnet.<\/td>\n<\/tr>\n
Geld und Konten<\/th>\nOrdne jedes Konto explizit zu; gehe nicht von gleichen Namen oder gleicher Semantik aus.<\/td>\nDie Summen vor und nach der Migration stimmen f\u00fcr eine eingefrorene Stichprobe \u00fcberein.<\/td>\n<\/tr>\n
Jobs und R\u00e4nge<\/th>\nLege f\u00fcr jeden aktiven Job und Rang eine Zuordnung fest, einschlie\u00dflich Ersatzwerten f\u00fcr Arbeitslose.<\/td>\nBerechtigungen und Gehaltszahlungen entsprechen der freigegebenen Zuordnung.<\/td>\n<\/tr>\n
Gegenst\u00e4nde und Inventar<\/th>\nOrdne Namen, Metadaten, Gewicht, Pl\u00e4tze und Lagerbesitz zu.<\/td>\nKeine verwaisten Gegenstandsnamen; Inventare bleiben nach dem erneuten Verbinden erhalten.<\/td>\n<\/tr>\n
Fahrzeuge und Immobilien<\/th>\nOrdne Besitzschl\u00fcssel, Garagen und Zustandsfelder zu. Erhalte dabei Kennzeichen und l\u00f6se Konflikte ausdr\u00fccklich auf.<\/td>\nBesitzdatens\u00e4tze bleiben eindeutig und zug\u00e4nglich.<\/td>\n<\/tr>\n
Eigene Ressourcen<\/th>\nErsetze ESX-Callbacks, Ereignisse und Spieler-APIs durch dokumentierte QBCore-Entsprechungen.<\/td>\nJeder vollst\u00e4ndige Ressourcenablauf besteht den Test in der Testumgebung.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Ablauf der Migration<\/h2>\n
    \n
  1. Pausiere Schema- und Ressourcen\u00e4nderungen; erstelle eine wiederherstellbare Sicherung der Datenbank und Dateien.<\/li>\n
  2. Richte QBCore anhand seiner gepflegten Installationsvorlage oder seines Repositorys in einer isolierten Testumgebung ein.<\/li>\n
  3. Exportiere eine Schema\u00fcbersicht und erstelle eine versionierte Zuordnung f\u00fcr Identit\u00e4ten, Konten, Jobs, Gegenst\u00e4nde, Fahrzeuge und eigene Tabellen.<\/li>\n
  4. Gestalte Umwandlungen idempotent und f\u00fchre sie ausschlie\u00dflich auf einer entbehrlichen Datenbankkopie aus.<\/li>\n
  5. Portiere Ressourcen einzeln anhand der aktuellen QBCore-Dokumentation; verlasse dich nicht auf blindes Ersetzen von Ereignisnamen.<\/li>\n
  6. Gleiche Zeilenzahlen, Eindeutigkeit, Summen und verwaiste Verweise ab. Teste anschlie\u00dfend Spielabl\u00e4ufe, erneutes Verbinden und Neustarts.<\/li>\n
  7. Probe die R\u00fccknahme. Stoppe beim Umstieg Schreibzugriffe, erstelle eine letzte Sicherung, wiederhole den erprobten Ablauf und pr\u00fcfe das Ergebnis, bevor du Verbindungen wieder zul\u00e4sst.<\/li>\n<\/ol>\n

    Kopiere keine allgemeine SQL-Vorlage<\/h2>\n

    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\u00fcltige Standardwerte erzeugen. Leite die SQL-Migration aus den beiden tats\u00e4chlich installierten Schemata ab, pr\u00fcfe Einschr\u00e4nkungen und bewahre eine Zuordnung alter zu neuen Identit\u00e4ten f\u00fcr Support und Pr\u00fcfung auf.<\/p>\n

    Umfang und Einschr\u00e4nkungen<\/h2>\n

    Dies ist ein Kontrollplan f\u00fcr die Migration, kein ausf\u00fchrbares SQL f\u00fcr einen unbekannten Server. Er sch\u00e4tzt keinen Zeitbedarf und verspricht keine verlustfreie Umwandlung. Verschl\u00fcsselte oder durch Escrow gesch\u00fctzte Ressourcen lassen sich m\u00f6glicherweise nicht portieren. Pr\u00fcfe vor Beginn Lizenzen, aktuelle Framework-APIs und die Migrationsrechte jedes Pakets.<\/p>\n

    Prim\u00e4re Quellen<\/h2>\n