Convert MySQL Database Charset/Engine

The Problem

Your database is on an outdated character set (like latin1) or storage engine (like MyISAM) that's causing problems — broken special characters, no foreign key support, or no transaction safety — but converting carelessly risks corrupting the very data you're trying to fix.

About this problem

Converting character set or storage engine after a database already has data is meaningfully riskier than setting it correctly from the start, since a naive conversion can silently corrupt text that was already mis-encoded, or a MyISAM-to-InnoDB conversion can expose foreign key or locking behaviour differences the application wasn't written to expect.

This typically comes up when modernising an older application's database, fixing emoji/special-character display issues, or needing InnoDB's transaction and foreign key support that MyISAM doesn't offer.

What's Included

• Assessing the current charset/engine and confirming exactly what needs converting and why
• Taking a full backup before any conversion work begins
• Converting with the correct method to avoid double-encoding or data corruption
• Verifying data integrity thoroughly after conversion, especially any text with special characters

What's NOT Included

• Fixing data that was already corrupted before the conversion (that needs a separate data-recovery conversation)
• Application code changes needed to take advantage of new engine features (e.g. adding foreign keys) beyond the conversion itself
• Guaranteeing zero behavioural change — InnoDB and MyISAM do have genuine differences in locking and constraint behaviour

How It Works

1. Take a full backup of the database before making any changes, since conversion mistakes can be destructive.
2. Assess whether existing text data is already correctly encoded, since converting mis-encoded data naively can make it worse (double-encoding).
3. Perform the character set or engine conversion using the appropriate method for the specific situation, which differs depending on whether data is already correctly encoded.
4. Spot-check converted tables, especially any with non-Latin characters or emoji, against the pre-conversion backup.
5. Test the application fully against the converted database to confirm no unexpected behavioural differences from the new engine.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

Why should I convert from latin1 to utf8mb4?

latin1 can't properly store many Unicode characters including emoji, while utf8mb4 can — converting fixes garbled text and prevents future encoding issues with international characters.

Is converting MyISAM to InnoDB risky?

It's generally safe when done carefully with a backup first, but InnoDB's foreign key and locking behaviour differs from MyISAM, so testing the application afterwards matters as much as the conversion itself.

Will converting character set fix already-garbled text?

Not automatically — text that's already mis-encoded needs to be identified and handled specifically during conversion, since naively converting already-broken data can make it permanently unreadable.

What's the benefit of InnoDB over MyISAM?

InnoDB supports transactions, foreign key constraints and row-level locking, all of which MyISAM lacks — most modern applications expect or benefit from these.

Can I convert a live production database without downtime?

Smaller databases can often convert quickly enough to feel seamless, but larger ones may benefit from a brief maintenance window to avoid any risk of writes happening mid-conversion.

How do I check my database's current character set and engine?

Querying information_schema.TABLES and information_schema.SCHEMATA shows the current character set, collation and storage engine for each table and database.