Quick answer
Export with a method suited to the source engine, import into a separate compatible target, and compare both records and displayed text. Check the schema and application connection encoding as well as the dump. A successful import or matching row count cannot prove that characters survived.
Treat the database as a separate migration unit
A database is a separate part of a website migration. This guide uses MariaDB concepts where MariaDB is installed. Confirm source and target versions, schema, permissions and the write window before exporting. Use the database-user guide to prepare the target account.
Do not run a generic dump command against a live production database without checking table engines, consistency needs, size and available space. Keep the original database and a separate verified backup until application acceptance.
Record schema and encoding before export
Inventory the database name, tables, table engines, row counts for representative tables, database and column character sets/collations, stored routines and application connection character set. Choose records with accents, emoji or other non-ASCII characters for before-and-after comparison. MariaDB defaults have changed across versions; guessing that every target is UTF-8 can create mojibake. Record the export client and server versions.
Define a write freeze or synchronisation strategy. A dump started while the application continues writing may not represent one consistent point, especially across non-transactional tables. Ask the database operator to select the engine-supported consistency method and confirm backup restoreability.
Export and import into an isolated target
Use the source engine’s documented dump facility or provider-supported export, with the source character set handled explicitly. MariaDB’s mariadb-dump supports a default-character-set option and can emit a SET NAMES directive; source and target client versions matter because newer dump features may not import with older clients. Move the dump over an approved encrypted channel, protect it as sensitive data and import into the intended empty target database with the agreed target encoding and privileges.
Do not edit SQL bytes by hand to make characters “look right”. If an import reports syntax or collation errors, stop, preserve the dump and investigate version compatibility before retrying. Do not import over the old live database by name coincidence.
Compare data before changing traffic
Compare table counts and representative row counts, schema objects, and the recorded non-ASCII strings at the SQL layer and in the application UI. Inspect one write/read cycle on the target in a protected preview and confirm new text round-trips without replacement characters or double encoding. Check timestamps and binary or large content where the application uses them. A row count match alone does not prove semantic integrity.
If characters are wrong, stop cutover and determine whether the source bytes, dump client encoding, target schema or application connection causes the change. Restore the clean target from a fresh controlled import after correcting the cause; do not stack speculative ALTER statements over corrupted data. Keep the old database read-only or under the agreed rollback plan until acceptance.
Example: compare characters, not just row counts
Use a non-sensitive test record such as Café — 東京 — 🚀 if the application supports those characters. Record its source text, import the database, then compare it at the SQL layer and in the application. An emoji needs a character set that supports it, such as MariaDB utf8mb4; do not assume every setting called UTF-8 has that capacity.
If the source displays correct text but the target does not, keep traffic on the source and trace dump encoding, target columns and the application connection. Re-import into a clean target after correcting the cause; do not repeatedly convert already-corrupted text.
Retain a rollback and secure the dump
At cutover, perform the final delta or write freeze specified by the application owner, then point only the intended application configuration at the new database. Verify core user journeys, jobs and logs. If acceptance fails, restore the prior connection setting and reconcile writes made since the switch; returning to the old connection without that step can lose orders or updates.
Delete temporary dumps from public or shared locations after retention requirements are met, keeping approved backups separately. Escalate with engine versions, redacted errors, table/row comparisons and sample code points, not customer data or credentials.
Common questions
Does import success prove correct encoding? No. Compare representative stored and displayed characters.
Should I change the target default collation? Only with application and schema compatibility evidence.
Can a DNS rollback restore database writes? No. Data reconciliation is separate.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.