Respuesta directa: Migrar ESX a QBCore es una reescritura controlada y una migración de datos, no un cambio de framework. Crea un servidor de staging QBCore limpio, inventaría cada dependencia ESX, define un mapeo de datos explícito campo por campo, porta recursos contra APIs actuales, ensaya la reversión y realiza 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 | Mapea 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 permisos y los flujos de pago 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 | Mapea las claves de propiedad, los garajes y los campos de estado, conservando las matrículas y resolviendo las colisiones explícitamente. | Los registros de propiedad siguen siendo únicos y accesibles. |
| Recursos personalizados | Sustituye los callbacks, los eventos y las API de jugador de ESX por sus equivalentes documentados en QBCore. | Cada flujo completo de un recurso supera las pruebas en el entorno de ensayo. |
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.
- Haz que las transformaciones sean idempotentes y ejecútalas solo contra una copia de base de datos desechable.
- Adapta 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 permitir de nuevo las conexiones.
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 un SQL ejecutable para un servidor desconocido. No estima horas ni promete una conversión sin pérdidas. Los recursos cifrados o protegidos por escrow pueden no ser portátiles. Revisa las licencias, las API del framework actual y los derechos de migración de cada paquete antes de empezar a trabajar.