A clothing pack can outlive its usefulness. The art no longer fits the city, a replacement offers better combinations, or maintaining two similar wardrobes has become more trouble than it is worth. Removing the old resource is simple. Removing it without damaging saved outfits takes preparation.
Treat retirement as a change to the wardrobe players already own. Identify who uses the pack, decide what those references should become, and preserve enough original data to recover mistakes. The aim is to retire an asset deliberately while keeping character identities recognizable.
Count references before counting files
Start with the places your appearance setup stores or defines outfits. These may include a character's active appearance, saved personal outfits, job uniforms, gang outfits, shop presets and outfits held by another resource. Confirm the actual schema and configuration on your server rather than assuming everything lives in one skin column.
Back up the relevant data and the exact old pack. Keep its version, resource name, supported ped models and the current game build with that backup. Your audit needs a stable definition of what the retiring pack contained.
Report references separately from characters. One player might have six saved outfits using the same jacket, while another currently wears it but has no saved outfit. Those cases need different player guidance and may follow different save paths.
Do not limit the audit to recently active players. The character returning after a month still expects their saved appearance to mean something.
Identify garments in the environment that knows them
FiveM clothing components and props belong to named collections. A global drawable index describes a position across those collections, while a local index describes a position inside one collection. Cfx.re documents how title updates can shift global indexes and why collection-relative identification helps. See the collection-based clothing guide.
For retirement work, the practical consequence is that you must resolve old identifiers while the matching ped, pack and build are still available. A bare number in an exported outfit record may not tell you which garment it represented after the resource set changes.
Build a reference catalogue for the affected pieces: ped model, component or prop slot, collection when available, drawable, texture and a small visual example. This catalogue is your migration evidence, not a new assumption that every appearance resource already supports collection-aware storage.
If your menu uses an older data format, follow its supported conversion path or build a tested adapter for that format. Changing field names in a saved JSON object is not sufficient by itself.
Choose between replacement, fallback and player choice
Some pieces have an obvious replacement. A retired work shirt might have a visually equivalent shirt in the new pack. Others do not. A distinctive coat should not silently become whichever item happens to occupy the same number.
For each affected piece, choose an explicit outcome. Map it to a tested replacement, apply a temporary fallback while preserving the original record, or ask the player to select a new garment the next time they use the wardrobe.
Consider the whole outfit when mapping. A jacket can require a different torso or undershirt combination. A replacement that looks correct in isolation may clip badly when inserted into the player's existing outfit. Include relevant paired components in the review.
For uniforms, get the responsible team to approve the resulting complete outfit. For personal clothing, provide a clear explanation of what changed and an easy route back into the appearance menu. Avoid presenting a forced replacement as though the player chose it.
Preserve the original when a fallback is shown
The dangerous failure is often a second write. The old garment is unavailable, the appearance resource displays a default, and an automatic save overwrites the original outfit with that default. The missing asset has now become lost information.
Review save triggers before the retirement. Check joining, respawning, changing characters, closing the wardrobe and switching uniforms. Decide which paths may persist a fallback and which should leave the preserved source data intact.
A fallback should carry an explicit status in your migration process, even if the player simply sees a normal outfit. That lets staff distinguish an intentional replacement from a temporary display used because a component could not be resolved.
FiveM's collection component native declaration specifies a ped, component, collection, local drawable, texture and palette. It applies a variation; it does not migrate your outfit database or decide how missing content should be saved. Those responsibilities remain in the appearance resource and your retirement procedure.
Stop creating new references before removing old ones
If practical, first hide the retiring pieces from new selection while keeping them available to render existing outfits. This reduces new references while you audit and migrate the old ones. Whether your appearance resource supports that distinction is something to verify on staging.
Update uniforms and presets during this phase too. Otherwise, a job menu can keep assigning an old garment after the personal wardrobe has stopped selling it.
Keep a migration marker or version where appropriate so repeating the process does not repeatedly modify already converted outfits. Produce a reviewable report of changed records, unresolved references and records left untouched. Save original values separately from the live result.
If you cannot support a gradual phase, schedule a controlled maintenance change with the full mapping prepared. Do not improvise mass numeric offsets after the pack has already vanished.
Rehearse with the old pack actually disabled
Test representative characters on a staging copy, including every supported ped model affected by the retirement. Include an active outfit, several saved outfits, a uniform and a prop where the pack supplies one.
Apply the proposed migration, disable the old pack, then load those appearances again. Try reconnecting, respawning, switching a uniform and saving a new outfit. Check that the old data backup remains intact through each path.
Also test a record you deliberately leave unmapped. It should follow the chosen fallback or selection policy without corrupting unrelated components. One unresolved hat should not reset the character's face or entire wardrobe.
The clothing conflict guide helps separate a bad component pairing from an asset conflict if a replacement renders incorrectly. Resolve those issues before turning the staging conversion into a live change.
Give retirement a verifiable finish
After the live change, inspect the unresolved-reference report and test the important appearance paths again. Keep a short support note naming the retired pack, the replacement policy and the information staff need to locate an affected outfit.
Retain the backup and migration evidence for a defined recovery period. Restoring the old pack alone may not restore outfits whose records were already rewritten, so your recovery plan must cover both assets and saved data.
The retirement is complete when new menus no longer assign the old content, existing outfits resolve according to the published policy, and returning players have a usable recovery path. That is a much better ending than discovering the removed coat was part of half the city's identity.
