Модернізація legacy-систем: стратегії, вартість та безпечний план міграції

Модернізація legacy-систем - це оновлення софту, який все ще обслуговує бізнес, але став важким у зміні, дорогим у змісті або ризикованим. Це може бути додаток на PHP 5 без тестів, стара CRM із самописними плагінами, десктопна програма, що працює із загальною базою даних, або моноліт, в якому розбирається одна людина. Ціль — не нові технології заради технологій, а система, яку бізнес знову може безпечно змінювати.

Ми приймаємо на підтримку та модернізуємо робочі системи клієнтів – від білінгових платформ до мультимовної e-commerce. Нижче підхід, який ми використовуємо самі: маленькі оборотні кроки, кожен з яких окупається.

Ознаки того, що настав час модернізувати

Вік сам собою не причина. Десятирічна система, яка стабільна, безпечна та недорога у змінах, може залишатися як є. Інвестиції виправдовують такі сигнали:

• Кожна зміна — довга і страшна. Невелика фіча займає тижні, релізи викочують уночі, а після кожного деплою ламається щось незв'язане.
• Непідтримуване середовище чи фреймворк. PHP 7.x або старше, фреймворк без підтримки, стара версія бази даних або ОС без оновлення безпеки. Цей випадок детально розібраний у нашому гайді з переходу на PHP 8.
• Залежність від однієї людини. Тільки один розробник, часто зовнішній, знає, як працюють депло, cron-завдання та інтеграції.
• Інтеграції заблоковані. Не можна підключити новий платіжний сервіс, CRM або ІІ, тому що система не має нормального API.
• Витрати зростають. Хостинг на надлишкових серверах, дорогі ліцензії, ручна робота в обхід відсутніх функцій і інциденти, що повторюються.
• Діри в безпеці та комплаєнсі. Паролі у відкритому вигляді, застарілі бібліотеки з відомими вразливістю, немає журналу дій, дані зберігаються не там, де мають.

Якщо збігаються два пункти або більше, модернізація зазвичай дешевша, ніж продовжувати платити приховану ціну.

Модель 6R: стратегії модернізації

6R - простий спосіб вибрати стратегію. Головне - вибирати її для кожного компонента окремо, а не для всієї системи одразу.

• Retain (залишити). Компонент не чіпаємо, лише моніторимо. Підходить для стабільних частин, які рідко змінюються, наприклад, старого модуля звітів.
• Rehost (перенести як є). Переносимо програму на нову інфраструктуру без зміни коду, наприклад зі старого фізичного сервера в Docker на сучасному VPS або у хмарі. Швидко і недорого: видаляє ризик заліза, але не проблеми коду.
• Replatform (змінити платформу). Невеликі зміни, щоб працювати на найкращій платформі: підтримувана версія PHP, керована база даних, черга замість циклів у cron. Часто найкраще співвідношення ціни та результату.
• Refactor (рефакторинг). Покращуємо внутрішню структуру без зміни поведінки: додаємо тести, виділяємо послуги, видаляємо мертвий код, поступово вводимо шар фреймворку.
• Rearchitect (перепроектувати). Змінюємо архітектуру частини системи, наприклад, виносимо білінг в окремий сервіс з API або замінюємо загальну базу даних на події.
• Rebuild або replace (переписати чи замінити). Пишемо компонент заново або замінюємо його SaaS-продуктом. Виправдано, коли бізнес-логіка проста та зрозуміла чи готовий продукт її покриває. Ризиковано для складної недокументованої логіки.

Типовий план поєднує кілька стратегій: спочатку перенесення, щоб усунути інфраструктурні ризики, потім рефакторинг ядра, перепроектування однієї-двох болючих областей і заміна типових частин — відправлення пошти чи пошуку — перевіреними сервісами. Якщо вибираєте саме між переписуванням та поступовим покращенням, оцініть, скільки недокументованих бізнес-правил містить старий код: кожне забуте правило стане багом у новій системі.

Спочатку аудит та карта ризиків

Модернізація без аудиту – це ворожіння. За один-два тижні аудит повинен відповісти: що саме працює у продакшені, де лежать дані, що тендітне і що бізнес не може втратити. Докладний список питань – у нашому чек-листі аудиту коду. Мінімальний результат:

• Інвентаризація. Сервери, домени, репозиторії, cron-завдання, черги, зовнішні сервіси, доступи та власник кожного облікового запису.
• Карта архітектури. Основні модулі, бази даних, інтеграції та потоки даних, включаючи недокументовані, знайдені в коді та логах.
• Карта ризиків. Кожен ризик з ймовірністю, впливом на бізнес та способом виправлення: немає бекапів, немає тестів платіжної логіки, секрети в репозиторії, середовище, що не підтримується.
• Швидкі перемоги. Виправлення на кілька днів, які знімають найбільші ризики: перевірені бекапи, моніторинг, секрети поза кодом, деплой, що відтворюється.
• Дорожні карти. Порядок кроків модернізації з оцінками, залежностями та тим, що кожен крок дає бізнесу.

Якщо ви приймаєте систему від іншого розробника, поєднайте аудит з кроками з нашого гайду з передачі legacy-проекту на PHP: спочатку доступи та бекапи, потім зміни в коді.

Покроковий план міграції

Найбезпечніший спосіб модернізувати працюючу систему — патерн strangler fig (фікус-душитель): ставимо проксі перед старим додатком і переносимо маршрути, модулі або функції в новий код по одному. Користувачі бачать одну систему, а за нею стара частина поступово стискається, доки її не відключать.

# nginx: new code serves /billing and /api/v2, everything else stays on the legacy app
location /billing/ { proxy_pass http://new_app; }
location /api/v2/  { proxy_pass http://new_app; }
location /         { proxy_pass http://legacy_app; }

1. Стабілізація. Бекапи з перевіреним відновленням, моніторинг доступності та помилок, централізовані логи, секрети поза кодом. Поки що цього немає, нічого іншого не починаємо.
2. Відтворюваність. Пакуємо додаток в Docker або інше середовище, що повторюється, піднімаємо staging з знеособленими даними і деплою, який відкочується за хвилини.
3. Страхова сітка. Пишемо характеризаційні тести для критичних сценаріїв: вхід, оформлення замовлення, виставлення рахунків, звіти, яких залежать фінанси. Вони фіксують, що система робить сьогодні, включаючи баги.
4. Відновлення платформи. Підтримувані версії мови та фреймворку, актуальні бібліотеки, сучасна версія БД. Де можна – автоматичні інструменти, а все, що ловлять тести, виправляємо.
5. Перенесення болючих частин. Вибираємо модуль із найвищою вартістю змін або найбільшим ризиком, будуємо заміну, направляємо на неї частину трафіку, порівнюємо результати та перемикаємо повністю.
6. Акуратна міграція даних. Плануємо зміни схеми так, щоб старий і новий код працювали одночасно, мігруємо порціями, звіряємо кількості та суми і зберігаємо шлях відкату, доки старий код не видалено.
7. Видалення старого коду. Виводимо з експлуатації все, що не використовується. Модернізація, яка нічого не видаляє, просто додає другу систему підтримки.

Кожен крок повинен викочуватися окремо і давати видимий результат: менше інцидентів, швидше за релізи або нижче рахунок. Так проект залишається профінансованим і не перетворюється на класичні «два роки переписування без результату».

Вартість, терміни та окупність

Цифри залежать від розміру, якості коду та кількості невідомих, але ці діапазони для невеликої досвідченої європейської команди корисні як орієнтир:

• Архітектурний аналіз або аудит: €200–3k, 1-2 тижні. Письмовий звіт з ризиками, пріоритетами та дорожньою картою.
• Стабілізація: €3k–15k, 2-6 тижнів. Бекапи, моніторинг, Docker, відтворюваний деплой, секрети, термінові виправлення безпеки.
• Оновлення платформи: €5k–40k, 1-3 місяці. Наприклад, перехід з PHP 5 або 7 на PHP 8 з оновленням фреймворку та тестами критичних сценаріїв.
• Поетапна модернізація: €15k–150k, 3-12 місяців. Перепроектування ключових модулів, нові API, міграція даних та виведення старих частин з експлуатації.
• Повне переписування: часто в 1,5–3 рази дорожче за першу оцінку. Приховані бізнес-правила, міграцію даних та паралельну підтримку старої системи зазвичай недооцінюють.

Для розрахунку окупності порівняйте поточну вартість legacy-системи з цільовим станом. Врахуйте годинник розробників, втрачені на повільні зміни, інциденти та їх вплив на бізнес, ручну роботу в обхід функцій, хостинг і ліцензії, а також виручку від функцій, які зараз неможливо зробити. Зазвичай модернізація окупається за рахунок трьох ефектів: зміни робляться в рази швидше, інцидентів менше, інфраструктура дешевша. Про бюджетування загалом у нашому гайді про вартість розробки ПЗ на замовлення.

Типові помилки

• Переписування "великим вибухом". Стару систему заморожують на рік, доки будують нову. Бізнес продовжує змінюватись, і нова система застаріває вже до запуску.
• Зміни без тестів. Без характеризаційних тестів ніхто не знає, чи рефакторинг змінив поведінку.
• Ігнорування даних. Код можна переписати за тижні, а роки неузгоджених даних чистити та мігрувати набагато довше.
• Рішення від технології. Мікросервіси або новий фреймворк вибирають, тому що це модно, а не тому, що це вирішує виміряну проблему.
• Не має відповідального з боку бізнесу. Хтось повинен розставляти пріоритети та підтверджувати, що перенесені функції працюють як слід.

Чим ми можемо допомогти

Ми модернізуємо робочі PHP- та веб-системи за кроками: аудит, Docker та безпечний деплой, оновлення PHP та фреймворків, нові API та інтеграції – без зупинки бізнесу. Хороший перший крок — архітектурний аналіз ( €200): письмовий аналіз вашої системи з ризиками, пріоритетами та оцінкою кожного кроку модернізації. Якщо хочете спочатку обговорити ситуацію, запишіться на консультацію ( €50/год). Дивіться також нашу послугу з інтеграцій та кейс білінгу PebbleHost.