Модернізація legacy-систем: практики, що працюють, для європейських компаній

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

Далі про те, що насправді говорять поточні дані, яка стратегія модернізації кому підходить і як вибудувати послідовність так, щоб критична система не впала посеред роботи.

Головне

• Платні cloud-сервіси у 2025 році купували 52,7% підприємств ЄС, AI використовували 20,0%. Cloud став звичайною інфраструктурою, AI ще ні, і саме у відстані між цими двома числами зазвичай і проступають архітектурні обмеження.
• NIS2 увійшов у фазу примусу, але не того, на який очікують: у липні 2026 Комісія передала чотири держави до Суду ЄС за нетранспозицію директиви, майже через два роки після дедлайну.
• Дослідження DORA від Google Cloud за 2025 рік показало, що адопція AI підвищує пропускну спроможність доставки, але зберігає негативний зв'язок з її стабільністю, а команди, скуті щільно зв'язаними системами й повільними процесами, не отримують майже нічого.
• Оглядове дослідження уряду Великої Британії віднесло близько 28% технологічного естейту центрального уряду до legacy, причому окремі організації витрачають до 70 і навіть 85% технологічного бюджету на утримання, а не на модернізацію.
• Послідовність важливіша за обсяг. Спершу раціоналізувати, потім обгорнути ядро стабільними API, далі рефакторити вибірково, і врешті перевірити, що виведення з експлуатації справді відбулося.

Що таке модернізація legacy-систем і чому вона на порядку дня саме зараз

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

Legacy-система це не просто стара система. Вона стає бізнес-проблемою тоді, коли її важко змінити, коли вона погано задокументована, дорога в підтримці або тримається на компетенціях, яких на ринку майже немає. У європейському mid-market картина повторюється з упізнаваною точністю: критичні процеси живуть на монолітних розширеннях ERP, на застарілих застосунках .NET або Java, на версіях баз даних без підтримки, на batch-інтеграціях і на on-premise інфраструктурі, чия мапа залежностей існує лише в пам'яті людей, які, можливо, тут уже не працюють.

Макрокартину варто викласти точно, бо її зазвичай цитують приблизно. В обігу два різні cloud-індикатори, і вони не взаємозамінні.

Два cloud-числа різняться не тому, що одне з них хибне, а тому, що вони міряють різні речі за різні періоди. Хто цитує єдину цифру «cloud-адопції в ЄС», не уточнюючи, про який індикатор ідеться, цитує приблизно.

Ціль на 2030 рік потребує такої ж обережності, бо вона складена: щонайменше 75% підприємств, які використовують хоч щось одне з трьох, cloud, big data або AI. Звіт Комісії за 2026 рік не публікує єдиного зведеного відсотка за цією складеною ціллю, тому будь-хто, хто впевнено каже вам, що Європа встигає або не встигає саме за цим показником, оцінює на око. Що звіт справді каже: адопція AI у 2025 році зросла на 48% рік до року, і суттєві прогалини в опануванні складніших цифрових технологій нікуди не зникли, причому найважче малому й середньому бізнесу.

Для CTO або VP of Engineering модернізація розкладається на чотири види роботи.

• Discovery. Каталогізувати застосунки, залежності, потоки даних, користувачів та інфраструктуру.
• Assessment. Класифікувати системи за критичністю для бізнесу, технічним ризиком, експозицією до безпеки і частотою змін.
• Цільовий дизайн. Визначити майбутню архітектуру, модель релізів і послідовність міграції.
• Виконання. Міграція, рефакторинг, інтеграція, тестування, виведення з експлуатації та моніторинг.

Один із найкорисніших ранніх артефактів це heatmap, де бізнес-цінність відкладена проти технічного стану. Вона дає раді директорів одну сторінку, на якій сходяться ризик, витрати і вплив на клієнта, і вона ж дає аргумент узятися не за ту систему, яка скрипить найгучніше.

Що насправді змінилося з боку регуляторики

Зобов'язання вийшли з фази написання у фазу примусу, але форму цього примусу варто розуміти точно, бо її описують неправильно частіше, ніж правильно.

NIS2. Дедлайн транспозиції був 17 жовтня 2024 року. Восьмого липня 2026 Європейська Комісія передала Ірландію, Іспанію, Францію та Нідерланди до Суду ЄС за неповідомлення про заходи транспозиції. До цього були листи офіційного попередження в листопаді 2024 і мотивовані висновки дев'ятнадцяти державам у травні 2025. Зверніть увагу, що це таке: примус проти держав за нетранспозицію, а не примус проти компаній. Практичний наслідок у тому, що зобов'язання прив'язуються до національної імплементації, тому комплаєнс-календар компанії залежить від того, де вона працює, а в кількох великих ринках цей календар усе ще формується. NIS2 також кладе обов'язок нагору: за положеннями про governance керівні органи essential та important entities мусять затверджувати заходи управління ризиком кібербезпеки і контролювати їх впровадження, а члени цих органів проходити навчання.

Італія. NIS2 імплементовано декретом Decreto Legislativo 138/2024, чинним з 16 жовтня 2024. Операційна конкретика живе не в самому декреті, а у визначеннях ACN: реєстрація в національному порталі, обов'язки щодо повідомлення про інциденти і базові заходи безпеки вводяться кожен за своїм графіком, і ці графіки вже переглядалися не раз. Тому італійській компанії, що потрапляє в сферу дії, свої обов'язки треба читати з поточного визначення ACN, а не з декрету: дати рухалися.

DORA. Регламент (ЄС) 2022/2554 застосовується з 17 січня 2025. Вісімнадцятого листопада 2025 європейські наглядові органи визначили перших критичних постачальників ICT-послуг, і ті тепер під прямим наглядом. Для постачальника софту наслідок прямий: якщо ви тримаєте інфраструктуру або постачаєте софт фінансовій установі, DORA формує ваші контракти, ваше звітування про інциденти і ваше тестування стійкості, а не лише клієнтові.

GDPR. Стаття 83(5) обмежує адміністративні штрафи сумою до 20 млн євро або 4% світового річного обороту, залежно від того, що більше. CMS Enforcement Tracker, який є сторонньою агрегацією, а не офіційним реєстром, станом на серпень 2026 показує сукупно близько 6,3 млрд євро за понад 3 200 штрафами. Зв'язок із модернізацією тут вузький і конкретний: сховища персональних даних, аудиторські логи, шляхи доступу, межі шифрування і відносини з процесорами це архітектурні рішення, дешеві на етапі дизайну і дорогі, коли їх доводиться допасовувати вже потім.

Поруч із регуляторною картиною стоїть картина безпеки. ENISA Threat Landscape 2025, який покриває 4 875 інцидентів між липнем 2024 і червнем 2025, знову поставив DDoS і ransomware на чоло списку основних загроз. У розподілі зафіксованих випадків DDoS склав близько 76,7%, вторгнення 17,8%, а за окремим вимірюванням, початковим доступом, домінантним вектором залишився фішинг із 60%. Звіт IBM Cost of a Data Breach 2026, опублікований 29 липня 2026, дає середню глобальну вартість витоку 4,99 млн доларів, що IBM описує як історичний максимум і зростання на 12% проти попередньої редакції, і повідомляє, що кожен четвертий зловмисний витік був AI-enabled із середньою вартістю 6 млн доларів.

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

Чому AI-інвестиції недобирають на legacy-архітектурі

Бо AI підвищує темп змін, а зв'язаність перетворює зміни на нестабільність.

Звіт DORA за 2025 рік від Google Cloud, побудований на відповідях майже 5 000 технологічних фахівців, показав, що 90% використовують AI на роботі і понад 80% повідомляють про зростання продуктивності. І він же показав, що адопція AI «продовжує мати негативний зв'язок зі стабільністю доставки софту». Механізм у звіті названий прямо: без сильного автоматизованого тестування, зрілого контролю версій і швидких петель зворотного зв'язку зростання обсягу змін дає нестабільність, а «команди, що працюють у слабко зв'язаних архітектурах зі швидкими петлями зворотного зв'язку, отримують виграш, тоді як ті, що скуті щільно зв'язаними системами і повільними процесами, не отримують майже нічого». Звіт описує AI як підсилювач тієї системи, яка в команди вже є, а не як засіб її виправити.

Наступне дослідження тієї ж групи, про віддачу від AI-асистованої розробки, опубліковане у квітні 2026 року, моделює цей самий ефект у грошах: описує J-криву, де продуктивність спершу просідає і лише потім зростає, і показує, як зростання частки невдалих змін з'їдає віддачу.

Дві умови в цій знахідці ходять разом, і викидання будь-якої з них перебільшує результат: щільна зв'язаність і повільні процеси.

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

Як виглядають гроші

Фінансову картину задають три джерела, і одне з них цитують неправильно майже завжди.

Утримання проти змін. Найясніше публічне свідчення того, як legacy з'їдає бюджет, дає оглядове дослідження State of Digital Government Review британського Департаменту науки, інновацій і технологій, опубліковане в січні 2025 року. Це самооцінка уряду, а не незалежний аудит, і воно покриває центральний уряд Великої Британії, а не європейські підприємства, тому воно радше ілюструє механізм, ніж дає бенчмарк. Дослідження віднесло близько 28% технологічного естейту центрального уряду до legacy, проти 26% у 2023 році, і зазначило, що організації на кшталт DWP і NHS England «витрачають до 70 і навіть 85% технологічного бюджету на утримання замість модернізації або інновацій». Також воно виявило, що 22% legacy-систем позначені червоним, і що 28% із цих червоних не мають фінансування на виправлення. Ось ця остання пара і є механізмом, який варто позичити: нефінансована ремедіація це те, як legacy-проблема нарощується замість того, щоб вирішуватися.

Технічний борг. Широко цитована цифра, за якою від 10 до 20% технологічного бюджету, призначеного на нові продукти, перетікає на розв'язання проблем технічного боргу, походить із дослідження McKinsey «Tech debt: reclaiming tech equity», опублікованого в жовтні 2020 року на основі опитування 50 CIO компаній із доходом понад 1 млрд доларів. Це дані 2020 року, і цитувати їх треба саме так. Та ж робота оцінила технічний борг у 20 до 40% вартості всього технологічного естейту до амортизації. Продовження від квітня 2023 року додало, що компанії з найгіршими показниками технічного боргу приблизно на 40% частіше мають незавершені або скасовані ІТ-модернізації.

Їхнє дослідження бюджетів від березня 2026 року, побудоване на 17 глобальних компаніях у Європі, Північній Америці та Австралії, описує, що робить інакше дисциплінований край ринку. Компанії, яких воно називає deliberate modernizers, тримають щонайменше третину загальних технологічних витрат на зміни, а не на утримання, тримають інфраструктурні витрати на утримання щонайменше на 20% нижче за інші організації і спрямовують 57% витрат на застосунки саме на зміни. Два показники частки використовують різні знаменники, загальний технологічний бюджет і бюджет на застосунки, і про це варто пам'ятати, бо ці числа переказують так, ніби вони одне й те саме вимірювання.

Твердження про зростання, сказане правильно. Дослідження Accenture 2024 року зазвичай цитують як «сильне цифрове ядро дає на 60% вище зростання доходу». Це подвійне спрощення. Насправді знахідка, опублікована 17 липня 2024, звучить так: організації з розвиненим цифровим ядром плюс стратегічними інвестиціями в інновації плюс збалансованим підходом до технічного боргу досягали «до» 60% вищого темпу зростання доходу і на 40% вищого прибутку. Це результат за трьома умовами одночасно, з обмежувачем «до», і в пресрелізі не описано порівняльну групу настільки детально, щоб аналіз можна було відтворити. Модернізація створює умови для зростання. Подавати її як причину 60-відсоткового приросту це не те, що говорить дослідження.

Для ринкового контексту: прогноз Gartner від 27 липня 2026 дає світові витрати на ІТ у 6,37 трлн доларів у 2026 році, зростання на 14,2%, при цьому infrastructure as a service росте з 222 млрд доларів у 2025 до 287 млрд у 2026, і саме IaaS разом із системами для дата-центрів названі найшвидше зростаючими сегментами. Найсвіжіший опублікований Gartner світовий підсумок витрат кінцевих користувачів на публічний cloud досі становить 723 млрд доларів за 2025 рік, із релізу листопада 2024, і подавати його як цифру 2026 року не варто.

Яка стратегія модернізації якій системі підходить

Ефективна модернізація це рішення про портфель, а не окремий проєкт. Сім стандартних опцій і той компроміс, який насправді між ними вибирає.

Яка з семи ваша? Перелічити ці опції легко, а призначити важко. Вирішити, яка з них підходить кожній системі, спираючись на свідчення, а не на думки, це і є те, що дає assessment. Подивіться, як ми формуємо scope assessment модернізації

Чи запрацює портфельний підхід, вирішують три практики.

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

Обгорнути ядро і зменшувати його роль. Замість переписувати центральну систему однією високоризиковою програмою, навколо неї будують стабільні API, нову функціональність ведуть через сучасні сервіси і знімають із legacy-ядра відповідальність по одній, поки те, що залишилося, не стане достатньо малим, щоб його свідомо замінити або свідомо зберегти. Це strangler pattern, і він є правильним типовим вибором, коли legacy-система досі проводить критичні транзакції. Інкременти, які лише додають шляхи читання або нові сервіси, розвернути просто. Інкременти, що переносять запис або володіння даними, ні, тому їм потрібен власний дизайн відкату, а не припущення, що все зворотне.

Рефакторити вибірково. Це для зон із високою частотою змін, слабкою надійністю або прямим впливом на клієнта. Рефакторити стабільну back-office функцію тому, що код виглядає старим, це естетичне рішення, подане як інженерне.

Практична послідовність релізів виглядає так.

1. Скласти інвентар портфеля і мапу залежностей.
2. Класифікувати кожен застосунок за бізнес-цінністю і технічним станом.
3. Вибрати одну стратегію на застосунок, із названим власником.
4. Визначити хвилі міграції з явними критеріями відкату.
5. Автоматизувати тести, деплой, сканування безпеки і моніторинг до першого переключення, а не після.
6. Вивести стару інфраструктуру з експлуатації після підтвердження стабільності в продакшні і перевірити, що виведення справді відбулося.

Шостий крок найчастіше залишається недоробленим, а невиведені системи це те, як організації врешті платять і за старий естейт, і за новий.

Як схеми модернізації допомагають планувати і виконувати

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

Програмі потрібні чотири.

• Архітектура поточного стану. Застосунки, бази даних, інтеграції, користувачі, інфраструктура.
• Мапа залежностей. Системи вище і нижче за потоком, batch-джоби, API, передача файлів.
• Архітектура цільового стану. Майбутні сервіси, сховища даних, ідентичність, моніторинг, модель деплою.
• Дорожня карта міграції. Хвилі, точки виходу в продакшн, періоди співіснування, ворота виведення з експлуатації.

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

Схему, яку використовують, від схеми, яку ігнорують, відрізняють дві речі. Вона під контролем версій і оновлюється як код, а не доживає слайдом. І вона явно позначає елементи, релевантні для комплаєнсу: сховища персональних даних, аудиторські логи, шляхи доступу, межі шифрування, сторонніх процесорів і операційний моніторинг. Саме цей шар дає людям, відповідальним за GDPR, NIS2 і DORA, розглянути архітектурне рішення, поки воно ще рішення.

Корисна схема відповідає на п'ять питань: що є сьогодні, що від чого залежить, що має змінитися, що не має зламатися і що можна вимкнути. Та, що на них не відповідає, занадто абстрактна, щоб керувати виконанням.

Що входить у роботу з модернізації

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

• Assessment. Дослідження вихідного коду, інфраструктури, баз даних, інтерфейсів, ліцензій, контролів безпеки та операційних процесів, плюс розмови з людьми, які ці системи тримають. На виході: інвентар застосунків, мапа залежностей, класифікація ризику по кожній системі і рекомендована стратегія по кожній системі.
• Дорожня карта архітектури. Цільовий стан на рівнях застосунків, даних, інтеграцій та інфраструктури, з позначеними елементами, релевантними для комплаєнсу. На виході: схеми під контролем версій, а не слайди.
• Планування міграції. Хвилі, моделі відкату, стратегія середовищ і критерії виходу в продакшн. На виході: послідовність, у якій кожен крок має визначений шлях назад.
• Інженерне виконання. Рефакторинг, контейнеризація, розробка API, міграція баз даних, автоматизація.
• Забезпечення якості. Регресійне, продуктивне і безпекове тестування плюс реконсиляція даних, яку на міграціях із великим обсягом даних недооцінюють найчастіше.
• Операційна модель. CI/CD, observability, управління інцидентами і передача, щоб внутрішня команда могла тримати результат сама.

Дві речі варто перевірити до того, як щось підписувати, і жодна з них не технічна.

Перша це хто вирішує. Аутсорсинг виконання не аутсорсить відповідальність. Внутрішній product owner, керівник безпеки та enterprise architect мусять залишитися тими, хто ухвалює рішення, бо залежності, які стопорять програми модернізації, зазвичай організаційні, а не технічні, і зовнішня команда сама їх не розв'яже.

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

Якщо ви зважуєте модернізацію проти дедлайну за NIS2 або DORA, або у вас є AI-ініціатива, яка не віддає того, що обіцяв пілот, поговоріть із нашою інженерною командою напряму. Без форми і без демо: розмова з людьми, які виконували б цю роботу.

Поговорити з нашою інженерною командою →

Джерела

• Eurostat, «53% EU enterprises used paid cloud services in 2025», 3 лютого 2026 (точне значення 52,7%): ec.europa.eu
• Європейська Комісія, State of the Digital Decade 2026, 17 червня 2026: digital-strategy.ec.europa.eu
• Eurostat, «20% of EU enterprises use AI technologies», 11 грудня 2025: ec.europa.eu
• Рішення (ЄС) 2022/2481, Digital Decade Policy Programme, ст. 4(1)(3)(a): eur-lex.europa.eu
• Європейська Комісія, передача Ірландії, Іспанії, Франції та Нідерландів до Суду ЄС, 8 липня 2026: digital-strategy.ec.europa.eu
• Директива (ЄС) 2022/2555 (NIS2), стаття 20: eur-lex.europa.eu
• Регламент (ЄС) 2022/2554 (DORA): eur-lex.europa.eu
• EIOPA, EBA і ESMA, визначення критичних постачальників ICT-послуг, 18 листопада 2025: eiopa.europa.eu
• Регламент (ЄС) 2016/679 (GDPR), стаття 83: eur-lex.europa.eu
• CMS GDPR Enforcement Tracker, дата звернення 6 серпня 2026: enforcementtracker.com
• ENISA Threat Landscape 2025, 1 жовтня 2025: enisa.europa.eu
• IBM, Cost of a Data Breach Report 2026, 29 липня 2026: ibm.com
• Google Cloud і DORA (DevOps Research and Assessment), 2025 DORA Report: State of AI-assisted Software Development, 23 вересня 2025: dora.dev
• DORA (DevOps Research and Assessment), ROI of AI-assisted Software Development, квітень 2026: dora.dev
• Департамент науки, інновацій і технологій Великої Британії, State of Digital Government Review, січень 2025: assets.publishing.service.gov.uk
• McKinsey, «Tech debt: reclaiming tech equity», 6 жовтня 2020
• McKinsey, «Breaking technical debt's vicious cycle to modernize your business», 25 квітня 2023
• McKinsey, «Recalibrating technology budgets for the AI era», 30 березня 2026
• Accenture, «Reinventing with a Digital Core», 17 липня 2024
• Gartner, «Worldwide IT Spending to Grow 14.2% in 2026», 27 липня 2026
• Gartner, «Worldwide Public Cloud End-User Spending to Total $723 Billion in 2025», 19 листопада 2024
• C4 Model: c4model.com
• arc42: arc42.org