The source site supports utf8mb4 data but the target does not and unknown collation errors

The source site supports utf8mb4 data but the target does not, aborting migration to avoid possible data corruption. (#148)

If the source database of a migration supports utf8mb4 encoded strings and the target database does not, WP Migrate DB Pro will abort the migration if it discovers a table being migrated that is set to use utf8mb4, as converting it to utf8 may mean losing extended character set data. Additionally, you may encounter an “Unknown collation: ‘utf8mb4_unicode_ci'” MySQL error.

WordPress has supported utf8mb4 encoded data since version 4.2, and automatically updates the database tables to use utf8mb4 rather than utf8 during the first upgrade to 4.2+ or when installing 4.2+ from scratch. This only happens if the version of MySQL being used supports utf8mb4 (5.5.3+).

utf8mb4 uses 4 bytes to store each character of a string as opposed to utf8’s 3 bytes, and can store an extended set of characters. See http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html for more information.

If you are confident that no extended character set data is being used that requires utf8mb4 and want to migrate to a utf8 based database, you can override this safety feature by adding a handler for the ‘wpmdb_abort_utf8mb4_to_utf8‘ filter and returning false. See our WP Migrate DB Pro Tweaks plugin for an example.

Alternately, you should consider updating your destination server’s MySQL server to version 5.5.3 or higher, as this will allow you to migrate between the two sites without needing to change your data’s collation.