Міграція з Drupal 7 на Drupal 10: інструкція та практичні приклади

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.

Стратегії міграції: як обрати?

Migrate API — рекомендований варіант. Він дозволяє запускати міграції багаторазово, додаючи лише змінений контент. Різниця в трудозатратах між Migrate API та ручною міграцією становить 3–5 разів на користь автоматизації. Економія бюджету при використанні Migrate API досягає 60-80%.

Як перенести кастомні модулі?

Кастомні модулі 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-сайту, щоб отримати точні терміни та вартість.

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Зв'яжіться з нами, щоб обговорити деталі.

Редизайн та міграція сайту: зміна CMS, збереження SEO

Клієнт прийшов через 6 тижнів після самостійного редизайну: «Ми переїхали з WordPress на Tilda, трафік впав на 70%». Відкриваю Google Search Console — 847 сторінок віддають 404, URL-структура повністю змінилася, жодного 301-редиректу. Яндекс ще не переіндексував новий сайт, позиції впали. Відновлення зайняло 4 місяці та призвело до значних фінансових втрат. Наш досвід — понад 7 років та 80+ успішних міграцій. Клієнти, які замовляють професійну міграцію, відновлюють трафік у 3 рази швидше, ніж ті, хто виконує її самостійно.

Чому міграції ламають SEO?

Пошуковики проіндексували конкретні URL. Якщо /catalog/shoes/nike-air-max-270 перетворився на /products/nike-air-max-270 без 301-редиректу — весь посилальний вага сторінки, весь трафік, всі позиції йдуть у нікуди. Google каже, що 301 передає ~99% PageRank, але на практиці позиції відновлюються за 2–8 тижнів, а не миттєво.

Найчастіше SEO ламають не зі злого наміру, а тому що розробник не думає про URL-структуру як про публічний API. Ось типові поломки:

Як відновити трафік після невдалої міграції?

Якщо трафік впав — дійте негайно:

1. Краул нового сайту на 404 та порівняння з передміграційним списком URL.
2. Створення редиректів для всіх втрачених сторінок з трафіком >0.
3. Перевірка структурованих даних та мета-тегів на тестовій вибірці.
4. Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
5. Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).

У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.

Як підготувати сайт до міграції: що не можна пропустити?

До початку розробки нового сайту потрібно:

1. Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
2. Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
3. Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
4. Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
5. Зберегти Core Web Vitals з Search Console за попередні 90 днів.

Таблиця для фіксації:

Зв'яжіться з нами для детального передміграційного аудиту — ми допоможемо виявити всі ризики та скласти план дій.

Мапінг URL та редиректи

Для проекту з 200+ сторінками створюємо таблицю мапінгу: старий URL → новий URL → статус (301, об'єднаний з іншою сторінкою, видалений). Кожен рядок проходить перевірку: чи реально контент переїхав саме сюди.

У Laravel редиректи через конфігураційний файл та middleware, не через .htaccess — це швидше та керованіше. Для WordPress → Next.js: редиректи налаштовуються в next.config.js (статичні) та на рівні Nginx/CDN для динамічних. Старий .htaccess на shared хостингу з 500+ рядками редиректів — особливий ад. Кожен редирект перевіряється послідовно, продуктивність падає. Переносимо в Nginx map директиву або Redis-кеш для динамічного пошуку.

Міграція контенту з різних CMS

WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API або WP All Export для експорту постів, метаполів, медіафайлів. Скрипт міграції на Node.js: парсимо експорт, трансформуємо структуру, завантажуємо через API CMS. Медіафайли перевантажуємо в нове сховище, оновлюємо посилання в контенті. Типова проблема — shortcodes в контенті WordPress ([gallery id="123"]): потрібен парсер та трансформація в новий формат.

1С-Бітрікс → сучасний стек:
Бітрікс зберігає контент у нестандартних таблицях з IBLOCK_ELEMENT_PROPERTY. Прямий SQL-експорт через phpMyAdmin або Bitrix API. Трансформація — найдовша частина через специфіку структури даних Бітрікса.

Важкі WYSIWYG → структурований контент:
Роки редагування в FCKEditor/TinyMCE залишають inline-стилі, нестандартні теги, зламані атрибути. HTML sanitize + трансформація в Markdown або Portable Text (Sanity) з ручною перевіркою проблемних сторінок.

SEO-збереження технічних елементів

Структуровані дані (Schema.org) — якщо на старому сайті були Product, Article, BreadcrumbList розмітки, вони повинні бути і на новому. Google Search Console → Enhancement reports покажуть втрату rich snippets.

Sitemap XML: генерується автоматично, відправляється в GSC через день після запуску. Старий sitemap залишається до повної переіндексації.

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

Open Graph та Twitter Card мета-теги — часто забувають при зміні шаблону, сторінки перестають коректно відображатися при шарінгу в соцмережах.

Як контролювати сайт після запуску?

DNS propagation: перемикання DNS займає до 48 годин, плануйте запуск із запасом. Cloudflare як DNS-провайдер — propagation займає хвилини, не години.

Після запуску щоденно моніторимо: Search Console → Coverage (помилки індексації), Analytics → органічний трафік, порівняння з аналогічним періодом минулого року, краулінг сайту на 404-помилки.

Перші 2 тижні — критичний період. Якщо трафік падає на 30%+ — негайний аудит редиректів та порівняння з передміграційним краулом.

Що входить в роботу

Результати, які ви отримуєте:

1. План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
2. Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
3. Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
4. Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
5. Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
6. Моніторинг Coverage в Search Console з повідомленнями про помилки.
7. Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.

Терміни та орієнтири

• Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
• Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
• Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.

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

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