QBCore to Qbox migration
Qbox began as a QBCore fork and keeps backwards compatibility as a goal, which is exactly why a QBCore server can migrate without throwing away its scripts: Qbox is an ox-native base. It is newer than QBCore, not a replacement you must adopt - QBCore and ESX remain the established frameworks, and you migrate only for specific technical reasons, not because QBCore stopped working. And "compatible" is not "identical." This lesson sets realistic expectations and gives you a staged plan.
A staged migration
Back up and stand up a test server
Full database backup, then clone the server onto a test environment. Match the live server's artifact (FXServer) version and sv_enforceGameBuild on the test box so what you prove there holds in production. Note: sv_enforceGameBuild is a startup-only convar (set it in server.cfg before the server boots; it cannot be changed while running). Its value is a GTA content game build number such as 3095 and up -- a SEPARATE numbering scheme from the FXServer artifact number (the 31000+ range). Copy whatever value your live server already uses so the test and live builds match exactly. Every step below happens on the test server first. Never migrate live.
Install the ox dependency stack
Qbox is ox-native, so its required dependencies must be in place before qbx_core. qbx_core declares two hard dependencies in its fxmanifest: ox_lib and oxmysql. Install and start oxmysql and ox_lib first, with no missing-dependency errors in the console. ox_inventory is the inventory Qbox expects, but it is configured separately and is not required for qbx_core to boot, so install it as part of the same stack but know that a missing ox_inventory does not stop qbx_core from starting. These are CommunityOx resources (originally Overextended), so pull them from the official CommunityOx GitHub releases (github.com/CommunityOx), not from a QBCore bundle.
Where this happens: each resource is a folder you place inside your server's resources directory (for example resources/[ox]/oxmysql) and then add to server.cfg with an ensure line (ensure oxmysql). After editing server.cfg, start or restart resources from the txAdmin Live Console or the FXServer console with commands like 'ensure oxmysql' or 'restart qbx_core'. If you do not yet have a server folder and server.cfg, complete the server-setup lesson first.
Install qbx_core and turn on the bridge
Install qbx_core. The compatibility layer is not a separate download: qbx_core ships a QBCore shim that rebuilds the old QBCore object on top of the Qbox API. qbx_core ships with the QBCore bridge enabled by default. You can set it explicitly by adding this line to your server.cfg (open the file in a text editor such as VS Code, add the line above your ensure qbx_core line, save, then restart the server). setr means a replicated convar (its value is sent to clients too); the capital B in enableBridge matters because convar names are case-sensitive:
setr qbx:enableBridge "true"
With the bridge on, many QBCore exports and events are translated to Qbox, so a lot of scripts work as-is. Expect a list of scripts that still need edits; that is normal, not failure. The next section shows you exactly where the line falls.
Test script by script, then cut over
Go through your resources: core (banking, jobs, inventory) first, then the rest. Note what works, what needs an edit, and what to drop. Confirm the production artifact version and game build match what you tested. Only cut production over once the core loop is solid on the test server.
Keep reading the full lesson
Sign in to start, then unlock every step of this lesson and the full FiveM School with a membership.
- How it works
- Common mistakes
- What you can do now
The remainder of QBCore to Qbox migration is available to FiveM School members.