Simultaneous Use of ESX and QBCore: Why It's Not Feasible

The idea is tempting: keep your existing ESX scripts running while gradually adding QBCore resources, building a hybrid server that draws from both ecosystems. Unfortunately, this is technically impossible for fundamental architectural reasons.

Why Two Frameworks Cannot Coexist

ESX and QBCore are not just collections of scripts — they are frameworks that manage core server state. Each framework expects to be the single source of truth for:

• Player data (identifiers, characters, inventories, jobs)
• Database access (each framework has its own schema and query patterns)
• Event systems (both frameworks use similarly-named events that would collide)
• Character selection (each framework has its own multicharacter system)
• Permission systems (jobs, grades, and ACE permissions are framework-specific)

Running both simultaneously means two systems competing to manage the same player, write to the same database tables, and respond to the same events. The result is not a hybrid server — it is a broken one.

The Database Conflict

ESX and QBCore use fundamentally different database schemas. ESX stores player data in an users table with an accounts table for money. QBCore uses a players table with a JSON money column and separate player_vehicles, player_houses, and other tables.

Loading both frameworks means both systems will attempt to create and manage these tables. They will overwrite each other's data, create duplicate entries, and leave your database in an inconsistent state that is nearly impossible to recover from.

The Event System Collision

FiveM's event system is global. Both ESX and QBCore use events like playerConnecting, playerJoining, or framework-specific events for character loading. When both frameworks register handlers for the same events, the results are unpredictable. One framework may win the race condition, both may fire in the wrong order, or neither may work correctly.

This is not something you can configure around. It is a fundamental conflict in how FiveM's event architecture works.

What You Can Actually Do

Option 1: Full Migration

The most common path: choose your target framework (ESX → QBCore, QBCore → ESX, or either → QBox) and migrate completely. This means:

1. Audit every script on your server for framework compatibility
2. Find or build framework-compatible replacements for every script
3. Migrate your database schema and player data
4. Test extensively on a development server
5. Schedule a maintenance window for the cutover

A full migration is disruptive but clean. You end up with a single, well-supported framework and access to its entire script ecosystem.

Option 2: Start Fresh

Many experienced server owners recommend starting a new server on the target framework rather than migrating an existing one. This avoids the technical complexity of data migration and lets you build with clean architecture from day one. The cost is losing your existing community, which makes this option viable primarily for new projects.

Option 3: Transitional Period

You cannot run both frameworks on the same server, but you can run a transitional server alongside your existing one. Use the existing server as a reference while building the new one, then announce a specific migration date with incentives for players to make the switch.

The Framework Choice in 2026

The framework landscape has consolidated significantly. ESX Legacy, QBCore, and QBox are the three main options, each with a mature ecosystem. The best choice depends on:

• Your development skills: QBCore and QBox use modern Lua patterns. ESX Legacy uses older conventions but has more documentation.
• Script availability: Which framework has the scripts you need? Check before committing.
• Performance requirements: QBox leads in raw performance. QBCore is close behind. ESX Legacy, depending on the version, can be heavier.
• Community support: All three have active Discord communities and regular updates.

For a deeper comparison, see our .