Short answer: migrating from ESX to QBCore is a scoped project, not a config switch. The two frameworks expose player data, jobs, and the economy differently, so most paid scripts need a QBCore version or a bridge, and your player database has to be mapped rather than copied. Done blind, it loses data and breaks the economy. Done with an audit first, it is predictable.

What actually breaks

  • Framework calls. ESX scripts lean on the ESX player object and its exports; QBCore uses its own player object and event model. Any script that touches the framework directly needs a QBCore build or a bridge.
  • Player data and the database. The schemas differ. Money, jobs, licenses, and inventory are stored differently, so existing player data has to be mapped into the QBCore shape, not dumped across.
  • Inventory and the economy. These are the highest-risk systems because almost everything depends on them. A mismatch here is what wipes balances or duplicates items.
  • Third-party paid scripts. Each one is either supported on QBCore, bridgeable, or a rewrite. That split is the whole budget.

What carries over

Your map, MLOs, vehicles, and most cosmetic or standalone resources do not care which framework you run, so they move with little or no change. Standalone scripts that never call the framework are usually safe.

How to scope it safely

  • Audit the full script stack and tag each resource: supported, bridge, or rewrite.
  • Stand up QBCore on a copy and migrate a copy of the database first.
  • Test the economy and inventory hard before any player ever logs in.
  • Plan the cutover window so players are not online during the data map.

The framework is not the hard part. The player data and the paid stack are. Scope those first.