> ## Documentation Index
> Fetch the complete documentation index at: https://rust-co.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Migration

> What RCO can migrate automatically, what it cannot, and how to move a live server safely.

Migration is the page to read **before** replacing an appearance system on a live server.

The most important rule is this: RCO knows how to migrate the supported **stock RSG/VORP appearance data**. It cannot guess the schema or meaning of every third-party appearance resource.

## Supported path

For a character that does not yet have an RCO appearance:

```text theme={"dark"}
Character becomes active
  ↓
RCO checks for a canonical rco_appearance snapshot
  ↓
Found? → use it
  ↓
Missing? → try supported legacy framework data for that exact character
  ↓
Convert / capture a valid RCO snapshot
  ↓
Persist it
  ↓
From then on, RCO is the source of truth
```

Migration is per character. RCO does not need to bulk-convert every offline character during installation.

<Tabs>
  <Tab title="RSG Core">
    The supported legacy source is the stock RSG appearance data used by `rsg-appearance` / `playerskins` for the **same citizen/character**.

    After RCO owns the character, old appearance tables are no longer the save target.
  </Tab>

  <Tab title="VORP Core">
    The supported legacy source is the stock VORP character appearance/components for the **active VORP character**.

    `vorp_character` itself must remain stopped, but its existing data can still be used as the legacy source during conversion.
  </Tab>
</Tabs>

## What is not automatically migrated

A custom system that stores appearance in its own tables or uses a private blob format is **not** automatically supported just because it runs on RSG or VORP.

Examples:

* a third-party multicharacter that writes its own skin table;
* a clothing resource that saves custom numeric indexes instead of RDR2 shop hashes/components;
* a barber that persists only hair in a separate custom table;
* a server that heavily changed the stock schema.

In those cases, build a deliberate converter or have players rebuild their appearance. Do not point two systems at the same live characters and hope they converge.

## RCO does not delete your old data

Legacy tables can stay in the database as a backup. RCO simply stops treating them as authoritative after a canonical RCO snapshot exists.

That is useful during rollout: you can verify migrated characters before deciding whether old tables can be archived later.

## Live-server migration checklist

1. Take a database backup.
2. Clone the server or make a staging environment.
3. Stop the resources RCO replaces.
4. Test at least one male and one female character with real existing clothing/hair.
5. Test a character that has unusual/NPC-style clothing if your old resource supported it.
6. Save a new RCO change, relog, and confirm the old system does not overwrite it.
7. Only then roll the change to production.

<Warning>
  Do not advertise automatic migration from a third-party appearance resource unless you have actually written and tested a converter for that resource. Stock RSG/VORP compatibility does not imply arbitrary third-party compatibility.
</Warning>