Нужен ли для Classic ASP и PHP один план миграции?

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

Если считать оба случая обычными устаревшими веб-приложениями, получится обычный план: описать страницы, выбрать фреймворк, преобразовать код, протестировать и переключить трафик. Такая последовательность скрывает риск, который определяет проект. Для Classic ASP сначала надо воспроизвести исчезающую среду выполнения и недокументированные зависимости, пока нынешний сервер ещё доступен. Для PHP сначала надо решить, какие архитектурные границы нужны. Построчная перепись способна сохранить все причины, по которым монолит трудно менять.

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

У Classic ASP есть срок жизни платформы

Миграция Classic ASP начинается с сервера, потому что приложение частично состоит из конфигурации IIS, к которой приложены исходные файлы. ASP-страницы зависят от движков сценариев Windows, регистрации COM, параметров метабазы IIS или applicationHost.config, совместимости с 32-битными компонентами, источников ODBC, прав на файлы, региональных настроек, а часто ещё от SMTP и заданий планировщика, которых никогда не было в системе контроля версий. Копия файлов .asp содержит лишь видимый слой.

Документация Microsoft по IIS описывает Classic ASP как необязательную функцию веб-сервера, которую должен отдельно установить администратор. Деталь кажется бытовой, но точно показывает риск: среда выполнения входит в роль операционной системы и хранит состояние машины, а не восстанавливается из манифеста проекта. Та же документация упоминает изменения безопасности, например отключённые родительские пути в новых конфигурациях IIS. Более безопасные настройки разумны, однако команда должна зафиксировать прежнее поведение до изменений. Иначе отличие платформы примут за дефект приложения.

Дедлайн редко задаёт одна дата окончания поддержки. Он наступает, когда организация уже не может уверенно собрать сервер заново. Можно ли настроить чистую машину по записанной инструкции? Сохранились ли установщики COM? Известно ли, какой учётной записи принадлежит каталог загрузок? Поддерживается ли драйвер базы на нужной версии Windows? Если ответы неубедительны, срок хостинга уже истёк, хотя текущая машина пока отвечает.

Поэтому обследование Classic ASP начинается с чистой сборки среды. Зафиксируйте параметры сайта и приложения IIS, установленные роли, сопоставления обработчиков, свойства пула приложений, идентификаторы классов COM, DSN, сертификаты, задания, службы Windows, используемые записи реестра и ACL всех каталогов с правом записи. Полезная единица инвентаризации здесь не страница, а исполняемая зависимость.

Проводите проверку под теми учётными записями, которыми действительно пользуется приложение. Администратор в интерактивном сеансе может читать реестр, создавать COM-объект и писать в общий каталог, недоступный учётной записи пула. Запишите разрядность процесса и каждого нативного компонента. 32-битная COM DLL может успешно зарегистрироваться на 64-битном сервере, но остаться невидимой рабочему процессу. В браузере это выглядит как ошибка приложения, а на сервере как ошибка хостинга. Поэтому на восстановленной среде нужен контролируемый набор запросов.

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

У монолита PHP высокая цена изменений

Монолиту PHP нужно архитектурное решение, когда бизнес-изменения затрагивают слишком много кода, а не просто когда версия PHP выглядит старой. Поддерживаемый PHP, актуальный веб-сервер и повторяемое развёртывание могут снять срочность со среды выполнения, но оставить систему, где оформление заказа подключает налоговые правила, отчёты сами создают соединения с базой, а общий include меняет аутентификацию каждого маршрута. Обновление интерпретатора относится к обслуживанию. Перестройка границ относится к модернизации.

Команды часто предлагают обновить фреймворк так, будто он создаёт архитектуру. Это неверно. Перенос глобального состояния в контейнер зависимостей может сделать синтаксис аккуратнее и сохранить прежнюю связанность. Замена одной библиотеки Active Record другой может оставить неясным владельца транзакции. Разделение контроллеров на сервисы создаёт каталоги, но не обязательно независимо проверяемое поведение. Совет популярен, потому что инструменты автоматизируют часть синтаксических правок, а diff выглядит убедительно. Он не решает проблему, если стоимость создаёт бизнес-логика без постоянного владельца.

Ищите пути изменений. Возьмите недавние задачи и проследите, что разработчики меняли ради правила цены, поля клиента, разрешения или отчёта. Найдите таблицы, в которые пишут несвязанные модули, значения сессии в роли скрытого API, include с побочными эффектами и задания, вызывающие веб-код через другую точку входа. Эти связи показывают, где новая граница снизит будущие затраты. Число файлов этого не покажет.

У PHP тоже бывает срок жизни среды, особенно при неподдерживаемом интерпретаторе или заброшенных расширениях. Но два случая от этого не становятся одним. Сначала устраните непосредственный риск самым небольшим обновлением, безопасность которого можно доказать. Затем выбирайте архитектуру по наблюдаемым путям изменений. Если смешать срочную совместимость с широким перепроектированием, искать причины ошибок станет труднее.

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

Эта карта предотвращает дорогую ошибку: извлечение кода, который выглядит старым, вместо функции, которую трудно менять. Стабильный некрасивый отчёт можно не переписывать. Более новый модуль без собственных данных, обращающийся к шести общим сервисам, может требовать внимания первым. Затраты на модернизацию оправдывает снижение цены будущей работы, а не современный вид каждого файла.

Два реестра отвечают на разные вопросы

Реестр Classic ASP отвечает на вопрос: «Что должно существовать, чтобы этот запрос выполнялся точно как сейчас?» Реестр PHP отвечает на другой: «Что должно меняться вместе и почему?» Оба изучают код, конфигурацию, данные, трафик и эксплуатацию, но придают свидетельствам разный вес.

Не объединяйте всё в таблице со столбцами имени файла, языка и сложности. Она создаёт ложную сопоставимость. Вызов закрытого COM-компонента из пяти строк ASP может определять весь график. Контроллер PHP на пять тысяч строк может быть многословным, но механически делимым. Ранжируйте зависимости Classic ASP по риску восстановления и замены, а области PHP по связанности, частоте изменений и бизнес-владельцу.

Команды путают ещё два понятия: поиск зависимостей и поиск архитектуры. Первый выясняет, что нужно системе для запуска. Второй выясняет, какие обязанности должны меняться независимо. Для Classic ASP сначала нужен первый, пока не сменился сервер. Основную пользу модернизации PHP даёт второй. Со временем обоим проектам нужны оба исследования, но порядок и глубина различаются.

Записанное поведение даёт общую основу

До переписи обеим системам нужна эталонная запись поведения, поскольку исходный код не содержит полной спецификации. Производственный трафик показывает сочетания параметров, состояния cookie, перенаправления, типы содержимого, кодировки, ошибки и временные допущения, пропущенные при просмотре кода. Снимки базы, созданные файлы, исходящие сообщения и результаты заданий дополняют эффекты, которых нет в HTTP-ответах.

Запишите представительные запросы, удалив или заменив секретные значения, затем воспроизведите их на старой и новой системе в контролируемой среде. Сравните статус, значимые заголовки, нормализованные тела, изменения базы, файлы и исходящие события. Не сравнивайте каждый изменчивый байт. Меткам времени, идентификаторам запросов, несущественному порядку и токенам CSRF нужны явные нормализаторы. У каждого должен быть владелец и причина, иначе слишком широкое правило скроет настоящую регрессию.

Полезный сценарий паритета хранит стимул и ожидаемые наблюдаемые эффекты:

{
  "case": "invoice-posted-with-credit",
  "request": {
    "method": "POST",
    "path": "/billing/post.asp",
    "form": {"invoice_id": "18421", "apply_credit": "1"}
  },
  "expect": {
    "status": 302,
    "location": "/billing/view.asp?id=18421",
    "database": ["invoice.status=posted", "credit.remaining=0"],
    "outbound": ["invoice-posted email"]
  }
}

Конкретный инструмент может отличаться, но в результате нужны имя сценария, различающееся наблюдение, старое и новое значение. Сообщения «тест не пройден» для миграции недостаточно. Инженер должен видеть, изменилось ли перенаправление, иначе округлилось число или письмо ушло дважды.

В Classic ASP записанное поведение защищает от различий в разборе дат, кодовых страницах, преобразовании Variant и возвратах COM. В PHP оно защищает команду при переносе логики через новые границы. Механизм общий, причина применения различна.

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

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

В Classic ASP сначала снижается риск сервера

Хороший план Classic ASP делает существующее поведение переносимым до улучшения устройства системы. Последовательность должна рано показать состояние машины и целенаправленно его устранить.

1. Соберите приложение на чистой поддерживаемой среде Windows и IIS по записанной конфигурации и сохранённым установщикам. Зафиксируйте каждое ручное действие, которого нет в репозитории.
2. Запишите и повторите представительное производственное поведение на текущем и восстановленном сервере. Устраните отличия совместимости до новой архитектуры.
3. Замените или изолируйте зависимости, которые не переживут перенос, начиная с COM, старых провайдеров данных и локального диска. Для каждой замены создайте сценарии паритета.
4. Переписывайте ограниченное поведение в целевой среде, пока старое приложение доступно как эталон. Направляйте контролируемый трафик по новому пути и сравнивайте эффекты.
5. Переключайтесь, только когда эксплуатация умеет развернуть, восстановить, наблюдать и откатить новую систему без доступа к исходной машине.

Может оказаться, что временная площадка IIS необходима. Это допустимо, если она явно описана, воспроизводится, обновляется и имеет условие закрытия. Перенос непрозрачной виртуальной машины в другой дата-центр не модернизирует приложение. Временный сервер покупает время для удаления машинных зависимостей и не должен по инерции становиться постоянным.

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

В PHP границы создаются и проверяются

Хороший план PHP начинает с целевой границы, связанной с реальным давлением изменений, и переносит через неё поведение. Монолит может оставаться на поддерживаемом сервере, пока команда доказывает по одной границе домена. Полная закрытая перепись лишает проект обратной связи, которая должна формировать устройство системы.

Выбирайте границы по бизнес-владельцу и транзакциям, а не по существительным в именах таблиц. «Клиент» встречается повсюду и редко образует хороший первый сервис. Расчёт цены, создание документа, проверка права или проведение расчёта часто имеют более ясные вход, выход и владельца. Сохраняйте вместе работу, требующую одной атомарной транзакции, пока не выбрана стратегия согласованности. Сетевой вызов не улучшает устройство только потому, что пересекает процесс.

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

Не требуйте микросервисов. Модульный монолит на Go или TypeScript может явно задать владельцев и направление зависимостей с гораздо меньшей эксплуатационной ценой. Rust подходит числовому ядру, где переполнение, точность и пропускная способность требуют строгого контроля, но для обычной обработки запросов он добавит языковую границу, не решив проблему домена. Целевая архитектура должна убрать измеренную связанность, а не демонстрировать любимые технологии.

Владение данными делает разделение настоящим

Граница не создана, если новый компонент и старое приложение могут по желанию менять одни таблицы. Общие чтения подходят как временный мост. Общие записи создают два набора инвариантов, две модели транзакций и ни одного надёжного владельца при расхождении. Риск есть в обеих системах, но особенно важен в PHP: извлечение подталкивает слишком рано делить базу.

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

Classic ASP часто скрывает поведение данных в хранимых процедурах, триггерах и умолчаниях ADO. Переписанная страница с тем же SQL может изменить тип параметра, обработку null, курсор или область транзакции. Проверяйте эффекты в базе, особенно деньги, даты и многострочные обновления. Совпавший HTML не доказывает совпавшую операцию.

Монолиты PHP скрывают ту же проблему за ORM. Обратные вызовы моделей, ленивая загрузка, глобальные области и неявные транзакции превращают простой вызов в несколько эффектов. До переноса метода запишите запросы и итоговое состояние, затем решите, какие эффекты входят в новую границу. Слепое воспроизведение всех вызовов сохраняет старую структуру. Слепое удаление теряет данные.

Планируйте переходное состояние, а не только финал. Если старый код должен читать данные нового компонента, используйте явное представление совместимости, API или реплицированную модель чтения с датой удаления. Если во время испытания обеим сторонам поступает одна команда, назначьте одну главной и сравнивайте предлагаемые эффекты другой без записи. Двойная запись проста на схеме, но частичный отказ превращает её в систему сверки. Большинству команд такая временная система не нужна.

Изменения схемы требуют той же дисциплины. Добавьте поля и читателей до смены писателей, поддерживайте старое и новое представление в переходный период и уберите совместимость после исчезновения старого трафика. Развёртывания базы и приложения могут проходить неатомарно. План, который предполагает обратное, столкнётся с откатом в неверном порядке.

Сессии, задания и файлы показывают скрытое приложение

Путь запроса и ответа обычно не равен всей системе. Classic ASP может хранить InProc-сессию в процессе IIS, писать документы в локальный каталог, принимать файлы для задания Windows или вызывать COM для почты. В монолите PHP бывают cron, запускающий веб-приложение, worker с другими переменными, общие сессии и файлы как механизм координации.

Для миграции сессий нужен явный выбор. Можно сохранить cookie и формат сессии, связать поиск между средами или попросить пользователей снова войти при плановом переключении. Выбор зависит от безопасности и неудобств. Допущение, что сессии перенесутся сами, выбором не считается. Проверяйте истечение, смену после аутентификации, параллельные запросы, выход и перезапуски.

Заданиям нужен свой корпус. Запишите входы, расписание, блокировки, эффекты в базе, файлы и поведение повторов. Задание, успешное при ручном запуске, может дважды создать счета при пересечении двух планировщиков. Потребитель очереди не возвращает HTTP-ответ, но может содержать самую опасную бизнес-логику.

Считайте пути файлов интерфейсами. Определите авторов и читателей, правила имён, срок хранения, кодировку, атомарность и результат неполной записи. Переход с локального каталога Windows или общего PHP-хоста на объектное хранилище меняет согласованность и права. Смоделируйте это, а не просто замените строку пути.

Критерии приёмки должны доказывать главный риск

Общая панель может показывать оба проекта, но критерии выпуска должны различаться. Для Classic ASP они доказывают независимость от старого сервера. Для PHP они доказывают снижение связанности без изменения поведения. Число преобразованных файлов и модульных тестов не доказывает ни то, ни другое.

Для Classic ASP требуйте чистую сборку из контролируемых артефактов, полный реестр с владельцем и решением по каждой внешней зависимости, результаты паритета интерактивных и пакетных процессов, подтверждение развёртывания, резервирования, восстановления, наблюдения и отката. Отдельный тест должен показать, что отключение старого сервера не удаляет нужный установщик, секрет, сертификат или источник истины. Готовность к выключению входит в приёмку.

Для PHP требуйте контракт каждой границы, одного автора каждого перенесённого факта, паритет ответов и эффектов, правила зависимостей в коде или сборке, тесты ошибок и повторов между процессами и примеры завершённых изменений, где извлечённая область больше не требует правок в несвязанных частях. Независимость должна проявиться в пути изменения.

Сравнению производительности нужен контекст. Повторяйте формы запросов и параллелизм производства, прогревайте кеши и сравнивайте работу базы вместе с задержкой. Новый endpoint может быстро ответить, отправив дорогую работу в отстающую очередь. Отчёт на пустой копии базы может быть быстрым и упасть на объёме закрытия месяца. Используйте реальную нагрузку и распределение данных.

Задайте допустимые отклонения механики миграции. Сколько различий паритета может оставаться, какая тяжесть блокирует трафик, насколько может отстать очередь и какая сверка должна дать ноль? Назначьте того, кто вправе отменить критерий, и способ записи решения. Без правил усталость от совещаний превращает необъяснённые различия в принятый риск. С правилами руководство отличит детали отображения от неизвестных финансовых эффектов.

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

Одна оценка не выражает две неопределённости

Оценка Classic ASP должна показывать неизвестные зависимости сервера, варианты замены и объём свидетельств поведения. Оценка PHP должна показывать решения о границах, общее владение данными и цену изменения вызывающего кода. Поставщик, оценивающий оба проекта по строкам и страницам, измеряет набор текста, а не риск.

Попросите команду Classic ASP показать чистую сборку и поиск вызовов вне репозитория. Спросите о каждом COM-объекте, DSN, задании, сертификате и каталоге. Спросите, как сравнивается поведение, если Variant или локаль изменит результат. Предложение, которое начинается с автоматического преобразования исходников и не отвечает на эти вопросы, начинается слишком высоко в стеке.

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

Структура договора должна следовать свидетельствам. Исследование должно дать реестр зависимостей, корпус поведения, карту границ, целевые решения и критерии приёмки. Этапы поставки должны соответствовать снятым рискам или работающему поведению, а не доле преобразованных файлов. Фиксированные даты не убирают неизвестность, поэтому раннее исследование и узкие решения становятся важнее.

В оценке надо отделять известную реализацию от вариантов. Замену конкретного COM-компонента можно оценить после наблюдения его входов и выходов. Выбор между монолитом, модулем и сервисом для функции PHP остаётся архитектурным вариантом с последствиями для развёртывания и данных. Общий процент резерва скрывает решение, способное изменить работу.

Требуйте проверяемых допущений. «Стандартное ASP-приложение» и «типичная база PHP» ничего не значат. «Ни один нативный компонент не пишет вне перечисленных каталогов» можно проверить. «Процесс расчёта владеет четырьмя таблицами, и другой код в них не пишет» тоже можно проверить. Оценка надёжнее, когда команда называет наблюдение, которое её изменит.

Правильный план следует причине переезда

После Classic ASP старый сервер Windows должен выключаться без потери поведения и скрытой эксплуатационной инструкции. После модернизации PHP команда должна менять бизнес-функцию, не прослеживая общее состояние через весь монолит. Это разные финишные условия.

CodeHero принимает исходники Classic ASP и PHP, читает всю кодовую базу и все её языки вместе, а переписанное поведение проверяет механизмом паритета по записанному производственному трафику. Проекты модернизируют архитектуру в Go, Rust, TypeScript и Postgres менее чем за 30 дней. Если среда требует, предоставленные CodeHero модели работают изолированно на оборудовании внутри периметра заказчика.

Даже при работе с другой командой требуйте, чтобы план назвал главный риск на первой странице. Для Classic ASP нужны доказательства, что сервер можно восстановить, а затем удалить. Для PHP нужно обоснование владельцев, транзакций и путей изменений, которые сократит новая архитектура. Одна шаблонная форма для двух случаев, скорее всего, не отвечает ни одному.