{"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":"comment-migrer-esx-qbcore","status":"publish","type":"post","link":"https:\/\/rpcrate.com\/fr\/how-to-migrate-esx-qbcore\/","title":{"rendered":"Comment migrer un serveur ESX vers QBCore"},"content":{"rendered":"

R\u00e9ponse directe :<\/strong> La migration d'ESX vers QBCore est une r\u00e9\u00e9criture contr\u00f4l\u00e9e et une migration de donn\u00e9es, pas un simple changement de framework. Cr\u00e9ez un serveur de staging QBCore propre, inventoriez chaque d\u00e9pendance ESX, d\u00e9finissez une correspondance de donn\u00e9es explicite champ par champ, portez les ressources sur les API actuelles, r\u00e9p\u00e9tez la proc\u00e9dure de rollback et ne basculez qu'une fois les v\u00e9rifications r\u00e9f\u00e9rentielles et de gameplay r\u00e9ussies.<\/p>\n

Ce qui doit \u00eatre mapp\u00e9<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n
Surface<\/th>\nD\u00e9cision de migration<\/th>\nPreuve d'acceptation<\/th>\n<\/tr>\n<\/thead>\n
Identit\u00e9 du joueur<\/th>\nMappez les identifiants et personnages h\u00e9rit\u00e9s vers les citizen IDs QBCore sans collisions.<\/td>\nChaque joueur \u00e9chantillonn\u00e9 correspond \u00e0 un unique enregistrement de personnage pr\u00e9vu.<\/td>\n<\/tr>\n
Argent et comptes<\/th>\nMappez chaque compte explicitement ; ne supposez pas que les noms ou la s\u00e9mantique soient identiques.<\/td>\nLes totaux avant\/apr\u00e8s se r\u00e9concilient pour un \u00e9chantillon fig\u00e9.<\/td>\n<\/tr>\n
M\u00e9tiers et grades<\/th>\nD\u00e9finissez une correspondance pour chaque m\u00e9tier et grade actif, y compris les valeurs de repli pour les personnages sans emploi.<\/td>\nLes flux de permissions et de paie correspondent \u00e0 la correspondance approuv\u00e9e.<\/td>\n<\/tr>\n
Objets et inventaire<\/th>\nMappez les noms, les m\u00e9tadonn\u00e9es, le poids, les emplacements et la propri\u00e9t\u00e9 du stockage.<\/td>\nAucun nom d'objet orphelin ; les inventaires persistent apr\u00e8s la reconnexion.<\/td>\n<\/tr>\n
V\u00e9hicules et propri\u00e9t\u00e9s<\/th>\nMappez les cl\u00e9s de propri\u00e9t\u00e9, les garages et les champs d'\u00e9tat tout en pr\u00e9servant les plaques et en r\u00e9solvant explicitement les collisions.<\/td>\nLes enregistrements d\u00e9tenus restent uniques et accessibles.<\/td>\n<\/tr>\n
Ressources personnalis\u00e9es<\/th>\nRemplacez les callbacks, \u00e9v\u00e9nements et API de joueur ESX par leurs \u00e9quivalents QBCore document\u00e9s.<\/td>\nChaque flux de ressources de bout en bout r\u00e9ussit sur le serveur de staging.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

S\u00e9quence de migration<\/h2>\n
    \n
  1. Gelez les modifications de sch\u00e9ma et de ressources ; effectuez une sauvegarde restaurable de la base de donn\u00e9es et des fichiers.<\/li>\n
  2. Cr\u00e9ez QBCore \u00e0 partir de sa recette ou de son d\u00e9p\u00f4t maintenu, dans un environnement de staging isol\u00e9.<\/li>\n
  3. Exportez un inventaire du sch\u00e9ma et r\u00e9digez une correspondance versionn\u00e9e pour les identit\u00e9s, les comptes, les m\u00e9tiers, les objets, les v\u00e9hicules et les tables personnalis\u00e9es.<\/li>\n
  4. Rendez les transformations idempotentes et ex\u00e9cutez-les uniquement sur une copie jetable de la base de donn\u00e9es.<\/li>\n
  5. Portez les ressources une par une en utilisant la documentation actuelle de QBCore ; ne vous fiez pas \u00e0 un remplacement aveugle des noms d'\u00e9v\u00e9nements.<\/li>\n
  6. R\u00e9conciliez les d\u00e9comptes de lignes, l'unicit\u00e9, les sommes et les r\u00e9f\u00e9rences orphelines, puis ex\u00e9cutez les tests de gameplay, de reconnexion et de red\u00e9marrage.<\/li>\n
  7. R\u00e9p\u00e9tez la proc\u00e9dure de rollback. Pendant la bascule, arr\u00eatez les \u00e9critures, effectuez une sauvegarde finale, r\u00e9ex\u00e9cutez le processus \u00e9prouv\u00e9 et v\u00e9rifiez avant de rouvrir les connexions.<\/li>\n<\/ol>\n

    Ne copiez pas un mod\u00e8le SQL g\u00e9n\u00e9rique<\/h2>\n

    Les sch\u00e9mas ESX et QBCore varient selon la version, la recette, l'inventaire et les ressources personnalis\u00e9es. Une instruction CREATE TABLE ou INSERT g\u00e9n\u00e9rique peut supprimer silencieusement des m\u00e9tadonn\u00e9es ou cr\u00e9er des valeurs par d\u00e9faut invalides. D\u00e9rivez le SQL de migration des deux sch\u00e9mas r\u00e9ellement install\u00e9s, examinez les contraintes et conservez une table de correspondance entre les anciennes et les nouvelles identit\u00e9s pour le support et l'audit.<\/p>\n

    Port\u00e9e et limites<\/h2>\n

    Il s'agit d'un plan de contr\u00f4le de migration, et non d'un SQL ex\u00e9cutable pour un serveur inconnu. Il n'estime pas la dur\u00e9e des travaux et ne promet pas une conversion sans perte. Les ressources chiffr\u00e9es ou sous s\u00e9questre peuvent ne pas \u00eatre portables. V\u00e9rifiez les licences, les API du framework actuel et les droits de migration de chaque package avant de commencer les travaux.<\/p>\n

    Sources primaires<\/h2>\n