How to Migrate Your Server from ESX to QBCore (Without Losing Players)

Switching frameworks is the single highest-risk thing a live server can do. Done well, it is a soft relaunch. Done poorly, it is the obituary.

Decide if you actually need to switch

Most we-need-to-switch arguments are really this-one-script-is-broken. If your stack basically works, fix the broken script and stay where you are. Migration is for servers where the codebase is fundamentally fighting you.

Build a parallel test server

Stand up a fresh QBCore install on a second box with a copy of your production database. This is where every conversion script gets tested, not on production. Treat the test server as the real launch target.

Mapping ESX data into QBCore tables

The schemas are different but compatible. users becomes players, with identifier mapped to citizenid (you will generate new IDs but keep the steam hex linked). accounts JSON in QBCore replaces the ESX bank/cash flat columns. Inventory should be pre-converted to the ox_inventory format if you are moving to it as part of the migration.

Jobs, vehicles, properties

This is the painful part. Most ESX jobs will not drop into QBCore — they will need rewrites or replacements. Don't try to port everything; pick the 5–10 jobs your players actually use and convert those. Vehicles are easier; ownership rows transfer cleanly with a SQL migration. Properties are framework-specific and almost always need a rewrite.

The launch playbook

Run a one-week beta where players can opt into the new server. Reward beta participants with cosmetic perks — they are testing for free. Set a hard cutover date, freeze the ESX database the night before, run the final conversion, and launch. Don't let two production servers run in parallel for more than 48 hours.

Wrapping up

Migration is mostly a project-management problem, not a code problem. The communities that survive a switch are the ones that planned, communicated, and rewarded patience. The ones that fail tried to do it in a weekend.