Сайт на Classic ASP в 2026 году: поддержка, риски и переход на современный стек

Сайты на Classic ASP редко выглядят как проблема: они годами отдают страницы, принимают заявки и никого не беспокоят. Проблема всплывает в момент, когда что-то меняется вокруг — хостинг переезжает на новую версию Windows Server, сканер безопасности находит инъекцию в форме поиска, отдел маркетинга просит адаптивную вёрстку, а в команде не остаётся никого, кто готов открыть файл с <% ... %> и On Error Resume Next на каждой второй строке.

Решения здесь два, и они не исключают друг друга. Если сайт держит сложную бизнес-логику — расчёты, интеграции, кабинет с ролями, — его переносят на ASP.NET Core по частям. Если же это по сути витрина с каталогом, новостями и формами, дешевле не тащить старый код, а заказать создание нового сайта на современном стеке и аккуратно перенести контент и адреса страниц. Ниже — как понять, какой из путей ваш.

Перед любым из вариантов стоит пройти чек-лист аудита legacy-кода: большая часть пунктов применима и к VBScript. А если рядом с ASP-сайтом живёт приложение на Web Forms, сверьтесь с разбором окончания поддержки Windows Server 2016 и IIS 10 — сроки там касаются обоих.

Поддерживается ли Classic ASP в 2026 году?

Формально — да. Classic ASP (модуль asp.dll) остаётся компонентом роли веб-сервера IIS и устанавливается отдельно: начиная с IIS 7 он не включён по умолчанию, это прямо описано в документации IIS на Microsoft Learn. Он доступен в IIS 10 на Windows Server 2019, 2022 и 2025 и получает исправления безопасности в рамках жизненного цикла самой ОС. Нового в технологии не появляется с начала 2000-х.

Неформально ситуация хуже. Весь серверный код Classic ASP почти всегда написан на VBScript, а VBScript в списке устаревших возможностей Windows: Microsoft сообщила, что сначала он станет компонентом по запросу (Feature on Demand), затем будет выключен по умолчанию и в конце концов удалён из системы. Первый этап уже прошёл в Windows 11 24H2, второй ориентировочно намечен на 2027 год.

Итог для планирования: сайт на Classic ASP можно безопасно эксплуатировать на поддерживаемом Windows Server ещё несколько лет, но горизонт ограничен, а людей, готовых его сопровождать, становится меньше каждый год.

Где главные риски старого ASP-сайта?

По опыту разборов, проблемы ASP-сайтов повторяются от проекта к проекту. Проверьте свой по этому списку до того, как обсуждать сроки миграции.

• SQL-инъекции. Запросы собираются склейкой строк: "SELECT * FROM news WHERE id=" & Request("id"). Это самый частый и самый опасный дефект; механику атаки и защиту подробно описывает OWASP.
• XSS. Данные из запроса и базы выводятся через Response.Write без Server.HTMLEncode.
• База Access в папке сайта. Файл .mdb лежит в каталоге вроде /db/ и при неудачных настройках скачивается целиком. Провайдер Microsoft.Jet.OLEDB.4.0 к тому же существует только в 32-битном варианте.
• Секреты в коде. Строки подключения с паролем в global.asa или include-файлах, общие для всех страниц и никогда не менявшиеся.
• Подавленные ошибки. On Error Resume Next в начале страницы: сбой записи заказа не виден никому, кроме клиента, который заказа так и не получил.
• COM-компоненты без исходников. Самописные DLL для загрузки файлов, отправки почты или генерации картинок, зарегистрированные на сервере пятнадцать лет назад. Это главный блокер переезда на новую ОС.
• Устаревшая почта и шифрование. Отправка писем через CDO без TLS, хранение паролей пользователей в открытом виде или как MD5 без соли.

Часть рисков закрывается без переписывания: параметризованные запросы через ADODB.Command, кодирование вывода, перенос базы из Access в SQL Server и вынос строки подключения из кода. Это стоит сделать в любом случае — даже если миграция начнётся через месяц, сайт всё это время остаётся в интернете.

<%
' Было: id подставляется в SQL как есть
' sql = "SELECT title, body FROM news WHERE id=" & Request("id")

' Стало: параметризованный запрос через ADODB.Command
Dim cmd, rs
Set cmd = Server.CreateObject("ADODB.Command")
cmd.ActiveConnection = Application("ConnString")
cmd.CommandText = "SELECT title, body FROM news WHERE id = ?"
cmd.Parameters.Append cmd.CreateParameter("id", 3, 1, , CLng(0 & Request.QueryString("id")))
Set rs = cmd.Execute

If Not rs.EOF Then
  Response.Write "<h1>" & Server.HTMLEncode(rs("title")) & "</h1>"
End If
%>

Сопровождать, переносить или делать заново?

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

1. Оставить и укрепить. Подходит, если сайт внутренний, меняется раз в год и доживает до замены более крупной системой. Минимум работ: актуальный Windows Server, закрытые инъекции, HTTPS, резервные копии, мониторинг ошибок. Горизонт — два-три года.
2. Перенести логику на ASP.NET Core. Подходит для кабинетов, B2B-порталов и внутренних систем, где в коде зашиты расчёты, статусы и интеграции. Логику переписывают на C# или VB.NET-библиотеки, интерфейс — на Razor Pages, MVC или Blazor. Это тот же подход, что и в плане миграции Web Forms на ASP.NET Core, только без возможности переиспользовать код.
3. Сделать новый сайт. Подходит для корпоративных сайтов, каталогов и лендингов, где ценность в контенте, а не в коде. Старый код не переносят вовсе: проектируют структуру заново, переносят тексты и картинки, а старые адреса .asp переадресуют на новые.
4. Гибрид. Часто лучший вариант: публичную часть делают новым сайтом, а кабинет или калькулятор переносят на ASP.NET Core и подключают к нему по API.

Ориентиры по трудоёмкости разобраны в статье о том, сколько стоит миграция legacy-приложения: для ASP-сайта оценка строится так же — от числа страниц с логикой, интеграций и COM-компонентов, а не от общего числа файлов.

Можно ли автоматически конвертировать ASP в ASP.NET?

Нет. Инструментов, которые превращают страницы на VBScript в работающий проект ASP.NET Core, не существует, а коммерческие конвертеры в лучшем случае дают черновик, который всё равно переписывают. Причины понятны: в ASP разметка, SQL и бизнес-правила перемешаны в одном файле, глобальное состояние живёт в объектах Session и Application, а поведение часто зависит от подавленных ошибок.

ИИ-ассистенты заметно ускоряют работу: хорошо объясняют, что делает конкретная страница, и пишут черновик контроллера или Razor-страницы. Но они не знают, почему в коде стоит странная проверка на дату, и не видят, какие COM-объекты вызываются в рантайме. Поэтому порядок такой: сначала человек разбирает страницу и фиксирует её поведение тестами на реальных данных, потом код пишется на новой платформе, потом результаты сравниваются со старым сайтом.

Полезный приём — снять «эталон»: для каждой страницы с логикой сохранить набор запросов и ответов старого сайта (параметры, итоговый HTML или значения в базе). Новая реализация считается готовой, когда выдаёт то же самое на тех же входных данных.

Как перенести сайт по частям без остановки?

Для сайтов с логикой лучше всего работает постепенная замена — паттерн «душитель» (strangler fig). Перед старым сайтом ставится обратный прокси, и маршруты по одному переключаются на новое приложение.

1. Инвентаризация. Соберите список всех .asp-страниц, include-файлов, COM-объектов (Server.CreateObject), таблиц и внешних интеграций. Отметьте, какие страницы реально посещаются: по логам IIS обычно оказывается, что треть файлов мертва.
2. База отдельно от кода. Перенесите данные из Access в SQL Server или PostgreSQL, если это ещё не сделано, и выделите учётную запись с минимальными правами. С этой базой будут работать оба сайта.
3. Прокси. Поставьте перед сайтом IIS с URL Rewrite и ARR или YARP — обратный прокси на ASP.NET Core. На старте все запросы уходят на старый сайт.
4. Общая авторизация. Сессия Classic ASP хранится в памяти процесса и недоступна ASP.NET Core. Самый простой мост — подписанный cookie или токен, который выдаёт старый вход и понимает новый, либо сразу перенос входа на новую платформу первым шагом.
5. Раздел за разделом. Переносите страницы группами: сначала простые и посещаемые (новости, каталог), затем формы, затем кабинет. Каждую группу переключайте в прокси и сверяйте с эталоном.
6. Выключение. Когда на старый сайт не уходит ни одного запроса две-три недели, его отключают, а VBScript и asp.dll удаляют с сервера.

Как не потерять позиции в поиске при переезде?

У сайта, который живёт пятнадцать лет, накоплены ссылки и позиции на адреса вида /catalog.asp?cat=12 и /news_detail.asp?id=345. При переезде на новый сайт или новую платформу их легко потерять.

• Выгрузите все индексируемые адреса: из логов IIS, Search Console, Вебмастера и внешних ссылок, а не только из меню сайта.
• Составьте карту соответствия «старый адрес → новый адрес». Для страниц с параметрами правило строится по значению параметра: news_detail.asp?id=345 → /news/nazvanie-novosti.
• Настройте постоянные редиректы 301 на уровне прокси или веб-сервера, без цепочек. Страницы, которым нет замены, должны отдавать 410 или 404, а не главную.
• Сохраните заголовки, описания и тексты страниц, которые приносят трафик, — улучшать их лучше после переезда, когда данные стабилизируются.
• После переключения отправьте новую карту сайта и две-три недели следите за ошибками сканирования.

Если параллельно со сменой платформы вы правите и старые разделы на Web Forms, пригодится разбор укрепления сайта на ASP.NET Web Forms: он покрывает те же темы — инъекции, заголовки безопасности и TLS.

Что делать в ближайший месяц

Даже если решение о миграции ещё не принято, есть работы, которые окупаются при любом сценарии:

1. Положите весь код сайта в git, включая include-файлы и global.asa, и уберите из него пароли.
2. Найдите все места со склейкой SQL и замените их параметризованными запросами.
3. Перечислите все COM-объекты и проверьте, у каких из них есть исходники и 64-битные версии.
4. Перенесите сайт на поддерживаемый Windows Server и включите журналирование ошибок вместо On Error Resume Next.
5. По логам IIS определите живые страницы и примите решение по каждому разделу: оставить, перенести или сделать заново.

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

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