А как бы вы организовали контроль проекта?

[fed]

Ну я бы обозначил следующий основной риск при апгрейде с 3ки на 2009ую. В 2009ой локальный микрософт реализовал много функциональности, которая раньше была в партнерских решениях каждого партнера. На вскидку - профиль разноски по складу, товары в пути, комисионная торговля, загрузка курсов с сайта ЦБ, накладняк от третей организации и тп.
И при переходе надо будет по каждой такой фиче принять решение - использовать ли партнерскую версию функционала (то есть то что партнер во времена 3.0 напрограммировал), или микрософтовскую.
Если использовать микрософтовскую версию, то скорее всего возникнут очень большие проблемы с конвертацией старых данных (может оказаться что нужных для новой микрософтовской функциональности данных просто нет в системе). И может оказаться что проще залить в систему остатки и запуститься с нуля, чем пытаться сконвертировать исторические данные.
Если использовать партнерскую версию - то во первых не понятно зачем тогда вообще переход начинать, во вторых - трудозатраты на выкашивание новой микрософтовской функциональности могут превзойти затраты на перевнедрение.
И вот этот риск явно значительно серьезнее чем технические риски связанные с id объектов и временем апгрейда БД.

Так что, IMNSHO, Vals прав однако. Либо проект перевнедрения (с затратами порядка 40-60% от стоимости начального проекта), либо проект апгрейда, но с совершенно непредсказуемым бюджетом и сроками и падучим монстром сшитыми из кусочков партнерского и микрософтовского кода в результате.

В общем - я бы посоветовал начать проект с составления каталога той функциональности которая в вашей версии 3.0 была реализована партнером, а в версии 2009 - Микрософтом. Если списки не пересекаются (или пересекаются очень слабо) - вам повезло и вы можете апгрейдиться. Если списки сильно пересекаются - возможно стоит с самого начала подумать насчет перевнедрения.