Resposta direta: A migração de ESX para QBCore é uma reescrita controlada e migração de dados, não uma troca de framework. Construa um servidor de estágio QBCore limpo, inventarie todas as dependências ESX, defina um mapeamento de dados explícito campo a campo, porte recursos contra APIs atuais, ensaie a reversão e só faça a transição após a aprovação das verificações referencial e de jogabilidade.
O que deve ser mapeado
| Superfície | Decisão de migração | Evidência de aceitação |
|---|---|---|
| Identidade do jogador | Mapeie identificadores e personagens legados para IDs de cidadãos QBCore sem colisões. | Cada jogador amostrado se resolve em um registro de personagem pretendido. |
| Dinheiro e contas | Mapeie cada conta explicitamente; não assuma nomes ou semânticas iguais. | Totais pré/pós reconciliados para uma amostra congelada. |
| Empregos e níveis de cargo | Defina uma correspondência para cada emprego e nível de cargo em uso, incluindo alternativas para personagens desempregados. | Permissões e fluxos de pagamento correspondem ao mapa aprovado. |
| Itens e inventário | Mapeie nomes, metadados, peso, slots e propriedade de armazenamento. | Sem nomes de itens órfãos; inventários persistem após reconexão. |
| Veículos e propriedades | Mapeie chaves de propriedade, garagens e campos de estado, preservando placas e resolvendo colisões explicitamente. | Registros de propriedade permanecem únicos e acessíveis. |
| Recursos personalizados | Substitua callbacks, eventos e APIs de jogador do ESX pelos equivalentes documentados do QBCore. | Cada fluxo de recurso ponta a ponta passa em staging. |
Sequência de migração
- Congele alterações de esquema e de recursos; faça um backup restaurável do banco de dados e dos arquivos.
- Crie o QBCore a partir de sua receita ou repositório mantido em um ambiente de staging isolado.
- Exporte um inventário de esquema e escreva um mapeamento versionado para identidades, contas, empregos, itens, veículos e tabelas personalizadas.
- Torne as transformações idempotentes e execute-as apenas em uma cópia descartável do banco de dados.
- Adapte os recursos um de cada vez usando a documentação atual do QBCore; não dependa de substituições cegas de nomes de eventos.
- Concilie contagens de linhas, unicidade, somas e referências órfãs, depois execute testes de jogabilidade, reconexão e reinicialização.
- Ensaie a reversão. Durante a transição, pare as gravações, faça um backup final, execute novamente o processo comprovado e verifique antes de reabrir as conexões.
Não copie um template SQL genérico
Os esquemas ESX e QBCore variam por release, receita, inventário e recursos personalizados. Uma instrução genérica CREATE TABLE ou INSERT pode descartar metadados silenciosamente ou criar padrões inválidos. Derive o SQL de migração dos dois esquemas realmente instalados, revise as restrições e preserve um mapa de identidade legado-para-novo para suporte e auditoria.
Escopo e limitações
Este é um plano de controle de migração, não um SQL executável para um servidor desconhecido. Ele não estima horas nem promete conversão sem perdas. Recursos criptografados ou protegidos por escrow podem não ser portáveis. Confira as licenças, as APIs atuais dos frameworks e os direitos de migração de cada pacote antes de começar.