Модернізація — це не один проєкт. Це рішення.
Будь-яка розмова про legacy-систему рано чи пізно зводиться до фрази «нам потрібно це модернізувати». За цією фразою ховаються чотири-п'ять зовсім різних проєктів із кардинально різною вартістю, термінами та сценаріями провалу. Вибір неправильного підходу — одна з найдорожчих помилок, яку може допустити технічна організація, і трапляється вона постійно, бо команди хапаються за рішення ще до того, як чітко назвали саму проблему.
Цифри пояснюють, чому це важливо. Дослідження 2022 року від Consortium for IT Software Quality (CISQ) оцінило вартість неякісного програмного забезпечення в США у 2,41 трильйона доларів на рік, з яких 1,52 трильйона доларів припадає безпосередньо на накопичений технічний борг. Окремі галузеві опитування 2025 року показують, що близько 40% ІТ-бюджетів витрачається на обслуговування технічного боргу, а не на створення чогось нового, а за оцінками McKinsey технічний борг становить від 20 до 40 відсотків загальної вартості технологічного портфеля компанії ще до того, як витрачено хоч долар на його погашення. Дослідження Developer Coefficient від Stripe — досі найцитованіше джерело даних із цієї теми — показало, що розробники витрачають близько 41 відсотка свого часу на підтримку та роботу з поганим кодом, і спрогнозувало, що неефективність розробки програмного забезпечення коштуватиме світовій економіці приблизно 3 трильйони доларів втраченого ВВП за десятиліття.
Жодну з цих проблем не вирішує саме слово «модернізація». Її вирішує вибір правильного підходу для тієї системи, яка у вас насправді є.
Фреймворк: шість способів працювати з legacy-системою
Стандартна термінологія тут почалася з «5 R» від Gartner і була розширена компанією AWS до того, що сьогодні зазвичай викладають як шість або сім «R». Три з них стосуються того, чи варто взагалі торкатися системи:
- Retire (вивести з експлуатації) — списати систему. Якщо від неї ніхто не залежить, її ліквідація — найвигідніший з погляду ROI крок модернізації, і саме цей крок команди пропускають найчастіше, бо ніхто не бере на себе відповідальність за таке рішення.
- Retain (залишити як є) — свідомо залишити систему без змін і повернутися до питання пізніше. Не кожну систему потрібно чіпати цього року.
- Repurchase (придбати заміну) — замінити власний код на SaaS- або COTS-продукт (готове комерційне рішення). Поширений варіант для комодитизованих функцій на кшталт розрахунку зарплат, HR чи CRM, де підтримка індивідуальної розробки вже втратила сенс.
Інші чотири варіанти — це шляхи, що вимагають серйозної інженерної роботи, і саме про них ця стаття: Rehost, Replatform, Refactor та Rebuild (іноді Refactor додатково поділяють на Refactor і Re-architect). Це варіанти, до яких звертаються, коли система в тій чи іншій формі залишається, і питання лише в тому, яку її частину доведеться переписати.
| Підхід | Що це означає | Типова вартість | Типові терміни | Найкраще підходить для |
|---|---|---|---|---|
| Rehost | «Підняти й перенести» (lift and shift) — перенесення застосунку на нову інфраструктуру без змін у коді | 25–150 тис. $ | Від кількох тижнів до 6 місяців | Стабільних систем, де проблема — вартість хостингу чи вихід із дата-центру, а не сам код |
| Replatform | «Підняти, доопрацювати й перенести» — перехід на нове середовище виконання чи керовані сервіси з незначними змінами в коді | 75–270 тис. $ | 3–12 місяців | Систем, яким потрібне реальне оновлення інфраструктури, але не зміна архітектури |
| Refactor | Поступова перебудова коду та архітектури зі збереженням поведінки системи | 180 тис. $ – 9 млн $+ | 6–36 місяців | Ключових систем, які активно гальмують постачання нових функцій, коли повне переписування занадто ризиковане |
| Rebuild | Повне переписування з нуля на сучасній, часто хмарно-нативній архітектурі | Від 500 тис. $ | 12–18+ місяців | Систем, надто малих, щоб виправдати поступову роботу, або надто зламаних, щоб їх рятувати |
Rehost: найдешевший варіант, який вирішує найменше
Rehost переносить застосунок на нову інфраструктуру — зазвичай у хмару — не торкаючись жодного рядка коду. Це найшвидший шлях до нижчого рахунку за хостинг: галузеві оцінки показують економію на інфраструктурі в діапазоні 20–40 відсотків після завершення переносу. Для нескладної системи це проєкт невеликого масштабу — приблизно 25–150 тис. доларів і від кількох тижнів до півроку, залежно від того, наскільки заплутаною вже є історія розгортання.
Проблема очевидна, щойно її сформулювати: ваш COBOL-застосунок або незадокументований моноліт тепер працює на сучасній інфраструктурі — і залишається тим самим COBOL-застосунком або незадокументованим монолітом. Rehost вирішує проблему хостингу. Він нічого не робить із проблемою коду. Команди, які очікують, що rehost виправить швидкість постачання чи надійність, зазвичай розчаровуються протягом року.
Replatform: середина, яку легко недооцінити за обсягом
Replatform іде далі, ніж просте «підняти й перенести» — заміна самостійно керованої бази даних на керовану, оновлення середовища виконання, контейнеризація сервісу — але без повного архітектурного перепроєктування. Він перебуває в діапазоні 75–270 тис. доларів і зазвичай триває 3–12 місяців, і для багатьох систем це справді правильний вибір: ви отримуєте реальне операційне покращення, не платячи за перепроєктування, яке насправді не потрібне.
Ризик replatform-проєкту — у розповзанні обсягу в протилежний бік. Виникає спокуса додати «ще одну» архітектурну зміну, коли ви вже й так у коді, і саме так replatform-проєкт непомітно перетворюється на недофінансований refactor із бюджетом replatform.
Refactor: варіант із найбільшим ефектом і найширшим діапазоном вартості
Refactor перебудовує код і внутрішню архітектуру, зберігаючи зовнішню поведінку системи незмінною. Саме тут відбувається більшість поступової модернізації, включно з патерном strangler fig — коли стара й нова системи працюють паралельно, а трафік мігрує частинами, а не в результаті одного одноразового перемикання. Ми детально розібрали цю конкретну техніку в статті Модернізація legacy-систем без переписування з нуля; ця ж стаття про те, чи взагалі варто обирати refactor, а не про те, як його реалізувати.
Вартість тут охоплює величезний діапазон, бо «refactor» описує все — від сервісу середнього розміру (180–270 тис. доларів, 6–12 місяців) до ключової фінансової платформи чи платформи для роботи зі страховими виплатами. Для систем такого масштабу традиційна робота з рефакторингу та ре-архітектури історично коштувала 4–9 млн доларів і тривала 18–36 місяців. AI-асистована розробка стискає ці показники: бенчмарки 2025 року оцінюють подібні проєкти приблизно у 7,2 млн доларів за 8–14 місяців — приблизно на п'яту частину дешевше і майже вдвічі швидше за традиційний шлях. Це реальний зсув, але не той 10-кратний ефект, який рекламують деякі постачальники.
Rebuild: повний контроль, повний ризик
Rebuild означає почати з нуля — справжнє переписування на сучасній архітектурі, зазвичай хмарно-нативній із самого початку. Він виправданий, коли вартість подальшого «латання» наявної системи перевищує вартість її заміни, або коли система достатньо мала, щоб можна було адекватно оцінити весь обсяг робіт заздалегідь. За оцінками, rebuild для систем корпоративного масштабу коштує від 500 тис. доларів і триває традиційно 12–18 місяців (AI-асистована розробка може наблизити ці показники до 250 тис. доларів і 6–12 місяців за порівнянного обсягу).
Rebuild також є найризикованішим із чотирьох підходів — і зі значним відривом. Ви замінюєте систему, на якій працює ваш бізнес, на щось ще не перевірене, зазвичай в один день одноразового перемикання, тоді як команда, яка розуміє всі особливості старої системи, зайнята побудовою її заміни, а не підтримкою оригіналу. Закладіть у бюджет період паралельної роботи обох систем і не дозволяйте нікому переконувати вас, що стару систему можна вимкнути того самого дня, коли запуститься нова.
За однією з найбільш цитованих галузевих оцінок, типова ініціатива з модернізації коштує 1,5 млн доларів і триває 16 місяців — і при цьому аж 79% таких ініціатив не досягають повністю поставлених цілей. Окреме дослідження корпоративних програмних проєктів загалом оцінює частку провалів у 58%. В обох випадках головна причина — не погана інженерія. Це вибір неправильного підходу для конкретної системи: rebuild там, де вистачило б refactor, або replatform там, де насправді потрібен був rebuild. Фреймворк вище існує саме для того, щоб запобігти цій помилці ще до того, як витрачено перший долар.
Що насправді визначає ціну всередині кожного діапазону
У межах будь-якого з цих чотирьох підходів той самий набір факторів визначає, потрапите ви в нижню чи верхню межу діапазону:
- Складність міграції даних — обсяг, якість і кількість вихідних систем. Неякісні або дубльовані дані додають вартості незалежно від обраного підходу.
- Навантаження, пов'язане з комплаєнсом і регуляторними вимогами — системи в охороні здоров'я та фінансах мають вимоги щодо валідації й аудиту, які додають реального часу. Не випадково значна частка лікарень досі працює на системах, термін підтримки яких вже завершився: вартість роботи з ними об'єктивно вища.
- Площа інтеграції — кожен вищерозташований API, пакетне завдання чи нижчерозташований споживач даних — це щось, що не може «зламатися» під час переходу, і кожен такий елемент додає вартості на тестування та координацію.
- Вартість паралельної роботи — якщо стара й нова система працюють паралельно під час міграції, закладайте в бюджет подвійні витрати на інфраструктуру та підтримку на весь період накладання, а не лише вартість самої розробки.
- Доступність команди — виконують роботу ті самі інженери, які одночасно підтримують legacy-систему, чи виділена команда, залучена спеціально під міграцію, — це впливає і на терміни, і на ризик помилок, спричинених вигоранням.
Як насправді ухвалити рішення
Груба, але надійна евристика: якщо система стабільна і єдина реальна проблема — де вона розміщена, обирайте rehost або replatform. Якщо вона критично важлива для бізнесу, активно гальмує постачання нових функцій і її можна розбити на частини, робіть refactor поступово, а не ставте все на одне одноразове перемикання. Якщо функція комодитизована і купити вигідніше, ніж будувати, обирайте repurchase. Якщо система достатньо мала, щоб повністю оцінити обсяг робіт, або надто зламана, щоб її рятувати, — обирайте rebuild. А якщо все працює і ніхто не скаржиться, залиште систему як є (retain) і поверніться до цього питання через дванадцять місяців — це законне рішення, а не бездіяльність.
Коли ми оцінюємо проєкт із модернізації legacy-систем, саме це — перша розмова, яку ми ведемо ще до будь-якого обговорення коду: що ця система має робити протягом наступних трьох років, і який із цих чотирьох шляхів приведе туди з найменшим ризиком. Найдешевший на папері варіант рідко залишається найдешевшим, коли ви враховуєте, що станеться, якщо він не спрацює.
Не впевнені, який підхід підходить вашій системі?
У нашій практиці були rehost-проєкти, що займали три тижні, і refactor-проєкти, що тривали вісімнадцять місяців, — для компаній однакового розміру. Надішліть нам опис вашої системи, і ми чесно скажемо, який шлях підходить, скільки це коштуватиме і що б ми зробили інакше.
Поширені запитання
Як зрозуміти, чи потрібен мені rehost, чи повний rebuild?
Почніть із того, що саме зламано. Якщо проблема — у вартості хостингу чи потребі піти з дата-центру, а сам код працює нормально, обирайте rehost. Якщо проблема саме в коді, але систему можна декомпозувати й мігрувати частинами, обирайте refactor. Rebuild підходить для систем, які або достатньо малі, щоб повністю переоцінити обсяг робіт, або надто фундаментально зламані, щоб їх розширювати. Більшість систем потрапляють у проміжну зону replatform або refactor, а не в один із крайніх варіантів.
Чи завжди refactor дешевший за rebuild?
Не завжди, але, як правило, він менш ризикований. Проєкти з рефакторингу та ре-архітектури для великих систем можуть коштувати 4–9 млн доларів, що на певному масштабі наближається до вартості rebuild. Головна відмінність — у швидкості окупності: поступові підходи зазвичай окупаються за 12–14 місяців, тоді як масштабний rebuild «в один прийом» — за 18–36 місяців, бо ви починаєте отримувати цінність від уже мігрованих частин, не чекаючи фінального одноразового перемикання.
Скільки насправді триває типовий проєкт модернізації?
За даними бенчмаркінгу 2025 року для проєктів різного масштабу, невеликі проєкти тривають 3–6 місяців, проєкти середнього розміру — 6–12 місяців, а робота корпоративного масштабу — 12–18 місяців і більше при традиційній розробці. AI-асистована розробка скорочує ці терміни приблизно на 40–50 відсотків за порівнянного обсягу, хоча цей ефект проявляється переважно в роботі, насиченій кодом, — refactor і rebuild, а не в проєктах rehost, де основне навантаження — саме міграція.
Яка найбільша причина провалу проєктів модернізації?
Вибір неправильного підходу для конкретної системи, а не погана інженерія. За галузевими оцінками, частка провалів корпоративних програмних проєктів сягає 58%, а за одним з найбільш цитованих досліджень 79% ініціатив з модернізації не досягають поставлених цілей. Спільна причина — невідповідність обсягу робіт реальній потребі: команди роблять rebuild там, де вистачило б refactor, або replatform там, де насправді був потрібен rebuild, і виявляють цю невідповідність через півроку та значну частину витраченого бюджету.