Drupal 7 більше не отримує оновлень безпеки. Сайт під загрозою атак, а прямого шляху до Drupal 10 немає — тільки повноцінна міграція. Ми провели 20+ таких проєктів: від 50 до 200 000 нод. Наш досвід дозволяє обійти типові пастки та вкластися в мінімальний downtime.
Migrate API прискорює перенесення контенту в 3–5 разів порівняно з ручним вивантаженням. Але міграція — це не лише контент: кастомні модулі та теми доводиться переписувати повністю. Drupal 7 — процедурний і без Composer, Drupal 10 — OOP на Symfony з YAML-роутингом. Різниця архітектур неминуче призводить до повного рефакторингу коду.
Міграція з Drupal 7 на Drupal 10: покрокова інструкція
Архітектурні відмінності: чому це не апгрейд
Drupal 7 та Drupal 10 — архітектурно різні системи. D7 не використовує Composer, OOP, Symfony компоненти. Контент мігрується через Migrate API, код тем і модулів переписується повністю. Це повноцінний рефакторинг, а не оновлення. Наприклад, hook_menu в D7 перетворюється на YAML-маршрути, а процедурні функції — на сервіси Dependency Injection.
Стратегії міграції: як обрати?
| Стратегія | Опис | Downtime | Коли підходить |
|---|---|---|---|
| Migrate API | Програмна міграція контенту з D7 БД в D10. Багаторазовий запуск до перемикання. | Хвилини | Більшість проєктів |
| Manual content migration | Експорт через Views, імпорт через Migrate або вручну. | Години | Сайти до 100 нод |
| Big bang | Повна зупинка D7, налаштування D10, міграція за один раз. | Дні | Прості сайти, коли downtime допустимий |
Migrate API — рекомендований варіант. Він дозволяє запускати міграції багаторазово, додаючи лише змінений контент. Різниця в трудозатратах між Migrate API та ручною міграцією становить 3–5 разів на користь автоматизації. Економія бюджету при використанні Migrate API досягає 60-80%.
Як працює Migrate API під капотом?
Migrate API використовує плагіни source, process, destination для кожної сутності. Source читає дані з D7 БД, process перетворює поля, destination зберігає в D10. Це дозволяє перевикористовувати плагіни та легко налаштовувати маппінг.Як перенести кастомні модулі?
Кастомні модулі Drupal 7 потрібно повністю переписувати під архітектуру Drupal 10. Наприклад, hook_menu замінюється на YAML-файл mymodule.routing.yml, а процедурні функції — на класи з анотаціями. Складність переписування залежить від розміру модуля. Часто потрібен рефакторинг всієї бізнес-логіки. Замовте аудит вашого сайту, щоб оцінити трудомісткість.
Як ми проводимо міграцію: покроково
Спочатку проводимо повний аудит поточного сайту. Заходимо на сервер D7 і збираємо метрики: список активних модулів, типи нод, розмір БД. Потім на новому сервері розгортаємо Drupal 10 та встановлюємо пакети міграції.
composer create-project drupal/recommended-project drupal10-site cd drupal10-site composer require drupal/migrate_plus drupal/migrate_tools drupal/migrate_upgrade drupal/migrate_source_csv drush en migrate migrate_plus migrate_tools migrate_upgrade -y Підключаємо базу D7 як додаткову в settings.php:
$databases['migrate']['default'] = [ 'driver' => 'mysql', 'database' => 'drupal7_db', 'username' => 'db_user', 'password' => 'db_pass', 'host' => '127.0.0.1', 'port' => '3306', 'prefix' => '', ]; Команда drush migrate:upgrade генерує YAML-конфігурації для користувачів, таксономії, типів контенту, полів, нод, файлів, блоків та меню. Потім міграції запускаються в порядку залежностей: спочатку ролі, потім типи контенту, поля, таксономія, користувачі, файли, ноди, меню та блоки.
drush migrate:import upgrade_d7_user_role drush migrate:import upgrade_d7_node_type drush migrate:import upgrade_d7_field drush migrate:import upgrade_d7_field_instance drush migrate:import upgrade_d7_taxonomy_vocabulary drush migrate:import upgrade_d7_taxonomy_term drush migrate:import upgrade_d7_user drush migrate:import upgrade_d7_file drush migrate:import upgrade_d7_node_complete drush migrate:import upgrade_d7_menu drush migrate:import upgrade_d7_block Проблемні зони та їх рішення
- CCK/Field API: Field Collection в D7 не мігрується напряму — потрібен модуль
migrate_field_collection. - Views: Views 3 (D7) переносяться частково. Складні представлення з relationships доведеться перестворювати вручну.
- Медіафайли: Файли копіюються через
file_copyплагін, джерело вказується якsource_base_path.
Отримайте консультацію — ми оцінимо складність вашого проєкту та запропонуємо оптимальний план.
Як мінімізувати downtime?
Використовуємо дельта-міграцію. За кілька днів до перемикання запускаємо первинну міграцію всього контенту. У день перемикання спочатку вмикаємо режим обслуговування на D7, потім запускаємо інкрементальне оновлення: drush migrate:import --all --update. Після цього перемикаємо DNS на D10 та вимикаємо режим обслуговування. Весь downtime — 15-30 хвилин. Зв'яжіться з нами для оцінки вашого проєкту.
Що входить в роботу?
- Повний аудит поточного D7-сайту (модулі, теми, контент, DB)
- Міграція контенту через Migrate API з гарантією цілісності
- Перепис кастомних модулів та тем на OOP/Symfony
- Налаштування SEO-модулів (metatag, redirect, pathauto)
- Тестова міграція та приймальне тестування
- Документація з нової архітектури, доступи до сервера та адмінки
- Пост-міграційна підтримка на 2 тижні
Замовте аудит D7-сайту, щоб отримати точні терміни та вартість.
Терміни та вартість
| Тип сайту | Термін |
|---|---|
| Простий (< 100 нод, стандартні типи) | 2-3 тижні |
| Середній (500-5000 нод, кастомні модулі) | 4-8 тижнів |
| Великий (50k+ нод, складні залежності) | 3-6 місяців |
Вартість розраховується індивідуально після аудиту. Зв'яжіться з нами, щоб обговорити деталі.







