How to migrate characters between accounts in MU Online

Migrating a character from one account to another is a common request in MU Online server administration. A player lost access to the old account's email, wants to consolidate their best characters into a single account, bought a character from another player, or you need to move a char from a banned account to a clean one. The game interface offers none of this — migration is a database operation, and done carelessly it wipes out items, duplicates records, or leaves the character inaccessible. This tutorial shows the safe path.

The core concept you need to master: in MU Online, a character belongs to an account, and that relationship is recorded in one or more tables. Migrating means repointing the character to the destination account, making sure the new owner has a free slot and that no auxiliary table (warehouse, guild, events) is left with a broken link. The most common mistake is thinking it's enough to change one field — in practice, depending on the emulator, the link appears in several places. All the table and column names here are common examples whose naming varies by season/emulator (IGCN, MuEmu, Season 6, X-Files, etc.); always confirm your server's real schema.

Prerequisites

Migration is a delicate operation with a risk of item loss. Prepare yourself:

• SSMS with write access to the MuOnline database (or your emulator's equivalent).
• A complete, validated backup of the database before any change.
• Confirmation of the requester's identity. An improper migration is a classic vector for scams and account theft.
• Source and destination accounts identified precisely (account name / AccountID).
• A maintenance window with the services shut down to avoid cache overwrites.
• A test environment where you validate the migration before applying it in production. If you're still building the base, start with how to create a MU Online server.

Understanding the character-account link

Before moving anything, understand where the link lives. In the typical model, three tables take part (example names, varying by season/emulator):

Note the most important point: on many emulators the account-character link exists in two places — in the AccountCharacter table (which lists the characters by the account's slot) and in the AccountID column of the Character table itself. Migrating by touching only one of the two is the number-one cause of a character that "disappears" or shows up in two accounts. You need to update both in a coordinated way.

The items, on the other hand, live in two distinct places: the inventory travels with the character (stored in the Character table itself as a binary field or in an item table tied to the character), but the warehouse belongs to the account, not the character. This means items stored in the source account's warehouse do not automatically go along — they stay with the old account. Tell the player to empty the warehouse first, or handle the warehouse separately.

Step 1: Verify source and destination

Never migrate blindly. Confirm the data for both accounts and the character:

-- Source account and character slots (example)
SELECT ac.Id        AS Conta,
       ac.GameIDC   AS Personagem,
       ac.Number    AS Slot
FROM AccountCharacter ac
WHERE ac.Id = 'ContaOrigem';

-- Occupied slots in the destination account
SELECT ac.Id, ac.GameIDC, ac.Number
FROM AccountCharacter ac
WHERE ac.Id = 'ContaDestino';

Check two things: that the character is really in the source account and that the destination account has at least one free slot. If all of the destination's slots are occupied, pick a vacant slot or ask the player to free one up.

Step 2: Mandatory backup

Generate and validate the backup before touching any record:

BACKUP DATABASE MuOnline
TO DISK = 'D:\Backups\MuOnline_pre_migracao.bak'
WITH FORMAT, INIT, NAME = 'Pre character migration backup';

RESTORE VERIFYONLY
FROM DISK = 'D:\Backups\MuOnline_pre_migracao.bak';

A migration is reversible only if you have the previous state. Keep the backup off the production server.

Step 3: Execute the migration

With the services shut down, do the migration inside a transaction. The core is to update both ends of the link — AccountCharacter and the AccountID column of Character:

BEGIN TRANSACTION;

-- 1. Repoint the character's slot to the destination account
UPDATE AccountCharacter
SET Id = 'ContaDestino'
WHERE GameIDC = 'NomePersonagem' AND Id = 'ContaOrigem';

-- 2. Update the AccountID in the character table (if that column exists)
UPDATE Character
SET AccountID = 'ContaDestino'
WHERE Name = 'NomePersonagem';

-- 3. Verification before committing
SELECT ac.Id AS Conta, ac.GameIDC, c.AccountID
FROM AccountCharacter ac
JOIN Character c ON ac.GameIDC = c.Name
WHERE ac.GameIDC = 'NomePersonagem';

COMMIT TRANSACTION;
-- In case of a discrepancy, use ROLLBACK TRANSACTION

Numbered steps to execute safely:

1. Shut down the GameServer and ConnectServer.
2. Take and validate the backup.
3. Confirm a free slot in the destination (Step 1).
4. Run the block inside BEGIN TRANSACTION.
5. Verify with the SELECT that both ends point to the destination account.
6. COMMIT if it's correct; ROLLBACK if not.
7. Bring the services up and ask the player to test logging into the destination account.

Step 4: Adjust the slot in the destination

If the character's slot number collides with a slot already occupied in the destination account, adjust the slot field (Number) to a free value. Slots usually run from 0 to 4 (five characters per account), but the maximum varies by emulator:

-- Move the migrated character to slot 3 (example, if it's free)
UPDATE AccountCharacter
SET Number = 3
WHERE GameIDC = 'NomePersonagem' AND Id = 'ContaDestino';

Never leave two characters from the same account in the same slot — that causes one to overwrite the other on the selection screen.

Step 5: Handle the account's warehouse and items

Since the warehouse belongs to the account, decide what to do with it. There are three common approaches:

1. Empty it first: the player removes the items from the source account's warehouse and puts them in the character's inventory before the migration. This is the simplest and safest.
2. Migrate the warehouse too: if the player is moving their only character and wants to take the warehouse, you also move the warehouse record from the source account to the destination — but be careful, this overwrites the destination's warehouse if it isn't empty.
3. Leave it at the source: the warehouse stays with the old account. Valid when the source account remains active.

Option 1 is the recommended one because it avoids item loss. Make it clear to the player which policy you use.

Step 6: Check the guild and residual links

The guild link normally references the character's name, not the account, so it usually survives the migration intact. Even so, confirm:

SELECT Name, G_Name, G_Level
FROM GuildMember
WHERE Name = 'NomePersonagem';

Also check for links in event, ranking, or VIP tables that reference the old account, if your emulator has benefits tied to the account rather than the character. Account benefits (VIP, coins) do not travel with the character.

Common errors and fixes

Launch checklist

Before considering the migration complete, go through:

• Requester's identity confirmed (anti-scam)
• Complete backup generated and validated with RESTORE VERIFYONLY
• Destination account exists and has a confirmed free slot
• GameServer and ConnectServer shut down during the operation
• AccountCharacter and Character's AccountID updated together
• Slot (Number) with no collision in the destination
• Verification SELECT showing both ends in the destination
• Warehouse/account-item policy defined and communicated to the player
• Guild link checked after the migration
• Services restarted and login tested on the destination account
• Migration recorded in the administration log

Migrating characters between accounts is a valuable service that builds player loyalty, but each migration touches links spread across several tables. Treat the two ends of the account-character relationship as inseparable, remember that the warehouse belongs to the account and not the char, and never operate without a validated backup and the services shut down. With that rigor, you deliver clean migrations, with no lost items or phantom characters.

Frequently asked questions