Framework choice is not a popularity contest. It is a dependency decision: what your scripts require, what interfaces they call, what your team understands, and what you can verify before launch.
Short answer: Keep ESX when your current resources and staff workflows depend on ESX interfaces. Keep QBCore when the required stack depends on QBCore interfaces. Evaluate QBox for a new or deliberately migrated build only after testing every required resource and bridge. The comparison below is a planning worksheet, not a catalog census or migration-cost study.
ESX vs QBCore vs QBox at a glance
| Factor | ESX | QBCore | QBox |
|---|---|---|---|
| Ecosystem / script catalog | Verify each required resource against the current ESX version | Verify each required resource against the current QBCore version | Verify native support or a documented bridge for each required resource |
| Architecture | Use the maintainer documentation to map the ESX interfaces your stack calls | Use the maintainer documentation to map QBCore shared objects and events | Use the maintainer documentation to map Qbox interfaces and bridge behavior |
| Use case to verify | Existing builds with verified ESX dependencies | Existing builds with verified QBCore dependencies and team knowledge | New or scoped migration builds that pass a resource-by-resource test |
| Migration work to scope | Count ESX-only resources, data changes, integrations, and staff workflows | Count QBCore-only resources, data changes, integrations, and staff workflows | Count unsupported resources, bridge tests, data changes, and acceptance checks |
Choose ESX when
You inherited an ESX stack, have staff who know its patterns, and your required resources pass on the current ESX version. Staying avoids a migration project, but that is not evidence that future maintenance is cheaper; record the dependencies and problems you are accepting.
Choose QBCore when
Your team already works in QBCore, your scripts are QBCore-native, and the required resources pass against the current interfaces, and staff can support those dependencies. Treat team familiarity as one planning input, then test the actual build instead of inferring support breadth.
Choose QBox when
You are starting fresh or have a scoped migration plan and can validate each required resource and bridge. Do not infer maintainability or compatibility from positioning language; install the target versions, run the acceptance checks, and record unsupported dependencies before committing the build.
Check the interface before changing a resource name
These are documented interfaces checked on September 8, 2026, not a tested compatibility matrix. The resource's own supported-version list and installation instructions still matter. Qbox specifically warns about resources that access core tables or internal files directly, rather than using its supported interfaces.
- QBCore: the core-object documentation uses
exports['qb-core']:GetCoreObject(). - Qbox:
qbx_corehas no native core object. Its QB bridge can supply the QBCore-style export. Renaming that call toexports['qbx_core']:GetCoreObject()is not a migration. Check the Qbox compatibility exceptions and the documented qbx:enableBridge setting. - ESX: its maintained imports file obtains
exports['es_extended']:getSharedObject(). An ESX integration needs the expected ESX API; changing the export name does not convert its player, inventory or job logic.
A compatibility check you can repeat
- Create an isolated test server and database using fictional players. Record the FXServer artifact, framework release or commit, resource release, database migration and every bridge or dependency version.
- Choose one required integration, such as a shop connected to your inventory. Write its expected behavior before running it: one purchase removes the configured amount and adds exactly one item; insufficient funds change neither balance nor inventory.
- Install in the documented dependency order. Test login, the action, failure handling and reconnecting. If persistence is part of the feature, restart the test server and confirm the expected state returns without a duplicate item or charge.
- Record expected versus actual behavior, relevant sanitized errors and the version tested. Mark missing evidence as untested. A clean startup proves only that startup completed; it does not prove these player actions work.
Repeat for each required integration. If the core version or bridge changes, repeat the affected checks. Bring a failing example to the free error decoder or follow the debugging lesson to identify the first missing value or API before buying a replacement.
