Respuesta directa: Migrar ESX a QBCore es una reescritura controlada y una migración de datos, no un cambio de framework. Cree un servidor de staging QBCore limpio, inventaríe cada dependencia ESX, defina un mapeo de datos explícito campo por campo, porte recursos contra APIs actuales, ensaye la reversión y realice el cambio solo después de que las verificaciones referenciales y de jugabilidad sean exitosas.
Qué debe mapearse
| Superficie | Decisión de migración | Evidencia de aceptación |
|---|---|---|
| Identidad del jugador | Mapear identificadores y personajes heredados a IDs de ciudadano QBCore sin colisiones. | Cada jugador muestreado se resuelve en un registro de personaje previsto. |
| Dinero y cuentas | Mapea cada cuenta explícitamente; no asumas nombres o semánticas iguales. | Los totales pre/post se concilian para una muestra congelada. |
| Trabajos y rangos | Define un mapeo para cada trabajo y rango activo, incluyendo las opciones por defecto para desempleados. | Los flujos de permisos y pagos coinciden con el mapa aprobado. |
| Objetos e inventario | Mapea nombres, metadatos, peso, ranuras y propiedad del almacenamiento. | No hay nombres de objetos huérfanos; los inventarios persisten después de reconectarse. |
| Vehículos y propiedades | Normalizar claves de propiedad, matrículas, garajes y campos de estado. | Los registros de propiedad siguen siendo únicos y accesibles. |
| Recursos personalizados | Reemplace las ESX devoluciones de llamada, eventos y API de jugadores con equivalentes QBCore documentados. | Cada flujo de recursos de extremo a extremo pasa por staging. |
Secuencia de migración
- Congela los cambios de esquema y recursos; realiza una copia de seguridad restaurable de la base de datos y de los archivos.
- Crea QBCore a partir de su receta o repositorio mantenido en un entorno de ensayo aislado.
- Exporta un inventario de esquemas y escribe un mapeo versionado para identidades, cuentas, trabajos, ítems, vehículos y tablas personalizadas.
- Haga que las transformaciones sean idempotentes y ejecútelas solo contra una copia de base de datos desechable.
- Importa los recursos uno a la vez usando la documentación actual de QBCore; no confíes en el reemplazo ciego de nombres de eventos.
- Reconcilia los recuentos de filas, la unicidad, las sumas y las referencias huérfanas, luego ejecuta las pruebas de juego, reconecta y reinicia.
- Ensaya el rollback. Durante el corte, detén las escrituras, haz una copia de seguridad final, vuelve a ejecutar el proceso probado y verifica antes de reabrir las uniones.
No copies una plantilla genérica de SQL
Los esquemas de ESX y QBCore varían según la versión, la receta, el inventario y los recursos personalizados. Una sentencia genérica CREATE TABLE o INSERT puede descartar silenciosamente metadatos o crear valores predeterminados inválidos. Deriva el SQL de migración de los dos esquemas realmente instalados, revisa las restricciones y preserva un mapa de identidad de legado a nuevo para soporte y auditoría.
Alcance y limitaciones
Este es un plan de control de migración, no ejecutable SQL para un servidor desconocido. No estima horas ni promete una conversión sin pérdidas. Los recursos cifrados o en depósito fiduciario pueden no ser portátiles. Verifique las licencias, los frameworks actuales APIs y los derechos de migración de cada paquete antes de que comience el trabajo.