Drupal 10 доживает последний год: когда переходить на 11 и чего ждать от Drupal 12

Если сайт компании живёт на Drupal 10, зиму он встретит без обновлений безопасности. Поддержка «десятки» заканчивается 9 декабря 2026 года. А за два дня до этого, на неделе 7 декабря, выходит Drupal 12: релиз сдвинули с августа на декабрь.

Отсюда развилка. Делать обновление Drupal сейчас, до одиннадцатой версии, или переждать и прыгнуть сразу на двенадцатую? Ответ неочевиден, поэтому разберём по датам.

Четыре даты второго полугодия

Картину можно выписать в календарь.

• Сейчас: актуальна ветка Drupal 11.4. Релиз зрелый, большая часть contrib-модулей на него уже переехала.
• Сентябрь: выходит бета Drupal 12. По ней разработчики модулей начинают проверять совместимость.
• Неделя 7 декабря 2026 года: выходит сам Drupal 12. Изначально его планировали на август, потом перенесли.
• 9 декабря 2026 года: у Drupal 10 наступает EOL, то есть конец жизненного цикла.

EOL не значит, что сайт сломается. Значит, что он больше не получает патчи безопасности. А на CMS держатся формы, личные кабинеты, обмен с CRM. Каждая новая дыра в ядре или в популярном модуле остаётся открытой навсегда. Свежие уязвимости популярных движков давно разбирают боты: жертву находят сканом, а не руками. Так что план «поживём на старой версии ещё годик» стоит на плохой арифметике.

Даты иногда двигают, как вышло с двенадцатой версией. Сверяйтесь с первоисточником: календарь релизов ядра на drupal.org. Там же публикуют точное число, когда выйдет бета.

Почему дорога идёт через одиннадцатую

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

Первая. Прыжка через версию в Drupal просто нет. Мажорные обновления идут по порядку, и с десятки вы в любом случае попадаете сначала на одиннадцать.

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

Третья, и она главная. Переход с 11 на 12 обойдётся заметно дешевле, чем с 10 на 11. Мажорные релизы Drupal устроены так: API помечают устаревшим в текущей версии, а удаляют в следующей. Код, вычищенный от deprecated-вызовов под Drupal 11, заработает на 12 почти без правок.

Что внутри двенадцатой: Symfony 8 и вычищенное ядро

Технически Drupal 12 строится на Symfony 8. Это свежая версия PHP-фреймворка, на котором стоит ядро. Отсюда прирост производительности и актуальные требования к PHP.

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

Для владельца сайта вывод такой: цену миграции определяет не ядро. Её определяют объём кастомного кода и число заброшенных contrib-модулей. Сайт на актуальной теме и живых модулях переезжает между мажорными версиями за дни. Сайт с пятью самописными модулями без тестов ползёт неделями.

Сколько стоит переезд и сколько занимает

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

• Аудит кода и модулей. От 40 тысяч рублей, три-пять рабочих дней. На выходе документ: что заброшено, что сломается, сколько часов на каждый пункт.
• Сайт на живых модулях и актуальной теме. От 120 тысяч рублей, одна-две недели. Поднимаем ядро и contrib, чиним мелочи вёрстки, проверяем формы и обмен с CRM.
• Сайт с самописными модулями без тестов. От 350 тысяч рублей, полтора-два месяца. Половина сметы уходит на переписывание кастома под новые API.
• Сопровождение после переезда. От 20 тысяч рублей в месяц: минорные обновления, патчи безопасности, дежурство на случай отката.

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

Как выглядит аудит перед переездом

Аудит нужен, чтобы смета перестала быть диапазоном «от недели до полугода». Три-пять дней работы, пять шагов.

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

Документ остаётся у вас. С ним можно идти к любому подрядчику, не только к нам.

Canvas и агенты: ИИ въезжает в ядро

Содержательная новинка двенадцатой версии: AI-ассистент Canvas и агентные инструменты переезжают из экспериментов в штатную поставку. Редактор словами описывает, какую страницу хочет собрать, и получает черновик со структурой и компонентами. Для контент-команд это сдвиг того же порядка, каким когда-то стал Layout Builder. Меньше задач «поправьте нам блок» уходит разработчикам.

Оговорка для бюджета. Ассистент в ядре даёт интерфейс, а не саму нейросеть. Модель подключается отдельно и считает деньги по расходу. Условия станут ясны ближе к релизу, поэтому в смету осеннего переезда эту строку я бы пока не закладывал.

Что делать до декабря

План на вторую половину 2026 года зависит от того, на чём у вас сайт.

• Drupal 7, 8 или 9: мигрировать немедленно. Эти версии давно без поддержки, а путь на 12 в любом случае лежит через 11.
• Drupal 10: запланировать обновление до 11 на осень, не дожидаясь декабрьского дедлайна. В конце года подрядчики будут перегружены такими же горящими проектами.
• Drupal 11: после сентябрьской беты прогнать кастомные модули на совместимость с 12. Deprecated-вызовы вычистить заранее.
• Всем: провести инвентаризацию модулей. Какие contrib заброшены, какой кастомный код реально работает. Это 80% сметы будущей миграции.
• Перед любым обновлением: полный дамп базы и файлов, тестовый прогон на копии, и только потом продакшен.

Если подрядчика у вас нет

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

• Узнайте версию. Админка, раздел «Отчёты», страница состояния. Там же видно версию PHP и список обновлений.
• Снимите дамп базы и файлов. Проверьте, что из него разворачивается рабочая копия. Если копии нет, начинать надо с неё, а не с миграции.
• Выпишите всё нестандартное: калькулятор, личный кабинет, обмен с 1С, самописные формы. Именно этот список определит цену.
• С ним идите за оценкой. Подрядчик, который называет сумму не глядя на модули, называет её наугад.

Цена переезда сильно зависит от того, когда за него взяться. Осенью это плановая работа, в декабре пожарная. Не хватает рук или экспертизы оценить объём? Начните с аудита инфраструктуры и кода: после него смета превращается из «где-то между неделей и полугодом» в план с датами. Сам переезд мы делаем отдельно, это миграция CMS на актуальную версию.