Аутсорсинг поддержки legacy-приложения на VB6 и VB.NET: как передать сопровождение подрядчику
Учётная система на VB6 или VB.NET работает много лет, но человек, который её знал, ушёл, а новых разработчиков со знанием этого стека на рынке почти нет. Разбираем, как передать сопровождение внешней команде и не потерять контроль над системой.
Microsoft прямо пишет в политике поддержки Visual Basic 6, что среда выполнения работает в современных Windows, а сама IDE давно не поддерживается. Поэтому VB6-приложения продолжают считать деньги, печатать накладные и управлять складом, но сопровождать их становится всё сложнее: опытных разработчиков мало, документации обычно нет, а сборку умеет повторить один ноутбук.
Один из выходов — передать сопровождение внешней команде по модели аутсорсинга разработки: подрядчик берёт систему на поддержку, отвечает за реакцию на аварии, делает доработки и постепенно снижает риски. Как устроен такой формат у компаний, которые ведут заказную разработку и поддержку с выделенной командой, можно посмотреть, например, на yusmpgroup.ru. Ниже — как подготовиться к передаче, что требовать от подрядчика и как не попасть в новую зависимость.
Статья для тимлидов, ИТ-директоров и владельцев систем, которые решают, держать ли legacy-приложение на своих силах или отдать его на аутсорс.
Когда сопровождение legacy-приложения стоит отдать на аутсорс?
Внешняя поддержка нужна не всем. Если в компании есть разработчик, который знает систему и загружен ею хотя бы наполовину, передача почти всегда обходится дороже, чем кажется. Аутсорс выигрывает в других ситуациях, и они хорошо узнаются:
- единственный человек, который понимает код, увольняется, уходит на пенсию или уже ушёл, а замену с опытом VB6 на рынке найти не удаётся месяцами;
- задач по системе мало и они нерегулярные: десяток доработок в квартал и редкие аварии, под которые держать штатного специалиста невыгодно;
- система критична для бизнеса (учёт, расчёт зарплаты, производство), но никто не отвечает за неё формально: нет дежурства, нет времени реакции, нет плана восстановления;
- впереди обязательные изменения окружения: переход на Windows 11 или новый сервер, обновление СУБД, конец поддержки .NET Framework 4.6.2 и старых Windows Server, отказ от VBScript;
- компания думает о миграции на современный .NET или веб, и нужен кто-то, кто сначала стабилизирует систему и разберётся в ней, а потом даст оценку.
Если узнали два-три пункта, стоит хотя бы посчитать вариант с подрядчиком. Если ни одного, скорее всего, достаточно навести порядок в собственном сопровождении: начните с воспроизводимой сборки по нашему разбору сопровождения VB6-приложения в 2026 году.
Что входит в поддержку legacy VB-приложения
Слово «поддержка» каждая сторона понимает по-своему, поэтому первое, что нужно сделать, это разложить работу на категории. У legacy-систем на VB6 и VB.NET их обычно пять.
Аварийная поддержка. Программа не запускается, отчёт падает, обмен с банком или 1С перестал работать. Здесь важна скорость: найти причину, восстановить работу, при необходимости откатить последнее изменение.
Плановое сопровождение окружения. Обновления Windows и драйверов, перенос на новые рабочие места и серверы, регистрация COM-компонентов, проверка 32-битных драйверов ODBC и OLE DB, продление сертификатов подписи. У VB6-приложений именно окружение ломается чаще, чем код.
Мелкие доработки. Новое поле в форме, изменение формулы расчёта, новый отчёт или выгрузка, поправка под изменившийся формат обмена. Обычно это основная часть объёма.
Безопасность и соответствие. Закрытие SQL-инъекций и хранения паролей в открытом виде, переход на TLS 1.2 для обмена, замена устаревших протоколов. Ориентир для веб-частей на Web Forms и Classic ASP даёт OWASP Top 10.
Документирование и снижение рисков. Описание модулей, данных и интеграций, автоматическая сборка, тесты на ключевые расчёты, постепенный вынос рискованных зависимостей в .NET-компоненты. Эта категория не горит, но именно она делает систему передаваемой и дешевле в сопровождении через год.
Какую модель сотрудничества выбрать: абонемент, T&M или SLA?
Фиксированная цена за поддержку почти не работает: объём заранее неизвестен, и одна из сторон всегда проигрывает. На практике встречаются три модели, и у каждой свой профиль.
- Абонемент с пакетом часов. Вы покупаете, например, 20 или 40 часов в месяц, подрядчик держит за вами специалиста с нужным опытом. Подходит для стабильного потока мелких задач. Уточните, что происходит с неизрасходованными часами и сколько стоит час сверх пакета;
- Time & Material. Оплата фактически отработанных часов по согласованной ставке. Удобно, когда задачи редкие и разные, но без жёсткого контроля оценок бюджет плывёт. Требуйте оценку перед каждой задачей больше нескольких часов;
- SLA-пакет. Подрядчик отвечает за время реакции и восстановления по классам инцидентов, иногда с дежурством вне рабочего времени. Это самый дорогой вариант и единственный, где за простой системы кто-то реально отвечает деньгами.
Часто модели комбинируют: SLA на аварии плюс пакет часов на доработки. Для системы, которая считает деньги, такая связка обычно оптимальна: аварии не конкурируют за часы с плановыми задачами.
Как передать приложение подрядчику: 8 шагов
Самая дорогая ошибка при передаче legacy-системы — сразу перейти к SLA. Подрядчик, который ещё не собрал проект и не видел данных, не может честно отвечать за время восстановления. Передача делается этапами:
- Инвентаризация. Где лежат исходники (все версии, включая «папку на диске у Сергея»), какие EXE, DLL и OCX стоят на рабочих местах и серверах, какие базы, планировщики задач и общие папки задействованы.
- Доступы. Репозиторий, виртуальные машины, серверы, СУБД, учётные записи для интеграций. Отдельные учётки для подрядчика, а не общий пароль администратора, и сразу журнал, кому что выдано.
- Воспроизводимая сборка. Подрядчик собирает приложение с нуля на отдельной машине и получает бинарник, идентичный тому, что работает у пользователей. Пока этого нет, любая правка — риск.
- Тестовый контур. Копия базы с обезличенными данными и стенд, где можно воспроизвести ошибку, не трогая рабочую систему.
- Передача знаний. Несколько сессий с тем, кто сопровождал систему раньше: архитектура, известные проблемы, «магические» настройки, ручные операции, которые делаются раз в месяц или раз в год.
- Аудит кода и рисков. Компоненты без исходников, брошенные OCX, жёстко прописанные пути и пароли, места без обработки ошибок. Хороший ориентир — наш чек-лист аудита legacy-кодовой базы.
- Пилотный период. Месяц-два подрядчик закрывает реальные задачи, но без штрафов по SLA. Вы смотрите на качество оценок, скорость и коммуникацию.
- Переход на SLA. Только после пилота фиксируются классы инцидентов, время реакции и отчётность, а прежний исполнитель окончательно передаёт дела.
Первые четыре шага стоит оплатить как отдельный этап с понятным результатом: собранный проект, описание окружения, работающий стенд. Это одновременно и проверка подрядчика: если он не может собрать вашу систему, дальше будет только хуже.
Что зафиксировать в договоре и SLA
Договор на поддержку legacy-системы отличается от договора на разработку: результат здесь не «готовый продукт», а работающая система и предсказуемая реакция. Минимальный набор пунктов:
- классы инцидентов с понятными примерами, время реакции и восстановления для каждого класса и окно поддержки (рабочие часы или круглосуточно);
- порядок оценки и согласования доработок: кто ставит задачу, кто утверждает оценку, когда работа считается принятой;
- права на код и документацию: исключительные права на всё созданное переходят заказчику, репозиторий принадлежит заказчику;
- правила работы с данными: доступ к рабочей базе только по заявке, работа с копиями без персональных данных, соглашение о конфиденциальности;
- отчётность: ежемесячный отчёт по часам, инцидентам и выполненным задачам, список рисков и рекомендаций;
- порядок выхода: срок уведомления, передача документации, доступов и знаний новому исполнителю или внутренней команде.
Пример классов инцидентов для учётной системы на VB6 (цифры — ориентир для обсуждения, а не норма):
- P1, система не работает у всех: реакция до 1 часа, восстановление или обходное решение в течение рабочего дня;
- P2, не работает важная функция (расчёт, обмен, печать документов): реакция до 4 часов, решение до 2 рабочих дней;
- P3, ошибка с обходным путём: реакция до 1 рабочего дня, решение в плановом релизе;
- P4, доработки и консультации: оценка до 3 рабочих дней, срок по согласованию.
Как выбрать подрядчика для VB6 и VB.NET
Подрядчиков, которые пишут «поддерживаем любой legacy», много, а людей с реальным опытом VB6 и Web Forms мало. Отличить одних от других помогают конкретные вопросы на первой встрече:
- как вы собираете VB6-проекты: в IDE вручную или из командной строки на выделенной машине, и как храните бинарные файлы форм .frx и .ctx в Git;
- что будете делать, если OCX стороннего вендора не работает на новой Windows, а исходников нет;
- как регистрируете COM-компоненты на 64-битной системе и что такое Binary Compatibility;
- как проверите, что доработка не сломала расчёты, если тестов в проекте нет;
- покажите пример отчёта по поддержке и пример описания системы, которое вы делали для другого клиента (без конфиденциальных деталей).
Тревожные сигналы: подрядчик с первой встречи предлагает «всё переписать», не задаёт вопросов про окружение и интеграции, готов сразу работать по SLA без этапа погружения или называет фиксированную цену за «поддержку целиком». Отдельно уточните, сколько людей в команде знают ваш стек: если ответ «один специалист», вы просто переносите риск единственного носителя знаний из своей компании в чужую.
Из чего складывается стоимость поддержки
Цена сопровождения legacy-системы определяется не столько объёмом кода, сколько его состоянием и требованиями к реакции. Основные факторы:
- Редкость стека. Час специалиста по VB6 и Crystal Reports обычно дороже часа по современному .NET: людей меньше, и они уже работают.
- Состояние системы. Нет документации, сборка ручная, часть компонентов без исходников — значит, каждая задача начинается с раскопок, и часы растут.
- Окно поддержки. Дежурство ночью и в выходные кратно дороже рабочего времени.
- Количество интеграций. Каждый обмен с банком, 1С, сайтом или оборудованием — отдельная точка отказа, которую нужно знать и мониторить.
- Доля работ по снижению рисков. На старте она увеличивает счёт, но через несколько месяцев уменьшает аварийную часть.
Чтобы сравнивать предложения, просите у подрядчиков оценку на одном и том же наборе типовых задач из вашей истории: две аварии, три доработки, одно обновление окружения. Сравнивать ставки без привязки к задачам бессмысленно. Если параллельно обсуждается миграция, пригодится наш разбор оценки стоимости миграции legacy-приложения: часто выясняется, что год поддержки сопоставим по цене с поэтапным переносом самой рискованной части.
Как не попасть в зависимость от подрядчика
Передав систему наружу, легко получить ту же проблему, от которой уходили: знания снова в одной голове, только теперь в чужой компании. Против этого работают простые правила:
- весь код и вся документация лежат в вашем репозитории, подрядчик работает в нём, а не у себя;
- сборка и развёртывание описаны так, что их может повторить любой разработчик по инструкции, и это проверяется хотя бы раз в год;
- каждая доработка сопровождается коротким описанием в задаче или в журнале изменений, а не только коммитом;
- раз в квартал подрядчик обновляет карту системы: модули, данные, интеграции, известные риски;
- в договоре есть понятный порядок выхода с обязательной передачей дел.
Полезно и постепенно покрывать ключевые расчёты тестами. Даже сравнение выходных файлов на эталонных данных резко снижает риск любой правки и делает систему передаваемой. С чего начать в VB.NET, мы разбирали в статье про модульные тесты для legacy-кода.
Как это делают сегодня
Вопросы и ответы
Что дешевле: нанять разработчика VB6 в штат или отдать поддержку на аутсорс?
Если задач мало и они нерегулярные, аутсорс почти всегда выгоднее: вы платите за фактические часы или за пакет, а не за полную ставку редкого специалиста. Штатный разработчик оправдан, когда legacy-система активно развивается и загружает человека целиком.
Можно ли передать на поддержку приложение без документации и без автора кода?
Можно, но первый этап будет дольше: подрядчик восстанавливает сборку, описывает модули, интеграции и данные и только потом берёт систему на SLA. Закладывайте на это отдельный оплачиваемый этап, а не надейтесь, что документацию напишут «по ходу».
Какое время реакции реально требовать для VB6-системы?
Для критичной учётной системы разумно требовать реакцию на аварию в пределах часа в рабочее время и восстановление работы в пределах рабочего дня, для мелких доработок хватает нескольких рабочих дней. Круглосуточная поддержка стоит заметно дороже и нужна только там, где система работает ночью.
Кому принадлежат исходный код и доработки, сделанные подрядчиком?
Это нужно прямо прописать в договоре: исключительные права на код и документацию переходят заказчику, репозиторий принадлежит заказчику, подрядчик получает к нему доступ. Без такого пункта по умолчанию права на новый код остаются у автора.
Подрядчик на поддержке может потом переписать систему на .NET?
Да, и это частый сценарий: команда, которая год сопровождала систему, лучше всех знает её логику и риски. Но решение о миграции лучше принимать по результатам независимого аудита, чтобы подрядчик не оценивал собственный объём работ без проверки.