Choose Qbox for a new server when you want its modern, OX-integrated stack and are prepared to follow its conventions. Keep QBCore when your stable server depends on QBCore-specific resources and a migration has no clear payoff. Qbox provides a compatibility bridge for most properly written QBCore scripts, but compatibility is not universal.
Qbox vs QBCore at a glance
| Question | Qbox | QBCore |
|---|---|---|
| Origin | Started as a QBCore fork and now follows its own architecture | Established FiveM roleplay framework and ecosystem |
| Existing QB scripts | Most documented, properly written scripts work through the bridge | Native target for QBCore resources |
| OX integration | Designed around integrations such as ox_lib and ox_inventory | Depends on the chosen server stack and resource ports |
| Core access | Uses exports and imported modules; no native Qbox core object | Many resources use the familiar QBCore core object |
| Migration risk | Requires auditing database access, core-file access and custom resources | No framework migration if the server is already stable |
What is Qbox?
Qbox is a FiveM roleplay framework created in 2022. It began as a QBCore fork, maintains backwards compatibility for almost all properly implemented QBCore scripts, and increasingly uses its own exports, modules and OX-based integrations. Qbox’s own documentation recommends released resources and warns against unsupported access to core-owned database tables or files.
What is QBCore?
QBCore is a mature roleplay framework with a large catalog of jobs, inventories, admin tools and custom scripts. Its main advantage for an existing server is predictability: if your resources are tested against your current QBCore version, staying avoids the cost and risk of a framework migration.
Will QBCore scripts work on Qbox?
Most will, but not all. Qbox provides a QB bridge for resources that use documented QBCore exports and events correctly. Scripts are more likely to fail when they:
- read or modify QBCore-owned database tables directly;
- open or patch internal core files;
- depend on undocumented functions or invalid event usage;
- replace built-in multijob or multigang data with incompatible tables;
- assume a Qbox core object exists instead of using supported exports and modules.
Qbox describes its compatibility as 99% for existing QB scripts, but that is not a substitute for testing your exact paid and custom resources.
When Qbox is the better choice
- You are building a new server and want a Qbox/OX-oriented foundation.
- Your critical scripts use documented APIs or already declare Qbox support.
- You want to move custom code toward exports and modules instead of core edits.
- You can test database and character migration on a full staging copy.
Explore Qbox scripts and our overview of the Qbox OX stack.
When QBCore is the better choice
- Your live server is stable and the migration would not solve a measured problem.
- A critical resource directly depends on QBCore internals.
- You do not have a complete database backup and staging environment.
- Your team already maintains a tested QBCore deployment and update process.
Browse QBCore scripts and the QBCore guide hub.
Safe QBCore-to-Qbox migration
- Inventory every resource. Record its version, database tables, framework calls and support status.
- Back up files and database. Prove that the backup restores before modifying production.
- Install Qbox with the recommended recipe. Start from current configuration files rather than mixing old core files into the new stack.
- Review jobs and gangs. Qbox uses numeric job and gang grades, and its migration documentation calls out the required shared-file and collation changes.
- Configure and convert the inventory database. Follow the exact inventory documentation and work on a copy.
- Test scripts by category. Start with identity, characters, jobs, money and inventory, then vehicles, housing, phones and admin tools.
- Replace unsupported internals gradually. Qbox supports partial conversion from QBCore calls to Qbox exports and modules.
- Cut over only after parity tests pass. Keep a timed rollback plan and the untouched pre-migration backup.
Decision
For a new project, Qbox is a strong default when the team wants its architecture and compatible resource set. For a profitable or heavily customized QBCore server, do not migrate for fashion: move only when a staged audit proves that the benefit exceeds the compatibility and data risk.
