Switching from GCPhone or Quasar Smartphone to LB Phone: A Migration Plan

Before you start: there is no official converter

Switching phones is worth planning properly, because a phone holds numbers, contacts, messages and the links to your inventory, bank and job scripts. One thing up front: neither the LB Phone documentation nor our guides document a tool that copies GCPhone or Quasar Smartphone data into LB Phone. The official installation guide describes a fresh installation, not a data import.

That leaves two honest options: a clearly communicated fresh start, or a custom conversion that you build or pay for. This guide covers the plan for both. Do not describe the switch to your players as lossless until representative records and their relationships have been checked.

Step 1: Decide what you want to keep

Make a list per data type: phone numbers, contacts, messages, call history, photos and social media accounts. For each one, decide whether it moves, is re-created, or starts fresh. Ask for a conversion plan for every data type you want to keep, including offline characters and unique phone items.

Three decisions shape the whole migration:

• Who owns a number: the character or the phone item? LB Phone's unique phones feature gives each phone item its own number and needs an inventory with metadata support.
• How you resolve number collisions, for example when two characters end up with the same number.
• Whether photo and attachment URLs stay reachable. LB Phone uses its own upload method, Fivemanage by default.

A fresh start is the simpler choice. If players mainly care about their contacts, re-creating contacts can be a middle ground (see Step 6).

Step 2: Back up the database and the old phone

LB Scripts asks you to always take a backup before making any changes to your database. Back up two things:

1. The database. The LB guide shows how to export it with HeidiSQL: right-click the database, choose "Export database as SQL", keep the "Create" boxes checked and the "Drop" boxes unchecked, and choose a file name. For a full migration backup, make sure the export includes the data as well as the structure.
2. The old phone resource and its configuration, for example as a ZIP. Keep a rollback copy of the old resource and its phone data. For Quasar, back up the existing phone configuration too.

Step 3: Build a test server from the backup

Never run the migration on your live city first. Restore the backup into a separate database and run a copy of your server against it. Every following step happens on this test server until Step 9.

Step 4: Check which tables LB Phone would delete

This is the step that decides whether data survives. Before running LB Phone's SQL file, the official guide says to delete all tables starting with phone_. On a fresh server that is fine. On a server with an old phone it can delete that phone's history.

Coming from GCPhone / Re-Ignited

GCPhone's base.sql adds a phone_number column to the users table and creates phone_app_chat, phone_calls, phone_messages and phone_users_contacts. Re-Ignited's base.sql creates the same four tables. All four start with phone_, so LB Phone's install step would remove GCPhone's contacts, messages, calls and chat. The phone_number column in users and the separate twitter_* tables from twitter.sql do not match the prefix.

So: export these four tables (and users.phone_number) before the LB install, or rename them to a prefix like old_phone_ on the test server, so you can still read them in Step 6. Note which edition you run, because Re-Ignited ships separate archives for ESX 1.1 and ESX 1.2.

Coming from Quasar Smartphone

Check your edition first. The current line, Smartphone 2026 or V3, prefixes all its tables with qs_phone_, so they do not match LB Phone's phone_ rule. Delete only tables that start exactly with phone_, and check every match before you delete it.

The older Smartphone PRO line is different. RPScripts' listing of QS Smartphone (Legacy 1.7.96) says its esx.sql and qb.sql drop and recreate the phone tables. Open the SQL file you installed and list its table names before deleting anything. Apps, voice adapters and add-ons from one Quasar edition are not automatically part of another, and Quasar's free DLC apps need the Quasar base phone, so those apps will not carry over to LB Phone.

Step 5: Install LB Phone on the test server

Remove or stop the old phone first. Quasar's own guide says to remove every other phone before installing a phone, naming lb-phone among others, because these phones use the same item, keys and events and running two at once causes errors and broken calls. The same applies in the other direction. Stop the old phone instead of deleting its files, so you can roll back.

Then follow the official LB installation guide:

• MariaDB 10.11 or newer, oxmysql, current server artifacts, loaf_bcrypt recommended.
• After your Step 4 checks, delete the phone_ tables and run lb-phone/phone.sql with HeidiSQL.
• Start your framework, oxmysql and inventory before the phone. The product page gives ensure oxmysql, ensure lb-phoneprop, ensure lb-phone.
• Set the upload method in config.lua and the keys in lb-phone/server/apiKeys.lua.

If you use unique phones, set up the phone item in your inventory as described in LB's unique phones guide; on ox_inventory that includes removing the NPWD integration block for Item('phone'.

Step 6: Move or re-create data and compare it

There is no documented importer, so any data you keep needs a custom step. LB Phone does document server exports a developer can use. For example, AddContact adds a contact to a given phone number, and SendMessage sends a message between two numbers. A developer can read the old contacts table from Step 4 and re-create contacts through AddContact once players have their new LB numbers. This is a custom script, not an official migration tool, and whether old numbers can be kept is not documented in our sources.

Before you trust the result, compare the data:

• Count records per data type before and after, for example contacts per character.
• Check representative records and their relationships by hand: the right contact on the right number, on both an online and an offline character.
• Check duplicates and number collisions.
• Check old photo links. Stored attachment URLs may not stay reachable after the switch.

Step 7: Update scripts that called the old phone

Job alerts, dispatch or garage scripts often call the old phone through exports or events. Once that phone is gone, those calls fail; "No such export" means the called resource is not started or has another name. The LB docs list LB Phone's own exports and events, for example SendMessage, SendNotification and EmergencyNotification. They do not document aliases for gcPhone or Quasar exports, so every script that called the old phone needs to be adapted to LB Phone's exports. Re-Ignited starts gcphone before job resources, which is a good hint for which scripts depend on it.

Step 8: Test with two characters

Test with two ordinary characters on the test server: calls in both directions, messages and attachments after a restart, handing over a unique phone, bank transfers and job apps. Test reconnects, duplicate phone numbers and job alerts before replacing the live phone. If video calls show no one, set up a TURN server; LB Phone has built-in Cloudflare support.

Step 9: Switch the live server

Only switch once Steps 6 to 8 pass. A sensible order:

1. Tell your players in advance what moves and what does not, especially if their phone history will not move.
2. Stop the server and take a fresh backup as in Step 2.
3. Run exactly the steps that worked on the test server, in the same order: protect or export the old tables, install LB Phone, run your conversion script if you have one.
4. Start the server and run a short version of the Step 8 tests.

Planning the switch? Get LB Phone v2 on RPScripts and test it on your staging server first.

Step 10: Keep a rollback plan

Keep the rollback copy of the old phone resource and its data until you are sure you no longer need it. Write the rollback down before switch day: stop the server, restore the database backup from Step 9, swap the ensure lines back to the old phone and restore any job scripts you changed in Step 7. Test this rollback once on the test server too, so you know it works.

FAQ

Is there an official tool to move GCPhone or Quasar data into LB Phone?

Not in the LB Phone documentation or on RPScripts. A custom conversion or a fresh start are the options.

Will installing LB Phone delete my GCPhone data?

It can. The LB guide says to delete all phone_ tables before running the SQL file, and gcPhone's contacts, messages, calls and chat tables all start with phone_. Back up and export them first.

Will it delete my Quasar Smartphone V3 data?

V3 tables start with qs_phone_, so they do not match the phone_ rule. Still back up first and check every table before you delete it.

Can I keep running the old phone next to LB Phone?

No. Quasar's guide says running two phones at once causes errors and broken calls. Stop the old phone, but keep its files and data for a rollback.

Can I re-create contacts automatically?

A developer can use LB Phone's documented AddContact export in a custom script. It is not an official migration tool.