FiveM Legacy vs Enhanced: migration checklist
Treat Enhanced as a separate compatibility target, not a graphics setting. The current Cfx.re onboarding and developer manuals describe an early-access platform with runtime, asset and server changes. A resource that works on Legacy is not automatically certified for Enhanced. Keep a working Legacy deployment and a separate staging environment until every required dependency has passed its relevant checks.
This page replaces the older assumption that only asset formats differ. The official developer change list and Enhanced onboarding guide are the release-specific authorities; recheck them before a migration.
Compatibility checks before any cutover
| Area | Current Enhanced difference | Required migration evidence |
|---|---|---|
| C# runtime | .NET replaces Mono; the onboarding guide calls for the .NET 10 SDK | Rebuild/port using the Enhanced toolchain and run the actual resource. A Legacy net452 DLL compiled by a new SDK remains a Legacy target. |
| Assets | Gen8 assets may need conversion/refinement for the target | Retain original sources; check supported file types and validate appearance, collision, LODs and metadata after conversion. |
| Streamed files | A stream_enhanced folder, when present, is loaded instead of stream; stream alone still works but is deprecated | Put Gen8 assets in stream and Gen9 assets in stream_enhanced to keep one resource cross-compatible, then test both tracks. |
| Player IDs | A disconnected player’s server ID is freed and can be reused by the next player to connect (Legacy only ever increments) | Key persistent state on stable identifiers or session data, not the server ID, and clear per-source tables in playerDropped. |
| Asset Escrow | The current onboarding guide says it is not yet implemented | Treat any required escrow-protected dependency as a blocker until the publisher and current platform support it. |
| Persistent KVP storage | Existing database files require migration | Back up and verify a supported migration path. Do not invent a conversion command or promise lossless reuse. |
| Voice | Mumble is deprecated | Verify the currently supported voice integration instead of assuming a Legacy voice resource is compatible. |
| Networking | No P2P; OneSync big mode is required | Audit ownership assumptions, routing buckets and synchronization under the new track. |
| Developer controls | Server sv_devMode replaces old client launch-mode assumptions; -cl2 is deprecated | Use the Enhanced two-client workflow. Keep dev mode out of public production config. |
| Build pipeline | Built-in resource builders are disabled | Compile/bundle before deployment; do not depend on an on-server builder silently producing output. |
| Client modifications | Pure mode stays enabled in early access | Do not promise support for graphics modifications or a pure-mode bypass. |
| Server networking configuration | Single endpoint per TCP/UDP, removed HTTP/2/ARQ options and other retired flags | Start from the current supported config and add reviewed settings, rather than copying every old tuning flag. |
The change list also documents state-bag behavior changes, Remote Console (formerly DevCon) being disabled by default but still available on port 29200 (the old 29300 port is retired), removal of the server ImGui GUI, and sv_syncTickRate (see Enhanced migration). These are compatibility changes, not a reason to apply an unmeasured “performance preset.” A script depending on an initial state-bag callback must test that callback against an existing entity and explicitly set the values it needs.
Build a migration manifest
Before changing the server, make a private table with one row per required resource: revision, publisher, client/server languages, runtime target, escrow status, streamed formats, persistence backend and tested track. Add the exact server artifact and game build used for each acceptance run. A marketplace label, successful download or clean TypeScript build does not substitute for that evidence.
Separate blockers from optional improvements. For example, a required encrypted dependency with no supported Enhanced release blocks the cutover even if every unencrypted script starts. An unused cosmetic asset can instead be left out of the first staging test. Do not delete original assets or databases while experimenting.
Reversible staging sequence
- Back up server configuration, resources, database and KVP state. Test that the backup is readable and keep it outside the staging write path.
- Create separate server-data and database locations. Use the Enhanced artifact/executable named by the current onboarding guide; do not overwrite the running Legacy artifact directory.
- Start a minimal server, then add required resources in dependency order. Prebuild JavaScript/C# output externally and keep credentials outside the repository and public downloads.
- Validate joins, permissions, persistence, vehicle/entity ownership, NUI, voice and restart behavior with two clients. For assets, test the collision/LOD matrix.
- Rehearse shutdown, state capture and rollback. Only schedule a real cutover after blockers have been resolved and tested; do not switch DNS or replace the live artifact as part of a documentation experiment.
If staging fails, stop it and return to the preserved Legacy deployment. Never point the old runtime at a state store that the new runtime may have migrated without a tested reverse path. Restore from the known-good backup into a separate location instead.
What the examples on this site certify
The JS/C# runtime lab is explicitly Legacy/Mono, and the owned asset fixture is Gen8. Their compilation/export checks are useful evidence for those examples—not an Enhanced compatibility badge. Alchemist documents the conversion workflow and its limits; converting selected files does not port scripts, migrate state, restore escrow support or validate a complete server.