Миграция с SQL Server на MariaDB / MySQL. Что делать с XML

осмелюсь предположить, что цена лицензии на MsSQL… гляньте спортивного интереса ради MsSQL enterprise. изначлаьно, возможно, велась разработка использую express или bizspark лицензию для стартапов… а потом халява закончилась и встал вопрос платить или переезжать

Я не конца понимаю что было в головах продакт менеджеров, но основная идея мне кажется на поверхности. SQL Server стоит денег и если мы можем предложить продукт тем для кого эти деньги существенные, но им не столь важны фичи SQL Server почему бы это не сделать.

Да, использовались. В MariaDb / MySQL тоже есть поддержка курсоров: mariadb.com/kb/en/mariadb/cursor-overview/ правда только non-scrollable но нам такие и требовались. Хотя разумеется часто код написанный с курсорами можно переписать без них.

	DECLARE vHost VARCHAR(512);

	DROP TEMPORARY TABLE IF EXISTS __HostsToProcess__;
	CREATE TEMPORARY TABLE __HostsToProcess__ ENGINE=MEMORY 
               AS SELECT Host FROM User;
	WHILE EXISTS (SELECT 1 FROM __HostsToProcess__ LIMIT 1) DO
	    SET vHost = (
                   SELECT Host FROM __HostsToProcess__ LIMIT 1);
	    SELECT CONCAT("Process host: ", vHost);
	    DELETE FROM __HostsToProcess__ 
                   WHERE Host = vHost;
	END WHILE;
	DROP TEMPORARY TABLE IF EXISTS __HostsToProcess__;

Наверное это достойно отдельной статьи. Но если совсем кратко то полуавтоматически )
Что касается конвертации процедур то подход был такой:
Был powershell скрипт для предварительной подготовки текста, с теми заменами которые можно сделать с помощью regexp, например типы данных XML->LONGTEXT,UNIQUEIDENTIFIER->BINARY(16), и т.д., эквивалентные функции GETDATE()->UTC_TIMESTAMP(3), переименование переменных и параметров (тут было немного магии).
И после переписывались места для которых не было эквивалентной функциональности. Например где используются CTE, аналитические функции, конструкции IF THEN ELSE END IF (в T-SQL отличаются), и т.п.
Но в простых случаях после конвертации оставалось только расставить точки с запятой в конце statement-ов. Поначалу было медленно но потом разогнались и в итоге в день на человека выходило до 20 процедур. Причем большую часть времени занимало написание тестовых скриптов. В MariaDB / MySQL есть такая же проблема как в T-SQL пока вы не вызовете хранимую процедуру вы можете даже не узнать что у вас нет каких то таблиц или полей, поэтому без тестовых скриптов нельзя. Особенно пока не хватает функциональности для запуска интеграционных тестов на уровне бизнес слоя.
Что касается конвертиации DAC была предпринята попытка сделать код универсальным, в конце концов ведь нам нужно передать в хранимые процедуры одни и те же параметры и прочитать из резалт сета одни и те же поля. Типы на уровне БД отличаются но не отличаются на уровне приложения, таким образом фактически нужно только применять разные правила для data mapping и по другому обработать ошибки и исключения из БД.

Трудно залезть в чужую голову, но возможно у предидущего разработчика были на это причины совершенно невредоносного характера. Например — требования к производительности или функциональности. Например пользователи могут сохранить свои фильтры которые нужно применять автоматически в background-е, и он не смог придумать решения лучше…

Но так или иначе если вы видите сейчас более правильное / красивое / эффективное решение скорее всего это можно исправить.
T-SQL хранящийся в таблицах в БД, если я правильно понял суть проблемы, не отличается от хранимых процедур, его тоже можно переписать изменив подход, разве нет?

Если вернутся к dynamic SQL — то его главный недостаток в SQL Server в том что он забивает квери кэш который становится большим и теряет эффективность. (В MariaDb такой проблемы нет по той причине, что query cache там лучше даже не включать :)