Міграція Magento 1 на 2: що ламається без плану перенесення
Магазин на застарілій версії Magento тримається до першого конфлікту: розширення під стару гілку перестають отримувати оновлення, а частина вже несумісна з новою архітектурою.
Підключити новий модуль оплати або доставки стає завданням з обхідним шляхом, а виправлень безпеки для ядра не виходить — уразливості закривають правками в чужому коді.
Підтримка старої версії впирається в людей і у відсутність стенду. Інженерів, які пам'ятають її устрій, все менше, документація з кастомізацій часто неповна, і будь-яка доробка йде без тестового контуру, що повторює бойовий каталог і налаштування.
Друга точка відмови — дані. Ручне вивантаження каталогу та замовлень дає розсинхрон: частина товарів від'їжджає без атрибутів, у частини губляться зв'язки з категоріями, історія замовлень переноситься неповною. Покупець бачить порожню картку або замовлення без статусу — і йде до конкурента.
Третя — адреси. Якщо перенесення інтернет-магазину йде без карти редиректів, старі адреси товарів і розділів віддають 404, а накопичені посилання та позиції в пошуку обнуляються за лічені тижні. Відновлювати їх потім дорожче, ніж побудувати схему адрес заздалегідь.
План перенесення пов'язує ці частини в один порядок робіт: інвентаризація розширень, перенесення даних з перевіркою сходимості, карта адрес, тестовий контур на копії каталогу. Розбираємо, як це закривається по кроках.
Що дає перенесення на підтримувану платформу: ефект у цифрах
Перенесення з Magento 1 на актуальну гілку змінює не зовнішній вигляд, а поведінку системи під навантаженням.
На старій схемі каталог збирається з кількох шарів кешу, а будь-яка правка атрибута запускає повну переіндексацію: сторінка категорії з фільтрами відповідає все довше в міру зростання числа товарів і значень атрибутів.
Після перенесення вибірку обслуговує підготовлений шар, індекси перебудовуються частинами, і відгук каталогу на списках і фільтрах скорочується в кілька разів — при цьому він не деградує в міру зростання асортименту. Важкі комбінації фільтрів перестають бути вузьким місцем.
Окремо змінюється стійкість до сплесків: пік від розсилки або розпродажу раніше вибивав частину сторінок і кошик, тому що читання і запис конкурували за одні ресурси.
Тепер читання винесено на окремі вузли, запис іде через черги, і сплеск розтягується в часі, а не перетворюється на відмову.
Термін виведення змін теж скорочується: правка шаблону, налаштування або промо-блоку замість ручного вивантаження на сервер від'їжджає в продакшн одним проходом, а відкат до попередньої збірки повертає робочий стан без розбору файлів вручну.
Індексація, прогрів кешу і збірка статики йдуть за розкладом, тому частка ручних операцій падає — разом з класом відмов, коли оновлення стороннього модуля перезаписувало тему або ламало оформлення замовлення.
Варіанти міграції Magento 1 на 2: порівняння підходів
Вибір варіанта перенесення визначає не розмір каталогу, а допустиме вікно недоступності вітрини і обсяг кастомної логіки. Magento 1 і Magento 2 — різні ядро, структура бази і шар шаблонів, тому модулі та теми переносяться не копіюванням, а переписуванням під нову архітектуру. Звідси три робочі сценарії з різною ціною переходу.
| Варіант | Коли підходить | Вікно простою | Обмеження підходу |
|---|---|---|---|
| Одномоментне перенесення | Компактний каталог, мінімум доробок, простій на кілька годин прийнятний | Повне, до доби | Усе переноситься одним прогоном; помилки в атрибутах, посиланнях і правилах цін спливають уже на живій вітрині, відкат зачіпає весь масив даних |
| Поетапна міграція з паралельною вітриною | Великий каталог, замовлення і трафік ідуть безперервно | Майже нульове, простій тільки на фінальному перемиканні | Потрібна постійна синхронізація замовлень, клієнтів і залишків між системами; вдвічі більше перевірок і складніше звірка SEO-адрес |
| Перенесення тільки вітрини зі збереженням серверної частини | Логіка та інтеграції зав'язані на старе ядро, яке не можна зупиняти | Мінімальне, на перемикання фронту | Довго живуть дві системи: частина даних іде з нового шару, частина — зі старого ядра, будь-яка зміна зачіпає обидві сторони |
Плата за прискорення завжди переноситься в інше місце. На паралельній вітрині це вартість синхронізації та подвійного тестування, на одномоментній — ризик тривалого відновлення при збої.
Підхід фіксуємо після інвентаризації модулів і вимірювань навантаження на поточну систему, інакше вибір залишається теоретичним.
Етапи перенесення: аудит, схема даних, налаштування, перевірка
Перехід з Magento 1 на 2 — це не перевстановлення, а перенесення даних, від яких залежить робота магазину: каталогу з історією цін, замовлень за кілька років, клієнтів з адресами та знижками.
Відновити їх після втрати нічим, тому роботи йдуть по кроках, і кожен наступний починається після приймання попереднього.
- Аудит даних магазину. Інвентаризуємо каталог, набори та значення атрибутів, категорії, клієнтів, адресні книги, замовлення, правила цін і статичні сторінки: рахуємо обсяги, знаходимо дублі, биті посилання на зображення та дані, які переносити не потрібно.
- Схема відповідності сутностей. Зводимо таблицю «атрибут-джерело → атрибут-приймач» з типом значення, обов'язковістю та набором атрибута. Окремо описуємо статуси замовлень, групи клієнтів і типи адрес — розбіжності тут дають втрати при перенесенні.
- Налаштування середовища. Розгортаємо цільову платформу на актуальній гілці: мову, СУБД, пошуковий сервіс, кеш і черги повідомлень; налаштовуємо індексацію та роздільні контури для розробки і репетиції перенесення.
- Пробний прогін на копії. Переносимо дані на повну копію бази та медіафайлів, заміряємо час і ресурси, ловимо помилки типів і кодувань. Прогонів зазвичай два: після першого схема відповідності уточнюється.
- Звірка даних після перенесення. Порівнюємо кількість записів по кожній сутності, вибірково — ціни, залишки, історію замовлень, прив'язку адрес і зображень, перевіряємо редиректи старих посилань.
- Перемикання та супровід. Наздоганяємо приріст даних, змінюємо маршрутизацію, вмикаємо моніторинг, стежимо за індексацією та роботою кошика; перший час тримаємо попередню версію доступною для відкату.
Передані артефакти: конфігурації, схеми даних, регламенти
Здача міграції Magento 1 на 2 — це не тільки працюючий сайт, а й набір артефактів, за якими ваша команда далі веде проект без нас. Усе передаємо в репозиторій поруч з кодом: файли версіонуються, зміни проходять рев'ю, а не живуть у листуванні та пам'яті окремих людей.
Перелік узгоджуємо до старту робіт, щоб приймання йшло за списком, а не за відчуттями. Нижче — мінімум, який залишається у замовника після виведення старого сайту з експлуатації.
- Конфігурації контурів — параметри тестового і бойового середовища, змінні, порядок збірки: локальна копія проекту піднімається за інструкцією за один прогін.
- Карта перенесення даних — відповідність «джерело → призначення» для товарів, категорій, замовлень, клієнтів і відгуків, правила перетворення та поведінка при повторному запуску.
- Політики доступу та розподілу ролей — матриця прав у панелі управління, хто може змінювати каталог і вивантажувати дані, порядок видачі та відкликання доступів.
- Правила обробки адрес — карта постійних перенаправлень зі старих посилань, пріоритети при конфліктах, журнал битих адрес після перемикання.
- Регламент оновлень — гілки, вікна релізів, порядок застосування оновлень платформи та розширень, точки відкату до попереднього робочого стану.
- Інструкції для команди — розгортання, де дивитися журнали, як провести відкат, що робити при інциденті, плюс чек-ліст приймання за ключовими сценаріями.
Кейс перенесення: каталог і замовлення переїхали без втрати позицій
Магазин з каталогом близько 12 тисяч позицій та історією замовлень за кілька років працював на Magento 1 — торгувати потрібно було без зупинки, тому перенесення каталогу, клієнтів і замовлень готували заздалегідь, а перемикання вітрини робили в коротке вікно низького трафіку.
Що змінили
Каталог переносили через схему відповідності атрибутів: старі набори розклали за новими, а товарні зв'язки перезібрали за зовнішніми ідентифікаторами, а не за назвами — інакше комплекти та супутні позиції розпадалися.
Історію замовлень перенесли зі збереженням зв'язки «клієнт — замовлення — позиції», статуси та коментарі менеджерів залишилися читабельними в особистому кабінеті, а не перетворилися на архівний дамп.
Окремо займалися збереженням адрес сторінок: 96% карток і категорій залишили попередній вигляд, решту закрили постійним редиректом за картою відповідностей — обхід пошукових роботів не вперся в тупики, а накопичені зовнішні посилання продовжили вести на ті ж товари.
Метрики до і після
Відгук каталогу під піковим навантаженням скоротився з секунд до часток секунди: видача з фільтрами перестала «зависати» на перегортанні.
Оновлення асортименту з прайсу постачальника раніше займало години ручних правок на партію — тепер це одна операція імпорту з перевіркою розбіжностей.
У першу добу після перемикання вітрина відпрацювала піковий трафік без відмов кошика та оформлення, а розбіжностей між залишками та прийнятими замовленнями не зафіксували.
Що робити, якщо частину даних уже перенесено вручну?
Починати міграцію заново, якщо половина каталогу вже перенесена своїми силами, дорожче, ніж звести дві бази.
Спочатку фіксуємо джерело істини по кожному типу сутностей: каталог і контент ведемо в новій системі, замовлення та історія клієнтів до моменту перемикання залишаються в старій.
Дублі шукаємо не за внутрішніми ідентифікаторами — в Magento 1 і Magento 2 вони між собою не пов'язані, — а за природними ключами: артикул, URL-ключ, прив'язка до постачальника.
За ними будується карта відповідності «старий ідентифікатор — новий», і вона ж стає робочою для всього подальшого довантаження даних.
Складніше зі зв'язками товарів і категорій. При ручному перенесенні позиція потрапляє в каталог, але втрачає прив'язку до наборів атрибутів, значення довідників і зображення: товар у базі є, а в фільтрах і на вітрині його немає. Ці зв'язки відновлюємо за картою відповідності, а не повторним заповненням вручну.
Замовлення перехідного періоду — окремий ризик. Долити їх списком не можна: ламається наскрізна нумерація, історія статусів і зв'язок з акаунтами покупців.
Тому зріз береться на момент перемикання і переноситься інкрементально, з дедуплікацією за номером замовлення та датою оформлення.
Довантаження даних робиться ідемпотентним: повторний запуск не створює копій і не задвоює залишки. Підсумок перевіряємо звіркою — число позицій, частка товарів без категорії, замовлення, що залишилися без прив'язки до клієнта. Розбіжності в частковому перенесенні видно до запуску, а не після.
Сумісність розширень, інтеграцій і адрес сторінок
Перед стартом замовник зазвичай побоюється не за дані, а за три речі: розширення, які в новій гілці платформи не працюють, інтеграції зі складом і оплатою та адреси сторінок, накопичені пошуковим трафіком.
Порядок робіт тут зворотний звичному: спочатку інвентаризація модулів і карта адрес, потім перенесення контенту — інакше каталог і розділи доведеться переробляти двічі.
Перенесення з Magento 1 на актуальну гілку другої версії ведемо за функціональністю, а не за назвами модулів: для кожного розширення фіксуємо, яке завдання воно закриває, яка частка сценаріїв реально використовується і чи є готова заміна.
Решту закриваємо доробкою через штатний механізм розширення або окремим модулем, щоб оновлення платформи не ламали логіку.
У розширення немає аналога під нову гілку — що тоді?
Дивимося, яка частина функціональності потрібна на практиці: часто з модуля використовуються один-два сценарії з десяти, і вони закриваються доробкою через штатний механізм перехоплення без правки ядра.
Якщо логіка глибша, пишемо свій модуль з покриттям тестами — він переноситься разом з платформою і не блокує оновлення.
Як переживають перенесення інтеграції зі складом і оплатою?
Обмін виносимо в окремий шар: платформа звертається до нього через штатні інтерфейси, зовнішні системи — через програмний інтерфейс обміну.
Замовлення та залишки синхронізуємо із захистом від повторної обробки, журналом і повторними відправками, щоб збій на одній стороні не давав подвійних списань. До перемикання трафіку обидві сторони проганяємо в тестовому контурі на копії даних.
Чи збережуться адреси сторінок і структура розділів?
Знімаємо карту адрес старого сайту, зіставляємо один до одного з новою структурою і віддаємо постійними перенаправленнями — без ланцюжків з кількох переходів. Категорії, фільтри, розбивка на сторінки та карта сайту отримують окремі правила.
Після перемикання звіряємо вивантаження з панелі вебмайстра: пошуковик повинен бачити нові адреси, а не помилки.
Обговоримо задачу: з чого починається перенесення магазину
Обговорення задачі починається не з оцінки, а з інвентаризації: скільки в магазині товарів, атрибутів і варіантів, які розширення та правки в ядрі тримають логіку продажів, як влаштовані інтеграції.
Без цих вступних оцінка обсягу робіт перетворюється на здогад, а план перенесення ламається на першому ж нестандартному модулі — тому розмову про перенесення з Magento 1 на актуальну гілку ведемо в площині фактів.
Що потрібно підготувати до обговорення:
- вивантаження каталогу: число товарів, категорій, атрибутів і варіантів;
- список розширень, тем і доробок ядра — з позначкою, що критично для продажів;
- інтеграції: склад, облікова система, служби доставки, платіжні шлюзи, розсилки;
- структуру адрес і правила їх формування — база для карти редиректів;
- звіт по трафіку та точках входу з пошуку за останній рік;
- доступи до серверів, репозиторіїв і панелей, обмеження по вікну перенесення;
- процеси, які не можна зупиняти: замовлення, вивантаження прайсів, залишки.
На виході першого етапу ви отримуєте план перенесення з розбивкою по роботах, карту даних і адрес, перелік ризиків і порядок перевірок. Якщо частина даних недоступна, позначте це на старті — уточнимо склад вступних і повернемося з оцінкою обсягу робіт. Далі узгодимо терміни та склад команди і почнемо з пробного перенесення на тестовий контур.
