> ## 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.

# Migración

> Qué pasa con los looks existentes de tus jugadores al cambiar a RCO Appearance.

Versión corta: **los jugadores conservan su aspecto**, **no** conviertes toda la base de datos al instalar, y **no** necesitas importar SQL en un servidor normal.

## Qué ocurre realmente

Cada personaje migra **individualmente, la primera vez que entra** tras el cambio:

1. El jugador selecciona su personaje.
2. Appearance comprueba: ¿ya tenemos un look guardado en `rco_appearance`?
3. **Sí** → lo usa. Listo.
4. **No** → lee sus **datos stock del framework**, convierte, guarda una fila en `rco_appearance`.
5. A partir de ahí, **RCO es la fuente de verdad** para ese personaje. Las tablas antiguas no se leen de nuevo para gameplay.

Nada borra masivamente tus tablas antiguas. Pueden quedarse en la base como respaldo — Appearance deja de usarlas para guardar.

<Tabs>
  <Tab title="RSG Core">
    Lee la fila del personaje en **`playerskins`** (`skin` y `clothes`). El stock `rsg-appearance` **no** necesita estar activo.

    Tras la migración, Appearance **no escribe de vuelta** en `playerskins`. Por eso `rsg-barbers` debe pararse — un corte ahí guardaría en una tabla que nadie lee.
  </Tab>

  <Tab title="VORP Core">
    Lee la skin/componentes guardados del personaje activo desde **VORP Core / base de datos**.

    El stock **`vorp_character` debe seguir parado** — pero los datos ya en la DB siguen siendo legibles.

    Skins VORP nuevas vacías saltan la migración; usan el creador RCO con normalidad.

    Appearance **no escribe datos RCO de vuelta en las columnas de skin de VORP** — los formatos no coinciden.
  </Tab>
</Tabs>

## Qué no es la migración

* **No** es un trabajo único que convierte cada fila con el servidor vacío.
* **No** es automática para sistemas de apariencia de terceros que guardaron looks en otro sitio.
* **No** es sincronización bidireccional. Editar tablas antiguas tras migrar no actualiza RCO.

<Note>
  Datos antiguos rotos o vacíos se omiten en lugar de guardarse como mesh glitcheado. El jugador puede necesitar reconstruir su look en el creador o en una tienda.
</Note>

## Checklist simple

1. Copia de seguridad de la base (siempre antes de cambios grandes).
2. Para recursos stock de apariencia ([Instalación](/es/rco-appearance/installation)).
3. Arranca Appearance (+ Creator si lo usas).
4. Deja que los jugadores entren.

¿Nervioso con muchos jugadores? Activa `Config.Debug` brevemente el primer día — las líneas de migración aparecen en consola, incluidos personajes que no pudieron convertirse.

## Scripts de terceros

Scripts que **solo leen** apariencia por exports de compatibilidad suelen seguir funcionando.

Scripts que **escriben** tablas SQL antiguas o blobs completos de skin necesitan actualización — ver [Compatibilidad](/es/rco-appearance/compatibility).