Ви використовуєте Magento 1, але його підтримка завершена — кожен день роботи на цій платформі підвищує ризики злому, втрати даних і штрафів PCI DSS. Переїзд на Magento 2 — не оновлення, а повна перезбірка магазину: різні архітектури (Zend Framework 1 vs Symfony), різні формати даних, різні системи розширень. На відміну від застарілої платформи, Magento 2 заснований на компонентах Symfony та сучасному PHP, що безпосередньо впливає на продуктивність і безпеку (див. Magento). Без глибокого аудиту та поетапного плану ви ризикуєте втратити до 30% функціоналу. Наша команда проведе міграцію під ключ зі збереженням усіх бізнес-процесів, SEO-позицій та клієнтської бази.
Що переноситься, а що — ні
Офіційний інструмент Data Migration Tool переносить стандартні сутності, але кастомні таблиці та весь код вимагають ручної роботи.
| Компонент |
Статус |
| Товари, категорії, атрибути |
Переносяться через Data Migration Tool |
| Клієнти та паролі |
Клієнти переносяться, паролі — ні (алгоритм хешування змінився) |
| Замовлення та історія замовлень |
Переносяться |
| CMS-сторінки та блоки |
Переносяться |
| Теми (шаблони) |
Не переносяться — Magento 2 використовує PHTML + Knockout.js + LESS |
| Розширення |
Не переносяться — Magento 2 API несумісний |
| Кастомні таблиці БД |
Вимагають ручного перенесення |
| URL-редиректи |
Переносяться з застереженнями |
Типові помилки при міграції
- Пропуск кастомних атрибутів продукту.
- Неправильний маппінг customer_group.
- Втрата посилань на CMS-сторінки через змінені ідентифікатори.
- Невраховані 301 редиректи для старих URL.
Чому не можна просто оновити Magento 1?
Magento 1 і 2 — різні платформи. Оновлення (upgrade) неможливе, необхідно мігрувати. В M1 стара архітектура, заснована на Zend Framework 1, тоді як M2 побудований на Symfony та сучасному PHP. Через це будь-яке розширення або кастомізація потребують переписування. Ми бачили проєкти, де після «швидкої» міграції втрачали 30% функціоналу — цього можна уникнути з правильним підходом.
Як перенести кастомні розширення?
Data Migration Tool не знає про ваші модулі. Для кожного розширення потрібно знайти аналог для M2 або замовити портування. Наприклад, популярне розширення для створення резервних копій в M1 (AheadWorks) має пряму заміну Amasty в M2. Але унікальні модулі переписуються з нуля під архітектуру Magento 2. На одному з проєктів ми перенесли 34 розширення, з них 25 потребували повного рерайту. Термін збільшився на 1.5 місяця, але всі функції зберегли.
Як перенести паролі клієнтів?
Magento 1 використовує MD5, Magento 2 — bcrypt. Паролі не конвертуються напряму. Ми застосовуємо lazy migration: при першому вході перевіряємо старий MD5-хеш і перешифровуємо в bcrypt. Клієнти не помічають зміни, але паролі стають безпечними.
// Plugin для CustomerAuthenticationService
public function aroundAuthenticate($subject, callable $proceed, $username, $password)
{
try {
return $proceed($username, $password);
} catch (AuthenticationException $e) {
$customer = $this->customerRepository->get($username);
$legacyHash = md5($password);
if (hash_equals($customer->getLegacyPasswordHash(), $legacyHash)) {
$this->customerRepository->save(
$customer->setPasswordHash($this->encryptor->getHash($password, true))
);
return $customer;
}
throw $e;
}
}
Як виглядає міграція по кроках
- Аудит Magento 1 — інвентаризація розширень, оцінка сумісності.
- Встановлення Magento 2 та Data Migration Tool — розгортання чистої платформи.
- Налаштування маппінгу та міграція даних — поетапне перенесення через
migrate:settings, migrate:data, migrate:delta.
- Перенесення кастомних таблиць — написання PHP-скриптів для ручної синхронізації.
- Вирішення проблеми паролів — lazy migration через плагін аутентифікації.
- Налаштування SEO-редиректів — генерація 301 редиректів для старої URL-структури.
Порівняння підходів до міграції
| Підхід |
Терміни |
Складність |
Ризики |
| Самостійна міграція |
1–6 міс. |
Висока |
Втрата даних, помилки SEO |
| Міграція через нас |
2–4 міс. |
Низька |
Мінімальні |
Magento 2 швидший за Magento 1 в 2–3 рази за показниками TTFB і LCP завдяки сучасному фреймворку та вбудованому кешуванню. Витрати на самостійну міграцію можуть сягати значних сум з урахуванням простоїв і помилок, тоді як наша вартість міграції розраховується індивідуально залежно від обсягу робіт.
Що входить у роботу
- Повний аудит поточного магазину
- Міграція даних (каталог, замовлення, клієнти)
- Портування або заміна розширень
- Розробка нової теми під M2
- Налаштування 301 редиректів
- Документація по новій системі
- Навчання вашої команди
- 30 днів пост-релізної підтримки
Цей проєкт не про встановлення плагіна, а про переїзд цілого магазину. Наш досвід більше 50 успішних міграцій. Ми гарантуємо збереженість даних і працездатність. Замовте безкоштовну оцінку вашого проєкту — ми підготуємо план і терміни. Свяжіться з нами для консультації.
Редизайн та міграція сайту: зміна 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. Ось типові поломки:
| Проблема |
Причина |
Рішення |
| Дубльований контент |
Новий сайт відкривається паралельно зі старим |
Вимкнути індексацію dev-версії, налаштувати canonical |
| Втрата метаданих |
Title і description залишилися в старій CMS |
Експорт через API, масовий імпорт з перевіркою |
| Зміна canonical |
Пагінація та фільтри скинулися |
Зафіксувати до розробки, впровадити в шаблон |
| Швидкість просіла |
Важкі секції, неоптимізовані зображення |
Оптимізувати LCP, CLS, TTFB до запуску |
Як відновити трафік після невдалої міграції?
Якщо трафік впав — дійте негайно:
- Краул нового сайту на 404 та порівняння з передміграційним списком URL.
- Створення редиректів для всіх втрачених сторінок з трафіком >0.
- Перевірка структурованих даних та мета-тегів на тестовій вибірці.
- Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
- Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).
У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.
Як підготувати сайт до міграції: що не можна пропустити?
До початку розробки нового сайту потрібно:
- Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
- Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
- Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
- Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
- Зберегти Core Web Vitals з Search Console за попередні 90 днів.
Таблиця для фіксації:
| Етап аудиту |
Інструмент |
Критичність |
| Збір URL |
Screaming Frog + GSC |
Висока |
| Трафік за сторінками |
Google Analytics / Search Console |
Висока |
| Зовнішні посилання |
Ahrefs / Majestic |
Середня |
| Позиції |
Яндекс.Wordstat / Serpstat |
Середня |
| Core Web Vitals |
GSC CrUX |
Висока |
Зв'яжіться з нами для детального передміграційного аудиту — ми допоможемо виявити всі ризики та скласти план дій.
Мапінг 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) з ручною перевіркою проблемних сторінок.
| CMS |
Інструменти міграції |
Складність |
Ризики |
| WordPress |
WP All Export, WP-CLI, REST API |
Середня |
Shortcodes, meta fields |
| 1С-Бітрікс |
Bitrix API, SQL-експорт |
Висока |
Складна структура, властивості інфоблоків |
| Joomla |
J2XML, пряме вивантаження з БД |
Висока |
Застарілі розширення |
| Tilda/Readymag |
Експорт через API (обмежений) |
Середня |
Немає повного доступу до контенту |
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%+ — негайний аудит редиректів та порівняння з передміграційним краулом.
Чек-лист на запуск (спойлер)
- [ ] Всі 301 редиректи працюють і не утворюють ланцюжків
- [ ] Sitemap відправлений в GSC та Яндекс.Вебмайстер
- [ ] Прописані canonical на всіх сторінках
- [ ] Перевірено відображення Open Graph / Twitter Card
- [ ] Скориговані robots.txt та мета-теги noindex
- [ ] Core Web Vitals в зеленій зоні (LCP <2.5s, CLS <0.1, INP <200ms)
Що входить в роботу
Результати, які ви отримуєте:
- План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
- Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
- Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
- Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
- Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
- Моніторинг Coverage в Search Console з повідомленнями про помилки.
- Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.
Терміни та орієнтири
- Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
- Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
- Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.
Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.
Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.