Міграція OpenCart 3 на 4: перенесення даних, шаблонів та розширень

Міграція OpenCart 3 на 4 — не оновлення, а повноцінна перебудова проєкту. Ми стикалися з проєктами, де кастомні розширення та нестандартні шаблони перетворювали процес на головоломку. Наш досвід показує, що без детального плану та тестування можна втратити дані та клієнтів. Ми працюємо на ринку понад 5 років і виконали 50+ міграцій OpenCart, тому знаємо кожну пастку. Розберемо, як перенести дані, адаптувати код і зберегти продуктивність.

Чому міграція OpenCart 3 → 4 — це не просто оновлення?

OpenCart 4 — це повністю перероблена платформа. Потрібен PHP 8.0+, шаблони переїхали з PHP на Twig, а система розширень OCMOD замінена на Events System. Пряме оновлення неможливе — потрібна міграція даних і повна переробка кастомного коду. Згідно з офіційною документацією OpenCart, перехід потребує повного аудиту та тестування.

Які технічні складнощі ми вирішуємо?

• Несумісність PHP. OC3 працював на PHP 7.x, OC4 потребує 8.0+. Застаріле оточення — перша причина збоїв. Ми перевіряємо сервер і оновлюємо оточення.
• Шаблони PHP → Twig. Усі файли .tpl.php потрібно переписати на .twig. Twig працює швидше за рахунок компіляції шаблонів у PHP-код. Це дає виграш у швидкості завантаження сторінок до 40%.
• OCMOD → Events. Модифікація ядра через патчінг файлів замінена на систему подій. Розширення переписуються без зміни вихідників, що спрощує підтримку.
• Зміна Storage API. Структура папки storage та робота з файлами повністю перероблені. Потрібно переналаштувати шляхи.

Кожна з цих проблем потребує окремого підходу. На аудиті ми визначаємо точний обсяг робіт і ризики.

Як ми проводимо міграцію: реальний кейс

Кожен проєкт унікальний, але є перевірений сценарій. Нещодавно перенесли магазин автозапчастин з 5000 товарів, власним модулем уцінених товарів та інтеграцією з 1С. Спочатку аудит — виявили 12 кастомних розширень, 3 з яких потребували повної переробки. Потім бекап, перенесення даних через SQL, адаптація шаблонів за 2 тижні, тестування на staging-сервері та запуск. Результат: швидкість завантаження сторінок зросла на 40% завдяки Twig і PHP 8. Клієнт не помітив простою — запуск пройшов безболісно.

Адаптація розширень під Events System

Замість патчінгу файлів через OCMOD ми використовуємо події. Кожне розширення переписуємо у вигляді класу-обробника подій. Приклад: виведення кастомного бейджа на сторінці товару:

class ExtensionMyExtensionEventProductList {
    public function index(&$route, &$data): void {
        foreach ($data['products'] as &$product) {
            $product['custom_badge'] = 'Акція';
        }
    }
}

Такий підхід виключає конфлікти між розширеннями та спрощує оновлення ядра.

Які технічні зміни відбулися в OpenCart 4?

Twig-шаблони працюють у 2 рази швидше за PHP-шаблони завдяки компіляції, а Events System робить розширення безпечнішими та легшими в підтримці. Детальніше про Twig читайте в документації Twig.

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

• Повний аудит поточного магазину з детальним звітом.
• Експорт і трансформація даних (товари, замовлення, клієнти, налаштування).
• Адаптація шаблонів і всіх розширень під Twig та Events System.
• Налаштування нового Storage API та перенесення файлів.
• Тестування на staging-сервері з перевіркою всіх ключових сценаріїв.
• Документація щодо змін і навчання команди.
• Місяць технічної підтримки після запуску.

Процес і терміни

1. Аудит поточного магазину (розширення, налаштування, обсяг даних).
2. Підготовка оточення (PHP 8.0+, сервер, staging).
3. Експорт даних та їх трансформація під OC4.
4. Адаптація шаблонів і розширень під Twig та Events.
5. Імпорт і тестування на staging-сервері.
6. Запуск і моніторинг.

Гарантії та підтримка

• Повний бекап та його верифікація.
• Перенесення товарів, замовлень, клієнтів та всіх налаштувань.
• Адаптація шаблонів і всіх розширень.
• Налаштування нового Storage API.
• Тестування всіх ключових сценаріїв (кошик, оформлення, особистий кабінет).
• Документація щодо змін.
• Місяць технічної підтримки після запуску.

Типові помилки при міграції: ігнорування несумісності PHP-розширень, пропуск тестування платіжних шлюзів, втрата зв'язку зображень при неправильному rsync. Ми гарантуємо збереження даних і безперебійну роботу.

У вас складний проєкт? Зв'яжіться з нами для аудиту — оцінимо обсяг і терміни. Або залиште заявку на консультацію — обговоримо деталі.

Редизайн та міграція сайту: зміна 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 тижні.

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

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