Информации много и она свалена в кучу - фиг разберешь, если с этим не сталвивался. Начинается сообщение с БД, переключается в приложение (в код) и заканчивается опять БД. Интересно посмотреть на людей, кто одновременно конвертирует формы и производит синхронизацию
(особенно на реальных данных). Было бы логичнее написать:
1. Готовим приложение. Обращаем внимание на те элементы, которые изменились и преобразовываем код "к четверке". Попутно конечно можно вообще пересмотреть весь свой функционал - но это уже кому как нравится. Приложение можно готовить на пустой БД.
Думаю, что этот пункт займет от двух недель до.... края бюджета, выделенного на переход на новую версию
2. Готовим БД (пробуем обновить данные на копии рабочей БД) для тестирования приложения. Изучаем все грабли подложенные Микрософтом, попутно разбирая сделанные свои грабли. На диске к 4-ке кстати - это есть как проект с выравниванием типов данных (в котором надо не забыть исключить типы из СНГовых модулей) и пресловутый AxDbUpgrade.exe.
3. Известные свои грабли (обновление данных) добавляем либо в список обновления до синхронизации (классы ReleaseUpdateDB39_*), либо после синхронизации (классы ReleaseUpdateDB401_*). Убеждаемся в отсутствии var/bus слоев.
4. Запускаем процесс перелива данных по изученному в п.2 алгоритму. Попутно ставим 4-ку (АОСы, клиенты и т.д.)
5. Натравливаем подготовленное в п.1 и п.3 приложение на получившуюся БД. Если есть проблемы с запуском - можно вообще приложение без модификаций натравить - лишь бы сформировался пользователь и появилась возможность загрузить лицензии.
6. Смотрим контрольный список обновления. На глоб компиляцию забиваем, если мы ее уже сделали в п.3. Загружаем лицензии и возвращаемся с чистого приложения на свое (если такая подмена делалась). Рестартуем АОС, чтобы он "скушал" лицензии.
7. Не вижу смысла запоминать что где какие поля переименовались. Всего не упомнишь. Есть процедура обновления данных до и после синхронизации. Если после ее выполнения остались грабли - их (грабли) нужно собирать и фиксировать в ReleaseUpdate-классах. Базу-то затем и готовим - чтобы можно было тестировать.
8. После отработки контрольного списка - 4-ка готова. Можно тестить. Все это тестится, исправления вносятся в приложение (в т.ч. в классы ReleaseUpdate*).
9. После массового сбора ошибок - запускается снова процедура переливки БД чтобы "засечь" время и оценить реальное время, которое будет потрачено.
10. Ну и наконец - в час Х все запускается на рабочей БД.