We downloaded a database back up via UpdraftPlus from the Azure WordPress. And the problem became pretty clear. Take a look at the Storage Engine and Collation of the create query:
CREATE TABLE `wp_options` (
`option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`option_name` varchar(191) COLLATE utf8mb4_unicode_520_ci NOT NULL DEFAULT '',
`option_value` longtext COLLATE utf8mb4_unicode_520_ci NOT NULL,
`autoload` varchar(20) COLLATE utf8mb4_unicode_520_ci NOT NULL DEFAULT 'yes',
PRIMARY KEY (`option_id`),
UNIQUE KEY `option_name` (`option_name`),
KEY `autoload` (`autoload`)
) /*!50100 TABLESPACE `innodb_system` */ ENGINE=InnoDB AUTO_INCREMENT=214 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;
On DreamHost, we edited every database table to have the same storage engine and collation as the Azure MySQL database tables. We just opened up good old phpMyAdmin and adjusted each table via table options, like so:
Just to be clear that’s changing:
Storage Engine:
MyISAM -> InnoDB
Collation:
utf8mb4_unicode_ci -> utf8mb4_unicode_520_ci
We then took a database export directly from phpMyAdmin and ran it through Workbench. Viola! The whole database transferred succesfully.
Actual Problem
I’m not sure exactly why this wouldn’t work initially, but… My speculation is the Azure MySQL database is in a Windows environment and the DreamHost MySQL database is in a Linux environment. So somewhere there are probably database configurations that don’t line up.