Legacy — это не система, которой много лет. Legacy — это система, изменение которой стало дорогим, рискованным или слишком сильно связанным с остальным бизнесом

Именно поэтому её никто не трогает.

Она годами выполняет критическую функцию.

Вокруг неё появляются:

Excel;

ручные выгрузки;

скрипты;

общие папки;

прямые SQL-запросы;

ручной двойной ввод.

Проблема уже не внутри системы.

Проблема в стоимости каждого нового взаимодействия с ней.

Возможные границы:

read-only database;

staging tables;

файловый обмен;

SFTP;

message adapter;

RPA;

экспорт/импорт;

собственный wrapper;

локальный agent;

CDC;

очередь рядом с системой.

AMPE выбирает не самый красивый, а самый безопасный и поддерживаемый способ.

В старой системе клиент называется «лицевой счёт».

Статус закодирован цифрой 7.

Дата хранится в нестандартном формате.

Новые системы не обязаны знать эти детали.

Adapter переводит старую модель в современный контракт.

Так будущая замена legacy становится проще.

Это защита новой доменной модели от старых терминов и правил.

Legacy может иметь собственные ограничения, возникшие исторически.

Если новые сервисы начнут использовать их напрямую, модернизация перестанет быть модернизацией.

AMPE изолирует семантику там, где это действительно нужно.

Старая система может иметь скрытые triggers, batch jobs и внутренние зависимости.

Запись «правильных» строк не гарантирует правильного бизнес-состояния.

Если write-interface отсутствует, AMPE отдельно оценивает staging, wrapper или controlled import вместо вмешательства в core tables.

Если система имеет только desktop/web UI и менять её нельзя, робот может автоматизировать человеческую операцию.

Но RPA зависит от интерфейса и обычно хрупче API.

Поэтому мы рассматриваем его как осознанную границу с monitoring и recovery, а не как невидимый вечный костыль.

Новая функция появляется рядом со старой.

Часть запросов идёт в новый компонент.

Legacy продолжает обслуживать остальное.

Постепенно граница сдвигается.

AMPE использует поэтапное вытеснение там, где big-bang replacement слишком рискован.

Таблицу legacy читают:

финансы;

аналитики;

скрипт склада;

ночной отчёт;

партнёрский экспорт.

Команда может даже не знать обо всех зависимостях.

Перед изменением AMPE ищет реальные consumers, чтобы не «успешно» модернизировать систему ценой пяти неожиданных сбоев.

История за 15 лет.

Уникальные нормативы.

Клиентские связи.

Техническая история активов.

Поэтому migration strategy рассматривает:

что переносить;

что архивировать;

что оставить read-only;

что доступно через historical service.

Переносить всю историю в новую систему дорого и иногда бессмысленно.

Старый контур можно оставить как архивный источник с контролируемым read-access.

AMPE отделяет operational migration от historical access.

Старая и новая системы работают одновременно.

Кто owner?

Куда писать?

Как синхронизировать изменения?

Когда переключаться?

Dual-write без ясной модели легко создаёт расхождения.

AMPE отдельно проектирует transition states и cutover.

Adapter может собирать:

технический статус;

processing time;

ошибки;

retries;

business IDs.

Так вокруг старой системы появляется современный operational layer, даже если её код не меняется.

Сначала фиксируется роль legacy.

Потом карта зависимостей.

Выбирается безопасная интеграционная граница.

Adapter изолирует старую модель.

Новые системы работают с современным контрактом.

Миграция или замена выполняется постепенно только там, где она оправдана.

Так интеграция становится частью модернизации без требования немедленного big bang.

Legacy можно подключать без опасного вмешательства.

Новые системы меньше наследуют старые ограничения.

Ручные мосты постепенно исчезают.

Модернизация становится поэтапной.

Исторические данные сохраняются осознанно.

Риск замены снижается.

И главное — компания получает возможность развиваться вокруг старой критической системы, не делая вид, что единственные варианты — «не трогать никогда» или «переписать всё сейчас».