How to Migrate ESX → QBCore the Right Way

What prerequisites do I need before migrating ESX to QBCore in 2026?

The prerequisites for an ESX to QBCore migration in 2026 fall into three groups: development tools, server artifacts, and supporting libraries. The development tools group requires Git with a dedicated migration branch, MariaDB or MySQL 8 with full backups enabled, and a staging server that mirrors production hardware and player count expectations as closely as possible. The server artifacts group requires an FXServer build that exactly matches the production version, the QBCore base framework with its default resources, and a fresh database created on the staging instance to receive the migrated data. The supporting libraries group requires oxmysql for every database query in the new stack and ox_lib for callbacks, UI helpers, notification primitives, and utility wrappers — both are open source from Overextended and are the de facto standard on every modern QBCore build. Skipping any of these prerequisites is the most common reason a migration stalls in step 6 with broken player data or unrecoverable schema mismatches.

Key takeaways:

• An ESX to QBCore migration prerequisites Git with a dedicated migration branch.
• An ESX to QBCore migration prerequisites a staging server that mirrors production.
• An ESX to QBCore migration prerequisites an FXServer build matching the production version.
• An ESX to QBCore migration prerequisites oxmysql for all queries in the new QBCore stack.
• An ESX to QBCore migration prerequisites ox_lib for callbacks, UI helpers, and utilities.

1. Tools
   1. GIT and a separate branch for the migration.
   2. MariaDB or MySQL 8 with full backups enabled.
   3. A staging server that mirrors production.
   4. Server artifacts
      1. FXServer updated to the same build as production.
      2. QBCore base framework and default resources.
      3. Libraries you will use

         1. oxmysql for database.

         2. ox_lib for callbacks, UI helpers, and utility wrappers.

            ---

            Step 1. Make a Plan and a Rollback Point

            1. Freeze production changes. Stop new script installs and DB writes not required for testing.
            2. Back up your entire database dump as a named snapshot.
            3. Branch your server repository and create a dedicated migrate-esx-to-qbcore branch.
            4. Write a runbook. Include commands to start and stop the staging server, restore DB, and run health checks.

            ---

            Step 2. Build a Clean QBCore Base

            1. Deploy a fresh QBCore base to staging.
            2. Keep only essentials enabled. Disable jobs, inventories, and custom scripts until after DB migration.
            3. Install and start these resources first

               1. qb-core

               2. qb-vehicles or your preferred replacements

               3. oxmysql

               4. ox_lib

                  ---

                  Step 3. Replace mysql-async with oxmysql

                  If any remaining ESX scripts still use MySQL.Async, convert the calls to oxmysql. Use simple find and replace with verification.

                  Common conversions

                        -- ESX mysql-async
                        MySQL.Async.fetchAll('SELECT * FROM users WHERE identifier = @id', {['@id'] = identifier}, function(rows)
                          -- ...
                        end)
                        
                        -- QBCore oxmysql
                        local rows = MySQL.query.await('SELECT * FROM players WHERE citizenid = ?', { citizenid })
                        -- rows is a Lua table; handle nil and length checks directly
                        
                        -- ESX scalar example
                        MySQL.Async.fetchScalar('SELECT COUNT(1) FROM owned_vehicles', {}, function(count)
                          -- ...
                        end)
                        
                        -- oxmysql scalar
                        local count = MySQL.scalar.await('SELECT COUNT(1) FROM player_vehicles')
                        
                        -- ESX insert
                        MySQL.Async.execute('INSERT INTO addon_account VALUES (@owner, @name, @money)', {
                          ['@owner'] = identifier, ['@name'] = name, ['@money'] = money
                        })
                        
                        -- oxmysql insert
                        MySQL.prepare.await('INSERT INTO player_accounts (citizenid, name, amount) VALUES (?, ?, ?)', { citizenid, name, amount })

Notes

1. Prefer query.await, scalar.await, and prepare.await for clean flow.
2. Use prepared statements for write operations.

Step 4. Map ESX Data Structures to QBCore

| You will move player identities and owned entities. Use this reference to map tables. | ESX table | Key column | QBCore table | |

Launch faster

Compare curated bundles

Bundles shorten the path from planning to launch by grouping the highest-leverage scripts into a cleaner commercial starting point.