Réponse directe : La migration d'ESX vers QBCore est une réécriture contrôlée et une migration de données, pas un simple changement de framework. Créez un serveur de staging QBCore propre, inventoriez chaque dépendance ESX, définissez une correspondance de données explicite champ par champ, portez les ressources sur les API actuelles, répétez la procédure de rollback et ne basculez qu'une fois les vérifications référentielles et de gameplay réussies.
Ce qui doit être mappé
| Surface | Décision de migration | Preuve d'acceptation |
|---|---|---|
| Identité du joueur | Mappez les identifiants et personnages hérités vers les citizen IDs QBCore sans collisions. | Chaque joueur échantillonné correspond à un unique enregistrement de personnage prévu. |
| Argent et comptes | Mappez chaque compte explicitement ; ne supposez pas que les noms ou la sémantique soient identiques. | Les totaux avant/après se réconcilient pour un échantillon figé. |
| Métiers et grades | Définissez une correspondance pour chaque métier et grade actif, y compris les valeurs de repli pour les personnages sans emploi. | Les flux de permissions et de paie correspondent à la correspondance approuvée. |
| Objets et inventaire | Mappez les noms, les métadonnées, le poids, les emplacements et la propriété du stockage. | Aucun nom d'objet orphelin ; les inventaires persistent après la reconnexion. |
| Véhicules et propriétés | Mappez les clés de propriété, les garages et les champs d'état tout en préservant les plaques et en résolvant explicitement les collisions. | Les enregistrements détenus restent uniques et accessibles. |
| Ressources personnalisées | Remplacez les callbacks, événements et API de joueur ESX par leurs équivalents QBCore documentés. | Chaque flux de ressources de bout en bout réussit sur le serveur de staging. |
Séquence de migration
- Gelez les modifications de schéma et de ressources ; effectuez une sauvegarde restaurable de la base de données et des fichiers.
- Créez QBCore à partir de sa recette ou de son dépôt maintenu, dans un environnement de staging isolé.
- Exportez un inventaire du schéma et rédigez une correspondance versionnée pour les identités, les comptes, les métiers, les objets, les véhicules et les tables personnalisées.
- Rendez les transformations idempotentes et exécutez-les uniquement sur une copie jetable de la base de données.
- Portez les ressources une par une en utilisant la documentation actuelle de QBCore ; ne vous fiez pas à un remplacement aveugle des noms d'événements.
- Réconciliez les décomptes de lignes, l'unicité, les sommes et les références orphelines, puis exécutez les tests de gameplay, de reconnexion et de redémarrage.
- Répétez la procédure de rollback. Pendant la bascule, arrêtez les écritures, effectuez une sauvegarde finale, réexécutez le processus éprouvé et vérifiez avant de rouvrir les connexions.
Ne copiez pas un modèle SQL générique
Les schémas ESX et QBCore varient selon la version, la recette, l'inventaire et les ressources personnalisées. Une instruction CREATE TABLE ou INSERT générique peut supprimer silencieusement des métadonnées ou créer des valeurs par défaut invalides. Dérivez le SQL de migration des deux schémas réellement installés, examinez les contraintes et conservez une table de correspondance entre les anciennes et les nouvelles identités pour le support et l'audit.
Portée et limites
Il s'agit d'un plan de contrôle de migration, et non d'un SQL exécutable pour un serveur inconnu. Il n'estime pas la durée des travaux et ne promet pas une conversion sans perte. Les ressources chiffrées ou sous séquestre peuvent ne pas être portables. Vérifiez les licences, les API du framework actuel et les droits de migration de chaque package avant de commencer les travaux.