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

# Migrating from AuthMe

> Bring existing accounts across, hashes included, without asking anyone to re-register.

```bash theme={null}
/rlogin migrate authme <path-or-jdbc-url>
```

Reads the other plugin's database directly and imports the accounts into
rLogin's own. Players keep their passwords — there is nothing for them to do.

## AuthMe

<Tabs>
  <Tab title="SQLite">
    Point it at the file:

    ```bash theme={null}
    /rlogin migrate authme plugins/AuthMe/authme.db
    ```

    A bare path is treated as SQLite automatically.
  </Tab>

  <Tab title="MySQL">
    Give it a full JDBC URL:

    ```bash theme={null}
    /rlogin migrate authme jdbc:mysql://127.0.0.1:3306/authme?user=root&password=secret
    ```
  </Tab>
</Tabs>

The importer reads `username`, `realname`, `password` and `ip` from the
`authme` table, and derives each account's offline UUID from the name.

### Which hashes carry over

| AuthMe hash                           | Result                                                                         |
| ------------------------------------- | ------------------------------------------------------------------------------ |
| **bcrypt** (`$2a$`, `$2b$`, `$2y$`)   | Works immediately. Players log in with their existing password.                |
| **AuthMe SHA-256** (`$SHA$salt$hash`) | Works immediately. rLogin verifies it and can re-hash to bcrypt on next login. |
| Anything else (MD5, XAUTH, …)         | The account is still imported, but that player must register again.            |

<Note>
  Unsupported hashes are listed individually in the import log, so you know
  exactly who to warn before you switch over.
</Note>

<Warning>
  Import into an **empty** rLogin database. Accounts that already exist are not
  overwritten, so a partial import can leave you with a confusing mix.
</Warning>

## nLogin

```bash theme={null}
/rlogin migrate nlogin plugins/nLogin/nlogin.db
```

nLogin records the **real Mojang UUID** for accounts it verified as premium,
and that column is read when present — so a premium player keeps the identity
they already had instead of arriving as a new offline account.

## JPremium and LoginSecurity

```bash theme={null}
/rlogin migrate jpremium plugins/LoginSecurity/LoginSecurity.db
```

Both are read by the same importer; their tables are close enough in shape.

<Note>
  Table and column names differ between versions of all three plugins, so they
  are discovered rather than assumed. If yours is not recognised the import
  says exactly that instead of failing with a database error — open an issue
  with your plugin version and it can be added.
</Note>

<Warning>
  Only **bcrypt** hashes carry across from these two, plus AuthMe's own
  SHA-256. Accounts on anything else are still imported, so the player keeps
  their name and identity, but they must register again — and each one is
  named in the import log.
</Warning>

## After importing

<Steps>
  <Step title="Check the log">
    The console reports how many accounts were read, how many were imported, and
    which hashes could not be carried across.
  </Step>

  <Step title="Decide on uuid-type">
    Imported accounts use the **offline** UUID, matching what AuthMe used. If
    you plan to run [`uuid-type: real`](/rlogin/features/premium-auth#uuid-type),
    your premium players will arrive as new accounts — which is usually what you
    want, but it is better to know beforehand.
  </Step>

  <Step title="Remove the old plugin">
    Two authentication plugins running at once will fight over the same events.
  </Step>
</Steps>