Сколько стоит миграция legacy-приложения на VB6 или VB.NET: как оценить сроки и бюджет

Вопрос «сколько стоит перенести нашу систему на .NET» обычно задают в момент, когда тянуть уже некуда: у .NET 8 поддержка заканчивается 10 ноября 2026 года, сборочная машина VB6 держится на одном старом ноутбуке, а аудитор не подписывает акт с компонентами без обновлений. Ответ «зависит» никого не устраивает, поэтому ниже — способ получить цифру, за которую не будет стыдно через полгода.

Оценивать можно своими силами, если в команде есть люди, знающие и старый, и новый стек. Если таких нет или миграцию нужно провести с фиксированным объёмом и сроком, проект часто отдают подрядчику, который берёт разработку под ключ: от аудита и сметы до запуска новой версии и вывода старой из эксплуатации. В обоих случаях логика оценки одинакова, и её полезно понимать заказчику, чтобы спорить со сметой по существу.

Технические детали самого переноса мы разбирали отдельно: план миграции VB6 на .NET и поэтапный переход с Web Forms на ASP.NET Core и Blazor. Здесь — только деньги и сроки.

Почему смета на миграцию так часто ошибается?

Короткий ответ: потому что оценивают видимую часть системы, а платят за невидимую. Код, который можно открыть в IDE, конвертер закрывает за дни. Недели и месяцы уходят на то, что в коде не записано явно.

• Скрытые правила. За двадцать лет в обработчики кнопок и хранимые процедуры зашили десятки бизнес-правил, о которых никто не помнит. Их приходится восстанавливать по поведению системы, и на плохо документированных проектах это увеличивает трудоёмкость в полтора-три раза.
• Сторонние компоненты. Каждый брошенный вендором OCX или DLL — это отдельная мини-миграция: найти замену, переписать использующие его формы, сверить поведение.
• Данные. Форматы дат, кодировки, пустые значения, двоичные файлы собственного формата. Перенос и очистка данных регулярно оказываются отдельным проектом внутри проекта.
• Окружение. 32-битные драйверы, регистрация COM, права на каталоги, печать. Всё это нужно воспроизвести или заменить на новой платформе.
• Отсутствие тестов. Если нет эталона, нечем доказать, что новая версия считает так же, как старая. Создание этого эталона почти никогда не попадает в первую смету.

Отсюда главное правило: смета без инвентаризации — это не оценка, а предположение. Хорошая новость в том, что инвентаризация занимает дни, а не месяцы, и её можно сделать до того, как подписан основной договор.

Из чего складывается бюджет миграции?

Если разложить типичный проект переноса legacy-системы по статьям, картина получается довольно устойчивой. Доли ниже — ориентир для проверки сметы, а не норматив: в конкретном проекте они сдвигаются в зависимости от состояния кода и требований.

• Анализ и инвентаризация — 5–10 %. Сбор зависимостей, оценочный прогон конвертера, пилотный перенос одного модуля, итоговая смета и план этапов.
• Перенос кода и доработка — 40–55 %. Конвертация или переписывание логики и интерфейса, замена компонентов, исправление того, что инструмент перевёл неверно.
• Тестирование и сверка — 15–25 %. Подготовка эталонов, характеризационные тесты, сравнение результатов, параллельная работа двух версий.
• Данные и интеграции — 10–15 %. Миграция схемы и данных, адаптация обменов с внешними системами, переписывание импорта и экспорта.
• Развёртывание, обучение, документация — 5–10 %. Установщики, инфраструктура, инструкции для пользователей и администраторов.
• Резерв на риски — 15–30 % сверху. Не «запас подрядчика», а честная плата за неопределённость. Чем хуже документирована система, тем больше резерв.

Если в предложении нет строки про тестирование или данные, это не значит, что работы будет меньше. Это значит, что её оплатят позже, уже без договорённостей.

Что удорожает миграцию VB6, VB.NET и Web Forms?

У каждого legacy-стека свои дорогие места. Их стоит найти на этапе инвентаризации и оценить отдельно, а не размазывать по общей ставке.

VB6. Самые дорогие пункты — сторонние OCX (гриды Sheridan и ComponentOne, MSFlexGrid, Winsock, MSComm), позднее связывание через CreateObject, объект Printer и рисование на форме, вызовы Win32 API со структурами и указателями, двоичные файлы через Get и Put. Конвертеры закрывают большую часть синтаксиса, но именно эти места дорабатывают руками.

VB.NET на .NET Framework. Здесь язык переносится почти бесплатно, а платят за технологии, которых нет в современном .NET: WCF-сервер, Remoting, AppDomain, BinaryFormatter, часть контролов WinForms. Отдельная статья расходов — ресурсы форм и сериализация настроек. Подробности — в разборе переноса WinForms на современный .NET.

ASP.NET Web Forms. Прямого пути на ASP.NET Core нет, поэтому интерфейс по сути переписывается; Microsoft описывает варианты в руководстве по переходу с ASP.NET на ASP.NET Core. Удорожают ViewState-логика, UpdatePanel, серверные контролы сторонних вендоров, GridView с шаблонами и сложной привязкой. Как выбирать замену таблицам, мы разбирали в статье о альтернативах GridView.

Общее для всех. Отчёты Crystal Reports — почти всегда отдельный поток работ со своей сметой (варианты замены). Интеграции, о которых не знает никто, кроме внешней системы, которая вдруг перестаёт получать файл. И люди: если последний разработчик ушёл, часть бюджета уходит на археологию.

Как посчитать трудоёмкость по инвентаризации

Метод, который даёт воспроизводимый результат, — оценка по единицам. Систему раскладывают на элементы, у каждого типа элемента есть базовая трудоёмкость, а сложность учитывается коэффициентом.

1. Соберите перечень. Формы и страницы, отчёты, сторонние компоненты, интеграции, таблицы базы данных, пакетные задания и сервисы. Источник — сам код плюс интервью с пользователями: они знают, какими экранами пользуются, а какие мёртвые.
2. Отбросьте мёртвое. В старых системах заметная часть форм и отчётов давно не используется. Подтвердите это логами или опросом и не переносите их — это самый дешёвый способ сократить бюджет.
3. Классифицируйте по сложности. Простая форма ввода, форма с гридом и расчётами, сложный экран с печатью и сторонним контролом. Для каждого класса задайте базовую оценку в часах.
4. Добавьте коэффициенты среды. Нет документации, нет тестов, нет доступа к авторам кода, много позднего связывания — каждый фактор увеличивает оценку.
5. Проверьте пилотом. Перенесите один типичный модуль и сравните фактические часы с расчётом. Расхождение покажет, какой коэффициент поправить для всей системы.
6. Добавьте сквозные работы и резерв. Тестирование, данные, развёртывание и резерв на риски — по долям из раздела выше.

Учётная система на VB6, 40 форм, 25 отчётов, 6 сторонних OCX

Формы:   12 простых  × 6 ч   =  72 ч
         20 средних  × 16 ч  = 320 ч
          8 сложных  × 40 ч  = 320 ч
Отчёты:  25 × 10 ч           = 250 ч
OCX:      6 × 40 ч           = 240 ч
Интеграции: 4 × 30 ч         = 120 ч
---------------------------------------
База переноса                = 1322 ч
× 1,4 (нет документации и тестов)
                             ≈ 1850 ч
+ тестирование и сверка 25 % ≈  460 ч
+ данные и развёртывание 15 % ≈ 280 ч
+ резерв 25 %                 ≈ 650 ч
---------------------------------------
Итого                         ≈ 3240 ч

Цифры в примере условные: базовые часы на единицу у каждой команды свои, и их надо калибровать пилотом. Ценность метода в другом — каждую строку можно обсудить отдельно. Заказчик видит, что 240 часов уходят на компоненты, и может решить, что два из шести OCX проще заменить стандартными контролами без сохранения внешнего вида. Перед стартом полезно пройти чек-лист аудита legacy-кода: он закрывает пункты, которые чаще всего забывают при подсчёте.

Сколько времени занимает миграция?

Срок зависит от объёма и от того, можно ли вести работы параллельно. Ориентиры для поэтапного переноса силами небольшой команды из двух-четырёх человек:

• Утилита или небольшое приложение (до десятка форм, без сторонних компонентов) — от нескольких недель до двух месяцев.
• Ведомственная или отделовая система (десятки форм и отчётов, несколько интеграций) — от трёх до шести месяцев.
• Учётная или производственная система (сотни форм, десятки OCX и отчётов, критичные интеграции) — от шести месяцев до полутора лет.

Отдельно планируйте параллельную эксплуатацию: несколько недель старая и новая версии работают на одних данных, расхождения разбираются по одному. Этот этап нельзя сжать добавлением людей, поэтому его лучше сразу поставить в календарь. Ускорить проект можно на этапе переноса кода — разбив систему на независимые модули и распределив их между разработчиками, — но не на этапе сверки.

Фиксированная цена или оплата по времени?

Модель оплаты влияет на итоговую стоимость не меньше, чем сама оценка. У каждой свои условия применимости.

• Фиксированная цена. Подходит, когда объём понятен после инвентаризации и пилота, а критерии приёмки записаны. Подрядчик закладывает в цену риски, зато заказчик получает предсказуемый бюджет. Без инвентаризации фиксированная цена на legacy-систему — лотерея для обеих сторон.
• Время и материалы. Подходит для систем, где неопределённость велика, а требования меняются по ходу. Платите за фактические часы, но нужен контроль: еженедельные отчёты, понятные этапы и право остановиться.
• Гибрид по этапам. Самая практичная схема для миграций: фиксированная цена на анализ и пилот, затем фиксированная цена на каждый следующий этап с уточнённой сметой. Риск каждой стороны ограничен одним этапом.

Как читать коммерческое предложение подрядчика

Разброс цен на одну и ту же систему в разы — нормальная ситуация, и чаще всего за ним стоит разный объём работ, а не разная жадность. Чтобы сравнивать предложения честно, проверьте в каждом:

1. Есть ли этап инвентаризации и пилота, и что будет, если пилот покажет расхождение с оценкой.
2. Какая целевая платформа и версия. Предложение на .NET 8 в конце 2026 года означает вторую миграцию через несколько месяцев; сверяйтесь с политикой поддержки .NET.
3. Что входит в тестирование: только «проверим вручную» или эталоны, автоматическое сравнение и параллельная работа.
4. Учтены ли перенос данных, отчёты и интеграции, или они вынесены «за рамки».
5. Как оформлены критерии приёмки каждого этапа и кто готовит эталонные данные.
6. Кому принадлежат исходный код, сконвертированный результат и инструменты, если подрядчик использует свою библиотеку совместимости.
7. Кто сопровождает систему после запуска и сколько длится гарантийный период.

Если два предложения после такой проверки отличаются по объёму, приведите их к одному перечню работ и попросите пересчитать. Только после этого цены можно сравнивать.

Как снизить стоимость и когда миграция окупается

Снизить бюджет без потери качества можно несколькими способами, и почти все они лежат на стороне заказчика:

• Не переносить мёртвое. Неиспользуемые формы, отчёты и функции выводятся из объёма до начала работ.
• Отказаться от пиксельной совместимости. Если интерфейс не обязан выглядеть как в 2005 году, сторонние гриды можно заменить стандартными компонентами.
• Подготовить эталоны своими силами. Пользователи лучше всех знают типовые сценарии и ожидаемые результаты.
• Начать с тестов на старой версии. Характеризационные тесты дешевле написать до миграции; как это делать, разобрано в статье о тестах для legacy VB.NET.
• Использовать конвертер там, где он силён. Бизнес-логику переводить инструментом, а переписывать только то, что всё равно должно измениться. Для проектов на .NET Framework первую оценку бесплатно даёт .NET Upgrade Assistant.

Окупаемость считается просто: сложите годовую стоимость владения старой системой — сопровождение, простои, ручные обходные процессы, лицензии на старые компоненты, риск отказа сборочной машины — и сравните с бюджетом миграции плюс стоимостью сопровождения новой версии. Если старая система обходится дороже уже сейчас, срок окупаемости считается в годах, а не в десятилетиях. Если нет, честнее продлить жизнь приложения по рекомендациям из статьи о сопровождении VB6 и вернуться к вопросу через год. Для VB6 помните, что среда выполнения поддерживается в Windows по официальной политике Microsoft, а среда разработки — нет, и именно это обычно и превращает «можно подождать» в «пора».

Как это делают сегодня

Вопросы и ответы