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

> Ce qui arrive aux looks existants de vos joueurs en passant à RCO Appearance.

Version courte : **les joueurs gardent leur apparence**, vous **ne** convertissez **pas** toute la base à l'installation, et vous **n'avez pas** besoin d'importer du SQL sur un serveur normal.

## Ce qui se passe vraiment

Chaque personnage migre **individuellement, la première fois qu'il se connecte** après le changement :

1. Le joueur sélectionne son personnage.
2. Appearance vérifie : avons-nous déjà un look enregistré dans `rco_appearance` ?
3. **Oui** → on l'utilise. Terminé.
4. **Non** → lit ses **anciennes données framework stock**, convertit, enregistre une ligne dans `rco_appearance`.
5. À partir de là, **RCO est la source de vérité** pour ce personnage. Les anciennes tables ne sont plus lues pour le gameplay.

Rien ne supprime en masse vos anciennes tables. Elles peuvent rester en base comme sauvegarde — Appearance cesse juste de les utiliser pour les enregistrements.

<Tabs>
  <Tab title="RSG Core">
    Lit la ligne du personnage dans **`playerskins`** (`skin` et `clothes`). Le stock `rsg-appearance` **n'a pas** besoin de tourner.

    Après migration, Appearance **n'écrit plus** dans `playerskins`. C'est pourquoi `rsg-barbers` doit être arrêté — une coupe là enregistrerait dans une table que personne ne lit.
  </Tab>

  <Tab title="VORP Core">
    Lit la skin/composants enregistrés du personnage actif depuis **VORP Core / base de données**.

    Le stock **`vorp_character` doit rester arrêté** — mais les données déjà en DB restent lisibles.

    Les skins VORP neuves vides ignorent la migration ; elles passent par le créateur RCO normalement.

    Appearance **n'écrit pas les données RCO dans les colonnes skin VORP** — les formats ne correspondent pas.
  </Tab>
</Tabs>

## Ce que la migration n'est pas

* **Pas** un job unique qui convertit chaque ligne serveur vide.
* **Pas** automatique pour des systèmes d'apparence tiers stockés ailleurs.
* **Pas** une sync bidirectionnelle. Éditer les anciennes tables après migration ne met pas RCO à jour.

<Note>
  Des données anciennes invalides ou vides sont ignorées plutôt qu'enregistrées en mesh cassé. Le joueur devra peut-être reconstruire son look au créateur ou en boutique.
</Note>

## Checklist simple

1. Sauvegarde base (toujours avant un gros changement).
2. Arrêtez les ressources d'apparence stock ([Installation](/fr/rco-appearance/installation)).
3. Démarrez Appearance (+ Creator si vous l'utilisez).
4. Laissez les joueurs se connecter.

Base de joueurs énorme ? Activez `Config.Debug` brièvement le premier jour — les lignes de migration apparaissent en console, y compris les personnages non convertis.

## Scripts tiers

Les scripts qui **lisent seulement** l'apparence via les exports de compatibilité fonctionnent en général toujours.

Les scripts qui **écrivent** d'anciennes tables SQL ou des blobs skin complets doivent être mis à jour — voir [Compatibilité](/fr/rco-appearance/compatibility).