Міграція Drupal: де ламається перенесення контенту
Перенесення контенту між версіями Drupal або на новий майданчик майже ніколи не проходить «за один прогін». Основна причина — контент у Drupal не живе сам по собі: матеріал пов'язаний з таксономією, полями-посиланнями на інші сутності, файлами, меню та правами доступу.
Модуль Migrate переносить сутності по одній і за замовчуванням не гарантує, що пов'язана сутність уже існує на момент імпорту.
Звідси три класичні збої: биті посилання на ще не створені матеріали, дублі при повторному запуску та роз'їхалася таксономія, коли терміни створюються заново замість прив'язки до існуючих.
Биті посилання з'являються, коли порядок міграцій не вибудуваний: матеріал посилається на сутність, якої в новій базі ще немає. Дублі — наслідок відсутності ідемпотентності: без явного зіставлення вихідного ідентифікатора повторний запуск створює копії замість оновлення.
Таксономія ламається найтихіше: терміни з однаковою назвою, але різними вихідними ідентифікаторами згортаються або розмножуються, і фільтри на сайті починають віддавати порожні вибірки.
Ми починаємо не із запуску імпорту, а з карти зв'язків: які сутності на що посилаються і в якому порядку їх переносити.
Далі налаштовуємо зіставлення ідентифікаторів, щоб повторний прогін оновлював записи, а не плодив дублі, і перевіряємо цілісність зв'язків до включення сайту для відвідувачів. Розбираємо, як це закривається на кожному типі збою.
Що дає керована міграція контенту
Цілісність контенту замість ручної звірки
Модуль Migrate переносить матеріали разом з їхніми зв'язками: таксономія, посилання між вузлами, прив'язка медіа та полів. Зв'язки відновлюються за ідентифікаторами джерела, а не збираються вручну, тому після перенесення не залишається «висячих» посилань і осиротілих термінів.
Перевірка цілісності стає частиною самого процесу: розбіжності видно одразу, а не спливають через місяць у пошуку.
Час перенесення скорочується в рази
Кожен тип матеріалу описується окремим набором правил, і перенесення йде пакетами, а не по одному запису. Там, де ручна міграція займала тижні, керована вкладається в дні, а повторний прогін після правок — у години.
Автоматизація міграції прибирає головне джерело затримок: очікування, поки людина перенесе чергову порцію контенту.
Перевірка зв'язків передбачувана
Перед перенесенням налаштовуються перевірки: скільки записів очікується на виході, чи всі посилання розв'язалися, чи не загубилися вкладення. Результат порівнюється з вихідними даними за лічильниками, і відхилення видно до публікації. Це знімає ризик, що частина каталогу або блогу просто не доїде до нової версії.
Відкат і повторний запуск без втрат
Перенесення йде в тестове середовище, де його можна прогнати стільки разів, скільки потрібно. Якщо правила уточнили — запуск повторюється на чистій базі, і результат знову перевіряється.
Такий цикл дає впевненість, що бойове перенесення пройде за вже відпрацьованим сценарієм, а не стане експериментом на живому сайті.
Способи перенесення: порівняння підходів
Перенесення контенту в Drupal майже ніколи не зводиться до «вивантажити й залити назад»: у матеріалів є зв'язки з таксономією, посилання між сутностями, ревізії та метадані полів.
Вибір підходу визначає, у скільки обійдеться повторний прогін, коли на тестовій копії щось поїде, і чи залишиться перенесення відтворюваним.
Нижче — три реальні варіанти, між якими обирають на старті проєкту, з їхніми межами застосовності.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Ручне перенесення через інтерфейс | Разові обсяги в десятки матеріалів, різний формат джерел, немає повторюваності | Не масштабується, помилки не відстежуються, зв'язки та ревізії губляться, повторний прогін — з нуля |
| Скрипти міграції (власний код) | Нестандартне джерело або логіка перетворення, якої немає в готових рішеннях | Потребує підтримки коду, немає єдиного журналу та відкату, кожна зміна джерела — правка скрипту |
| Модуль Migrate | Структуроване джерело, регулярні або великі перенесення, потрібна повторюваність | Потребує опису відповідності полів, для нестандартних джерел потрібен власний плагін |
Модуль Migrate описує перенесення декларативно: джерело, обробники полів і приймач задаються конфігурацією, а не кодом «тут і зараз».
Це дає те, чого позбавлені перші два підходи — прогін можна повторити на чистій базі й отримати той самий результат, а розходження видно у звіті, а не спливають через місяць у проді.
Ручне перенесення та скрипти не скасовуються: для десятка сторінок або джерела без структури вони швидші. Але щойно обсяг зростає або перенесення потрібно повторити після правок, декларативний підхід окупається — розбираємо, як це влаштовано на практиці.
Як відбувається налаштування міграції Drupal
Налаштування міграції в Drupal — це не разовий імпорт, а керований процес із відтворюваними кроками. Модуль Migrate описує перенесення декларативно: що звідки беремо, як перетворюємо, куди кладемо.
Тому результат відтворюваний на тестовому та промисловому середовищі, а не залежить від ручних правок.
- Аудит контенту. Інвентаризуємо сутності джерела: типи матеріалів, таксономії, користувачів, файли, зв'язки між ними. Фіксуємо обсяги, дублі, биті посилання та поля без аналога в цільовій моделі — це визначає обсяг робіт, а не побажання до дизайну.
- Схема відповідності. Складаємо карту «джерело → сутність Drupal»: які поля стають полями, що переходить у таксономії, як переносяться вкладені структури та медіа. Для кожної розбіжності вирішуємо заздалегідь — перетворення, об'єднання або усвідомлена відмова від даних.
- Налаштування міграції. Описуємо процеси перенесення з обробкою тексту, дат, посилань і файлів, налаштовуємо залежності між кроками, щоб матеріали не приїжджали раніше за свої довідники. Прогоняємо на копії та правимо до чистого результату.
- Перевірка цілісності. Звіряємо кількість записів, зв'язки, права доступу та коректність відображення. Окремо перевіряємо повторний запуск: міграція має оновлювати, а не дублювати контент.
- Перенесення та приймання. Виконуємо фінальний прогін у узгодженому вікні, фіксуємо точку відкату та передаємо команді документацію щодо запуску й повторного застосування.
Такий порядок прибирає головний ризик міграції — розбіжність між тим, що перенесли, і тим, що очікували побачити. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Артефакти на виході: конфігурації та регламенти
Передаємо не «архів проєкту», а робочу систему міграції, яку ваша команда може запускати й розвивати без нас. Кожен артефакт — у репозиторії, з історією змін і прив'язкою до середовищ.
- Конфігурації міграції — набір правил перенесення у вигляді декларативних файлів: джерела, відповідність полів, обробники значень, залежності між наборами. Перенесення відтворюється однією командою, а не ручними правками в інтерфейсі.
- Схеми даних — карта відповідності «джерело → цільова структура»: типи матеріалів, таксономії, зв'язки, поля-посилання. За нею видно, що і куди переїжджає, і де потрібні перетворення.
- Політики доступу — ролі, права на читання й публікацію перенесеного контенту, правила для службових і архівних матеріалів. Щоб після перемикання ніхто не втратив і не отримав зайвий доступ.
- Регламент запуску — порядок дій: підготовка середовища, прогін на копії, звірка обсягів, перемикання, відкат. З точками контролю та відповідальними на кожному кроці.
- Регламент відкату — як повернутися до попереднього стану, якщо звірка не зійшлася: збережені зрізи, порядок відновлення, критерії зупинки.
- Документація — опис логіки перенесення, відомих обмежень і типових помилок із рішеннями. Достатньо, щоб новий інженер розібрався без усних пояснень.
- Звіти звірки — протоколи прогонів: скільки записів перенесено, скільки відхилено і чому. Це доказ повноти міграції, а не обіцянка.
Комплект закриває весь цикл: від першого тестового прогону до супроводу після перемикання. Опишіть вашу задачу — повернемося з оцінкою та планом робіт із міграції.
Кейс: перенесення каталогу без втрати зв'язків
Замовник прийшов з каталогом на Drupal: близько 40 000 матеріалів, три типи сутностей, пов'язаних між собою посиланнями на терміни таксономії та на файли.
Попередній підрядник переносив контент скриптами поверх прямого запису в базу — частина зв'язків «матеріал → термін» залишилася у старих таблицях, частина продублювалася.
На проді це виглядало так: у 18% карток не відкривалися пов'язані розділи, а редактори правили зв'язки вручну — по 6-8 хвилин на картку.
Що було до
- Втрачених зв'язків «матеріал → термін»: близько 7 200 (18% каталогу).
- Битих посилань на файли: 1 400, частина медіа лежала поза керованим сховищем.
- Відновлення після невдалого прогону: півтора дня — відкат робили з дампа бази, бо проміжних станів ніхто не фіксував.
- Ручне правлення: два тижні роботи редакторів, і після нього зв'язки знову розходилися під час наступного імпорту.
Що змінили
Зібрали міграції на штатному модулі Migrate: кожен тип сутності — окремий набір правил, зв'язки проставляються на етапі обробки, а не після.
Терміни таксономії та медіа заводимо першими і запам'ятовуємо відповідність «старий ідентифікатор → новий» в окремій таблиці — за нею зв'язки відновлюються детерміновано, без вгадування за назвою. Прогін іде в staging, результат звіряється з джерелом до перемикання проду.
Що стало
- Втрачених зв'язків: 0, розходження з джерелом — 0 рядків за контрольною звіркою.
- Битих посилань на файли: 0, усе медіа перенесено в кероване сховище.
- Повний прогін: 40 хвилин, повторний запуск ідемпотентний — дублів не з'являється.
- Відновлення після збою: 12 хвилин — відкат до останнього зафіксованого стану замість розгортання дампа.
- Ручне правлення редакторів: не знадобилося.
Окремо віддали замовнику карту міграції: які поля в що переходять, де правила допускають розходження і як запускати перенесення повторно під час наступного оновлення каталогу.
Чим відрізняється міграція Drupal від ручного перенесення?
Ручне перенесення — це коли контент-менеджер відкриває стару сторінку й копіює текст, зображення та поля в нову.
На десяти матеріалах різниця непомітна, на тисячі починається розходження: десь загубився alt у зображення, десь не перенеслася таксономія, десь залишилося бите посилання на стару адресу.
Перевірити це очима на всьому обсязі неможливо, а помилки випливають уже після запуску, коли пошукові системи переобійшли сайт.
Міграція Drupal через модуль Migrate працює інакше: ви описуєте правила перенесення один раз — звідки беремо сутність, як мапимо поля, що робити з вкладеними зв'язками, — і далі процес іде пакетами по всій базі.
Кожен матеріал проходить через одні й ті самі правила, тому тисячна сторінка переноситься так само точно, як перша. Це і є головна відповідь про надійність: не «акуратніше», а відтворювано.
Швидкість тут теж не про «швидше руками», а про те, що процес не залежить від людино-годин. Перенесення йде пакетами у фоновому режимі, його можна зупиняти й продовжувати з місця зупинки, а перед запуском — прогнати на копії бази та звірити результат.
Ручне перенесення так не перевірити: щоб зрозуміти, що все зійшлося, потрібно знову пройти весь обсяг очима.
Є й третя різниця — оборотність. Міграція залишає журнал: які записи оброблено, які пропущено і чому. Якщо після запуску виявиться, що частину матеріалів потрібно перекласти інакше, правило правлять і перезапускають лише зачеплені пакети, не торкаючись уже перенесеного. При ручному перенесенні відкат означає повторну роботу з нуля.
Тому вибір між модулем Migrate і ручним перенесенням — це не про зручність інструмента, а про те, чи готові ви відповідати за цілісність даних на всьому обсязі. До кількох десятків сторінок ручний шлях виправданий, далі ціна помилки зростає швидше, ніж обсяг.
Часті технічні сумніви
Перший і найпоширеніший страх — що міграція вимагатиме зупинки вже працюючого сайту.
На практиці ми переносимо контент на копію бойової бази, звіряємо результат і лише потім перемикаємо трафік: відвідувачі продовжують працювати на поточній версії, а вікно недоступності зводиться до хвилин.
Якщо сайт розгорнуто й активно наповнюється, спочатку фіксуємо точку синхронізації, переносимо основний масив, а зміни, що накопичилися за час перенесення, наздоганяємо повторним проходом по журналу змін.
Що робити з нестандартними полями та типами контенту?
Стандартні сутності переносяться типовими правилами, а ось поля, додані під конкретну задачу, вимагають окремого зіставлення. Ми описуємо кожне таке поле в конфігурації міграції, задаємо перетворення значень і порядок обробки посилань між матеріалами.
Якщо структура на джерелі та приймачі відрізняється, переносимо дані в проміжний шар і розкладаємо за потрібними полями вже на боці приймача — так нестандартний контент не губиться і не перетворюється на сміття.
Як перевіряється цілісність після перенесення?
Звіряємо не «на око», а за контрольними сумами: кількість матеріалів кожного типу, число прив'язаних файлів і зображень, заповненість обов'язкових полів, збереженість зв'язків між сутностями.
Окремо перевіряємо, що жоден матеріал не залишився без автора, категорії чи адреси сторінки. Розбіжності потрапляють у звіт із зазначенням конкретних записів — їх розбираємо точково, а не перезапускаємо всю міграцію заново.
Чи можна відкотитися, якщо щось пішло не так?
Так. Перенесення йде на копію, тому бойовий сайт залишається недоторканим до моменту перемикання. Перед фінальним запуском зберігаємо повний знімок бази та файлів — за будь-якого сумніву повертаємося до нього й повторюємо перенесення з виправленою конфігурацією. Відкат не вимагає ручного відновлення контенту: повернення до знімка займає хвилини.
Що з адресами сторінок і пошуковою видачею?
Старі адреси зберігаємо або налаштовуємо перенаправлення на нові, щоб накопичений трафік і позиції не втратилися. Карту адрес готуємо до перемикання, а після запуску перевіряємо, що всі ключові сторінки відкриваються за колишніми посиланнями без помилок.
Обговоримо ваше завдання міграції
Щоб повернутися з оцінкою міграції, а не із загальними словами, нам потрібен від вас мінімум вхідних даних: поточна платформа та її версія, обсяг контенту за типами сутностей, кількість мов, перелік інтеграцій і жорсткі дати, якщо вони є. Цього достатньо, щоб зрозуміти схему перенесення, оцінити трудовитрати й назвати реальний термін.
Далі ми розберемо структуру даних на боці джерела, зіставимо її з моделями матеріалів і полями на приймачі, окремо пройдемося по файлах, посиланнях, таксономії та користувачах.
За підсумком ви отримаєте план робіт з етапами, точками перевірки та порядком перенесення — без сюрпризів у процесі.
- Розбір поточного сховища: типи матеріалів, поля, зв'язки, таксономія, медіа, користувачі та ролі.
- Схема зіставлення: що переноситься один в один, що потребує перетворення, що відкидається усвідомлено.
- Порядок міграції: контент, файли, посилання, метадані, редиректи — з перевіркою на кожному кроці.
- План перевірок: звірка кількості записів, вибіркова валідація полів, контроль битих посилань і зображень.
- Стратегія відкату: як повернутися до вихідного стану, якщо приймання виявить розбіжності.
- Оцінка термінів і складу робіт за етапами — з урахуванням ваших дат і обсягу.
- Регламент підтримки після перенесення: оновлення, резервні копії, моніторинг доступності.
Опишіть завдання — платформу, обсяг і обмеження. Ми повернемося з оцінкою міграції та планом робіт, де буде видно, що і в якій послідовності робимо.
