Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления

[gl00mie]

Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю. Если у компании достаточно большая база, и компания не хочет переходить лишь со справочниками и начальными остатками, то возможность конвертации такой большой базы стандартными средствами в приемлемые сроки может стать серьезным препятствием: обычно простой приемлем в течение выходных (т.е. в районе 60-и часов, включая вечер пятницы и утро понедельника), в то время как стандартный способ конвертации базы представляется, мягко говоря, далеким от оптимального.
Что предлагается сделать при штатной конвертации базы:

• перевести базу на левое выравнивание;
• удалить из базы данные, которые не предполагается переносить, т.е. затраты времени на перенос которых не оправданы (всякие там логи, параметрические таблицы для обработки заказов/закупок и т.п);
• с помощью отдельной утилиты создать слепок базы 3.0, подготовленный для AX 2009 (с данными, конвертированными в Unicode, с 64-битными полями под RecId, но со схемой от базы 3.0); утилита не разбирает, какие таблицы переносит, поэтому чтобы не переносить лишнее, нужен предыдущий шаг;
• с помощью скриптов конвертации:
  • перенести часть данных из удаляемых полей в новые (например, из createdTime/modifiedTime - в createdDateTime/modifiedDateTime);
  • заполнить часть новых полей константами либо значениями других полей той же записи (например, новые поля с MST-суммами могут заполняться из полей с валютными суммами при условии совпадения валюты проводки и основной валюты компании);
  • перебить значения некоторых enum'ов на новые (т.е. было значение 200, стало 5);
  • ну и выполнить какие-то нетривиальные преобразования.

Мне лично непонятно, зачем нужно тратить столько драгоценного времени на тупое перелопачивание одних и тех же данных, если кучу перечисленных действий можно было бы выполнить в рамках одного этапа - создания слепка базы 3.0, подготовленного для AX 2009. Ведь можно было бы на лету:

• переводить данные на левое выравнивание;
• заполнять поля типа UtcDateTime из имеющихся старых пар полей типа date + time (а это в скриптах конвертации реализовано офигенски неэффективно);
• перебивать значения enum'ов;
• заполнять новые либо незаполненные старые поля, если их значения можно легко и просто вычислить из других полей записи либо вообще задать константами;
• выбирать, какие таблицы не переливать вовсе;
• фильтровать переливаемые таблицы, чтобы не переливать лишние данные (всякие там отмененные/закрытые и т.п. записи либо записи с датой ранее заданной);
• и много чего еще...

При всем при этом за счет сокращения числа промежуточных "переделов" базы можно также сократить число создаваемых по ходу конвертации резервных копий, что даст дополнительный выигрыш во времени. В общем, отсюда вопрос: почему стандартная конвертация сделана так неэффективно? Я уже молчу про скрипты перебивки енумов, которые зачем-то запускаются в разрезе компаний вместо выполнения одного прямого SQL-запроса, но зачем же столько ненужных промежуточных действий?..
Кто как боролся с этими проблемами - из тех, кому уже приходилось участвовать в переходе на 2009-ю с конвертацией имеющейся базы? Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход... Какие еще есть варианты?