Frameworks
Moving a server or script from ESX to QBCore/Qbox
Plan an ESX to QBCore or Qbox migration: mapping xPlayer functions to QBCore Player functions and Qbox exports, money accounts, jobs and grades, items and inventories, database differences (users vs players, identifier vs citizenid), converting player data, bridging scripts instead of rewriting, and testing.
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.