Frameworks
Moving a server or script from ESX to QBCore/Qbox
Plan an ESX to QBCore or Qbox migration: mapping xPlayer functions, money, jobs and items, database differences, converting player data and bridging scripts.
Overview
Framework migrations are among the riskiest projects on a live server: every script touches the framework, and every player’s money and items live in its tables. Most of the work is mapping — functions, data and events — and the most important decision is which scripts to convert, which to bridge and which to replace.
API mapping
| ESX | QBCore | Qbox |
|---|---|---|
ESX.GetPlayerFromId(src) | QBCore.Functions.GetPlayer(src) | exports.qbx_core:GetPlayer(src) |
xPlayer.identifier | Player.PlayerData.citizenid | player.PlayerData.citizenid |
xPlayer.addMoney(n) | Player.Functions.AddMoney('cash', n) | exports.qbx_core:AddMoney(src, 'cash', n) |
xPlayer.addAccountMoney('bank', n) | Player.Functions.AddMoney('bank', n) | exports.qbx_core:AddMoney(src, 'bank', n) |
xPlayer.job.name / .grade | PlayerData.job.name / .job.grade.level | Same as QBCore |
xPlayer.setJob(job, grade) | Player.Functions.SetJob(job, grade) | exports.qbx_core:SetJob(src, job, grade) |
esx:playerLoaded | QBCore:Client:OnPlayerLoaded | QBX.PlayerData / same events |
Full APIs: ESX tutorial, QBCore tutorial, Qbox tutorial.
Data differences
| Data | ESX | QBCore / Qbox |
|---|---|---|
| Character table | users keyed by identifier | players keyed by citizenid (plus license) |
| Money | accounts JSON (money, bank, black_money) | money JSON (cash, bank, crypto) |
| Job | job, job_grade columns | job JSON with grade table |
| Vehicles | owned_vehicles | player_vehicles |
| Items | Inventory/ESX tables | Inventory-specific (qb-inventory or ox_inventory) |
Write a conversion script that reads each ESX row, generates a citizenid, maps money accounts and jobs, and inserts into the new tables — then verify totals (sum of all money before and after). Schema tips: database design.
Convert, bridge or replace
| Script type | Usual choice |
|---|---|
| Your own scripts | Convert, or add a framework bridge — see bridges |
| Popular multi-framework resources | Switch the config to the new framework |
| Old ESX-only resources | Replace with maintained equivalents |
| Escrowed ESX-only scripts | Ask the seller for a QB/Qbox version |
01A migration plan
- Inventory every resource and its framework dependency.
- Set up the new framework on a test server with a copy of the database.
- Convert data; compare money, items and vehicle counts.
- Test every job, shop, garage and admin tool.
- Announce a maintenance window; take a backup; switch; keep the old server ready for rollback.
Backups: server backups.
Frequently asked questions
Can I convert ESX scripts to QBCore?
Yes — map the xPlayer calls to QBCore Player functions (or Qbox exports), update events and inventory calls, and test.
Should I migrate to QBCore or Qbox?
For a new move, Qbox gives the QBCore data model with a modern ox-based stack; QBCore has the larger legacy script catalogue.
Can I keep player data when switching frameworks?
Yes, with a conversion script that maps users to players, money accounts and jobs. Test it on a copy first.
What is the biggest migration risk?
Economy data: money, items and vehicles. Verify totals before and after conversion.
Need this built, not just explained?
Ten years of FiveM work, from Lua to NUI
Custom resources, React NUI, ESX / QBCore / Qbox integration, OneSync performance audits and security reviews — plus the websites and SEO around your server brand.
Related guides
- FrameworksESX vs QBCore vs QboxData models, inventories, script ecosystems, performance and hiring cost — the real differences between the three FiveM frameworks.
- FrameworksSupporting several frameworks with a bridgeDetect the running framework with GetResourceState('qbx_core'), ('qb-core') and ('es_extended'), load a matching bridge file, and have every bridge expose the same functions — get player identifier, job, money add/remove, notify, item add/remove. Keep framework calls out of your main logic, allow a config override, and test on each framework you claim to support.
- FrameworksWriting scripts for Qbox (qbx_core)On the server call qbx_core exports: exports.qbx_core:GetPlayer(source), AddMoney(source, 'cash', amount, reason), SetJob(source, job, grade), HasGroup(source, filter) and Notify(source, text, type). On the client, add '@qbx_core/modules/playerdata.lua' to get QBX.PlayerData, kept in sync automatically. Items and inventories go through ox_inventory; UI through ox_lib. A bridge keeps most QBCore scripts working.
- FrameworksMaking your script work with every common inventoryox_inventory: exports.ox_inventory:AddItem(src, item, count, metadata), RemoveItem, GetItemCount, CanCarryItem. qb-inventory: exports['qb-inventory']:AddItem(src, item, amount, slot, info, reason), RemoveItem, GetItemCount, HasItem. ESX default: xPlayer.addInventoryItem, removeInventoryItem, getInventoryItem(name).count, canCarryItem. Detect the inventory with GetResourceState, wrap the calls in one module, and keep item names configurable.