Запись

Как обновить OpenCart 1.5, 2 или 3 до OpenCart 4 с сохранением данных и SEO

Полная инструкция по миграции интернет-магазина на OpenCart 4. Пошагово разбираю перенос товаров, категорий, клиентов, паролей, заказов, истории, скидок, изображений и SEO URL, финальную синхронизацию и проверку магазина перед запуском.

Обновление OpenCart 1.5, 2.x или 3.x до OpenCart 4 — это не только замена файлов движка. Для старых магазинов основной объем работы приходится на перенос базы данных, покупателей, заказов, товаров, изображений, SEO URL, модулей и индивидуальных доработок. При неправильной последовательности можно получить магазин, который внешне открывается, но теряет старые заказы, не авторизует клиентов, неправильно считает скидки или возвращает 404 по адресам товаров.

В этой инструкции разобран весь процесс перехода на OpenCart 4: от выбора способа обновления и создания резервной копии до пошаговой миграции каждой важной группы данных и финального переключения рабочего магазина.

На момент актуализации материала в сентябре 2026 года актуальный стабильный релиз ветки OpenCart 4 — 4.1.0.4. Перед реальной миграцией всегда дополнительно проверяйте, не вышла ли более свежая версия и поддерживают ли ее необходимые вам расширения.

Какой способ перехода на OpenCart 4 выбрать

Подход зависит прежде всего от исходной версии и количества доработок.

Исходная версия	Рекомендуемый сценарий	Комментарий
OpenCart 1.5.x	Чистая OpenCart 4 + миграция данных	Прямое обновление поверх старого ядра использовать не стоит
OpenCart 2.x	Чаще чистая OpenCart 4 + миграция	Последовательность 2 → 3 → 4 возможна, но добавляет лишние этапы и риски
OpenCart 3.x	Штатный upgrade или чистая миграция	Для 3.x существует официальный путь обновления до 4.x, но модули и тема проверяются отдельно

Для сильно доработанного проекта даже OpenCart 3 зачастую проще перенести на чистую OpenCart 4. Это позволяет не тащить за собой устаревшие OCMOD, старые таблицы расширений, изменения ядра и накопившийся технический долг.

Почему нельзя просто скопировать новую версию поверх старой

За годы развития OpenCart менялись не только PHP-файлы. Изменилась структура таблиц, формат хранения отдельных полей, система расширений и логика работы каталога.

Например, в современной OpenCart 4.1 структура товаров уже отличается от старых веток: дополнительные идентификаторы товара обслуживаются отдельным механизмом кодов, а специальные цены объединены с системой скидок. В таблице SEO URL вместо старой пары query → keyword используется структура с отдельными key, value и keyword.

Поэтому задача миграции состоит не в копировании таблиц, а в преобразовании старой модели данных в новую.

Подготовка и резервная копия

Шаг 1. Зафиксируйте точную конфигурацию старого магазина

До любых изменений запишите:

точную версию OpenCart;
версию PHP;
версию MySQL или MariaDB;
префикс таблиц;
используемую тему;
языки;
валюты;
мультимагазины;
модули оплаты;
модули доставки;
SEO-модули;
VQMod и OCMOD;
cron-задачи;
интеграции с 1С, CRM, ERP и маркетплейсами;
самописные PHP-скрипты;
внешние API и вебхуки.

Шаг 2. Посчитайте основные сущности

Запишите количество товаров, категорий, производителей, клиентов и заказов. Это простая, но важная контрольная точка.

Например:

SELECT COUNT(*) FROM oc_product;
SELECT COUNT(*) FROM oc_category;
SELECT COUNT(*) FROM oc_customer;
SELECT COUNT(*) FROM oc_order;

Вместо oc_ используйте реальный префикс магазина.

Шаг 3. Сделайте резервную копию файлов

Сохраняйте весь магазин, а не только стандартные папки OpenCart. В архив должны попасть изображения, конфигурация, сторонние модули, VQMod, загрузки и любые нестандартные каталоги.

Шаг 4. Сделайте дамп базы

mysqldump -u USER -p DATABASE > opencart-backup.sql

Лучшей проверкой бэкапа является его реальное восстановление в отдельную базу. Размер SQL-файла не показывает, полная копия или нет.

Шаг 5. Создайте staging-среду

Все работы сначала проводятся на тестовой копии. Например:

stage.example.ru

Закройте ее от индексации и, по возможности, от постороннего доступа.

Переход с OpenCart 1.5 на OpenCart 4

OpenCart 1.5 нельзя рассматривать как версию, которую разумно напрямую обновлять поверх файлов до OpenCart 4. Для нее используйте чистую миграцию.

Создайте бэкап.
Установите чистую OpenCart 4.
Настройте сервер и основные параметры.
Подготовьте новую тему.
Установите аналоги необходимых модулей.
Создайте правила сопоставления старых и новых таблиц.
Перенесите справочники.
Перенесите каталог.
Перенесите клиентов.
Перенесите заказы.
Перенесите дополнительные сущности.
Перенесите SEO URL.
Проведите тестирование.
Выполните финальную синхронизацию.
Переключите рабочий сайт.

Переход с OpenCart 2.x на OpenCart 4

Для OpenCart 2 технически возможен путь через промежуточный OpenCart 3, но для большинства сильно доработанных магазинов это не дает преимуществ.

Сценарий 2 → 3 → 4 заставляет дважды менять структуру базы и дважды разбираться с совместимостью. Если конечная цель известна заранее, зачастую безопаснее сразу мигрировать данные в чистый OpenCart 4.

Особое внимание уделите старым .tpl-шаблонам и модулям OpenCart 2. Они не становятся совместимыми с OpenCart 4 автоматически.

Переход с OpenCart 3.x на OpenCart 4

Для OpenCart 3 существует официальный сценарий upgrade до OpenCart 4. В общих чертах он включает создание резервной копии, загрузку новой версии с сохранением конфигурационных и пользовательских данных и запуск upgrade через каталог /install.

Но перед реальным обновлением обязательно:

проверьте тему;
проверьте каждый модуль;
отключите несовместимые модификации;
проведите обновление на полной копии;
проверьте каталог, checkout и административную панель.

Если OpenCart 3 сильно изменен, чистая миграция все равно может оказаться надежнее.

Правильная последовательность миграции данных

Основная ошибка при ручном переносе — импортировать данные в произвольном порядке. В OpenCart сущности связаны друг с другом, поэтому сначала создаются объекты, на которые потом будут ссылаться остальные записи.

Практический порядок выглядит так:

Языки, магазины и валюты.
Группы покупателей.
Статусы товаров, заказов и возвратов.
Единицы веса и размеров, налоги и геозоны при необходимости.
Производители.
Группы атрибутов и атрибуты.
Опции и значения опций.
Фильтры.
Категории.
Товары.
Изображения.
Цены, акции, скидки и бонусные баллы.
SEO URL каталога.
Покупатели.
Адреса покупателей.
Wishlist, бонусы и баланс клиентов.
Заказы.
Товары и опции внутри заказов.
Итоги заказов.
История статусов.
Отзывы.
Возвраты.
Купоны и маркетинговые данные.
Информационные страницы.
Данные сторонних модулей.

Нужно ли сохранять старые ID

При чистой миграции есть две стратегии.

Вариант 1. Сохранять существующие ID

Для пустой новой базы это часто самый удобный вариант. Если product_id=1542 остается 1542, вам не приходится пересчитывать десятки связанных таблиц.

То же относится к:

category_id;
manufacturer_id;
customer_id;
order_id;
option_id;
attribute_id.

Но перед этим нужно удалить или не импортировать демонстрационные данные, которые могут занимать те же ID.

Вариант 2. Создавать новые ID

Если сохранить старые идентификаторы невозможно, миграционный скрипт должен вести таблицу соответствий:

old_product_id 1542 → new_product_id 846;
old_customer_id 531 → new_customer_id 972;

После этого каждая связанная запись должна использовать новое значение.

Нельзя смешивать эти подходы. Если товары получили новые ID, а order_product продолжает ссылаться на старые, связи будут нарушены.

Где нельзя слепо сохранять ID

Языки, страны, регионы, валюты и статусы лучше сопоставлять по смыслу или стабильному коду, а не только по числовому ID. Например, order_status_id=5 в старой базе не гарантированно означает то же состояние в новой.

Перенос справочников

До товаров и заказов подготовьте все справочники, на которые они ссылаются.

Языки

Составьте соответствие старого language_id с новым. Если магазин одноязычный, задача простая. В мультиязычном проекте ошибка в language_id приведет к отсутствующим описаниям и SEO URL.

Валюты

Для истории заказов важно сохранить не только код валюты, но и значение курса, записанное непосредственно в заказе.

Статусы заказов

Создайте таблицу соответствий:

старый "Pending" → новый "Pending";
старый "Complete" → новый "Complete";
старый "Canceled" → новый "Canceled";

Сопоставляйте по смыслу, а не по ID.

Группы клиентов

Перенесите группы до самих покупателей, скидок и цен, поскольку эти сущности могут ссылаться на customer_group_id.

Пошаговый перенос каталога

Шаг 1. Производители

Перенесите производителя, изображение, порядок сортировки, привязку к магазинам и SEO URL.

Шаг 2. Атрибуты

Сначала перенесите группы атрибутов, затем сами атрибуты, после этого описания на всех языках.

Шаг 3. Опции

Порядок:

создать option;
перенести option_description;
создать option_value;
перенести option_value_description;
только потом создавать product_option и product_option_value.

Шаг 4. Категории

Для каждой категории перенесите:

parent_id;
image;
sort_order;
status;
описание;
meta title;
meta description;
привязку к магазинам;
SEO URL.

После этого пересоберите и проверьте category_path. Эта таблица описывает полный путь от корневой категории до вложенной.

Например, для:

Электроника → Телефоны → Смартфоны

у категории «Смартфоны» должны существовать связи со всеми уровнями пути.

Шаг 5. Основные поля товара

Перенесите:

model;
quantity;
stock_status_id;
image;
manufacturer_id;
shipping;
price;
tax_class_id;
date_available;
weight;
length, width и height;
minimum;
subtract;
sort_order;
status.

При этом не пытайтесь вставлять в OpenCart 4 все старые поля один в один. Некоторые поля старых версий в новой структуре отсутствуют или хранятся иначе.

Шаг 6. SKU, UPC, EAN, JAN, ISBN и MPN

В актуальной OpenCart 4.1 эти идентификаторы обслуживаются через отдельный механизм кодов товара. Поэтому старые значения из полей sku, upc, ean, jan, isbn и mpn нужно преобразовать в структуру, которую использует OpenCart 4, а не просто пытаться добавить старые колонки в новую таблицу product.

После импорта обязательно протестируйте поиск по SKU и другим идентификаторам.

Шаг 7. Описания товаров

Перенесите для каждого языка:

name;
description;
tag;
meta_title;
meta_description;
meta_keyword, если используется.

Шаг 8. Привязки к категориям

Перенесите product_to_category, используя новые ID категорий и товаров либо сохраненные старые ID.

Шаг 9. Дополнительные изображения

Сначала скопируйте физические файлы, затем перенесите записи product_image.

После миграции проверьте:

основное изображение;
галерею;
изображения опций;
категории;
производителей;
баннеры.

Шаг 10. Характеристики

Перенесите product_attribute только после того, как созданы соответствующие товары и атрибуты.

Шаг 11. Опции товара

Перенос выполняется в два уровня:

product_option;
product_option_value.

Если ID были изменены, необходимо одновременно заменить product_id, option_id и option_value_id.

Шаг 12. Скидки и специальные цены

Это важное отличие OpenCart 4. В текущей структуре специальные цены и обычные скидки обслуживаются единой таблицей product_discount, где есть признак специальной цены.

Поэтому старую product_special нельзя просто импортировать как отдельную таблицу: данные нужно преобразовать в новый формат.

Проверьте:

customer_group_id;
priority;
price;
date_start;
date_end;
признак special.

Шаг 13. Related products, downloads, rewards и filters

Если они используются, переносите после основных товаров, потому что эти записи ссылаются на уже существующие product_id.

Шаг 14. Проверка каталога

После импорта проверьте как минимум:

общее количество товаров;
активные и отключенные товары;
категории;
остатки;
цены;
скидки;
SKU/EAN;
опции;
изображения;
характеристики;
SEO URL.

Пошаговый перенос покупателей

В OpenCart важно различать customer и user. Customer — покупатель магазина. User — пользователь административной панели.

Обычно переносить нужно покупателей, а администраторов безопаснее создать заново.

Шаг 1. Перенесите группы покупателей

Сначала создайте customer_group и описания групп.

Шаг 2. Перенесите основные записи customer

Для каждого покупателя нужны как минимум:

customer_group_id;
store_id;
language_id;
firstname;
lastname;
email;
telephone;
password;
custom_field;
newsletter;
status;
date_added.

Нормализуйте email: удалите случайные пробелы и проверьте дубликаты. Два клиента с одинаковым email могут создавать проблемы при авторизации.

Шаг 3. Перенесите адреса

После создания клиента перенесите его записи address:

firstname;
lastname;
company;
address_1;
address_2;
city;
postcode;
country_id;
zone_id;
custom_field.

Если customer_id изменились, обязательно используйте таблицу соответствий.

Шаг 4. Что делать с паролями

В OpenCart 4 новые пароли сохраняются современным password_hash(). При этом код авторизации содержит механизмы совместимости с некоторыми старыми хэшами: после успешного входа старый пароль может быть автоматически перехэширован в современный формат.

Но при чистой установке OpenCart 4 таблица customer уже не содержит старое стандартное поле salt. Поэтому для старых salted SHA1-паролей из OpenCart 1.5–3 нельзя просто скопировать только значение password и ожидать гарантированную авторизацию.

Есть два нормальных сценария:

Совместимая миграция паролей. Миграционный код временно сохраняет необходимую информацию старого алгоритма и дает OpenCart возможность перехэшировать пароль после первого успешного входа.
Сброс паролей. Покупатели переносятся без возможности входа со старым паролем и при первом входе используют восстановление пароля.

Для официального upgrade OpenCart 3 → 4 лучше не вмешиваться в password/salt вручную, а позволить штатной процедуре преобразовать установку.

Обязательно проверьте реальные учетные записи с разными годами регистрации. В старом магазине могли одновременно присутствовать пароли, созданные разными версиями OpenCart.

Шаг 5. Перенесите бонусные баллы

Если используется программа лояльности, переносите не только итоговое число баллов, а историю customer_reward. Так в личном кабинете сохраняется понятное происхождение начислений.

Шаг 6. Перенесите баланс клиента

Если магазин использует внутренний кредит или баланс, перенесите customer_transaction с корректной связью customer_id и order_id.

Шаг 7. Wishlist

Переносите список желаний только после переноса товаров, иначе product_id не будут существовать в новой базе.

Шаг 8. Affiliate

Если использовалась партнерская программа OpenCart, отдельно мигрируйте affiliate-данные и tracking.

Что обычно не нужно переносить

В новую систему не стоит тащить временные данные:

активные PHP-сессии;
customer_online;
старые login attempts;
временные tokens;
старый кеш.

Эти данные OpenCart создаст заново.

Пользователи административной панели

Для чистой миграции безопаснее создать новых пользователей admin вручную и заново назначить права. Структура разрешений и набор маршрутов между версиями менялись, поэтому копирование старой user_group целиком может дать лишние или отсутствующие разрешения.

Пошаговый перенос заказов

Перенос заказов — один из самых ответственных этапов. Заказ в OpenCart состоит сразу из нескольких таблиц. Копирования одной order недостаточно.

В стандартном сценарии нужно обработать как минимум:

order;
order_product;
order_option;
order_total;
order_history;
связанные данные клиента;
при необходимости подписки и дополнительные таблицы расширений.

Шаг 1. Сопоставьте статусы заказов

До переноса истории определите соответствие каждого старого статуса новому.

Например:

1 Pending → 1 Pending;
5 Complete → 5 Complete;
7 Canceled → 7 Canceled;

Цифры приведены только как пример. Реальные ID нужно проверять в конкретных базах.

Шаг 2. Сопоставьте customer_id

Заказ может принадлежать зарегистрированному пользователю либо гостю.

Если customer_id был изменен при миграции, используйте карту old_customer_id → new_customer_id.

Для гостевых заказов customer_id обычно остается равным нулю.

Шаг 3. Перенесите основную запись заказа

Необходимо сохранить исторические данные такими, какими они были в момент покупки:

order_id;
invoice_no и invoice_prefix;
store_id;
store_name;
store_url;
customer_id;
customer_group_id;
firstname и lastname;
email;
telephone;
платежный адрес;
адрес доставки;
комментарий;
total;
order_status_id;
currency_code;
currency_value;
language_code;
date_added;
date_modified.

Не подменяйте старый адрес текущим адресом клиента. Заказ является историческим снимком: если покупатель позже переехал, старый заказ должен продолжать показывать адрес, на который он был доставлен.

Шаг 4. Преобразуйте payment_method и shipping_method

Это особенно важно при переходе со старых версий.

В OpenCart 4 методы оплаты и доставки в заказе хранятся как структурированные данные, сериализованные в JSON. В коде OpenCart используются структуры наподобие:

{"name":"Payment Name","code":"extension/payment.method"}

и аналогично для доставки.

В старых OpenCart часто существовали отдельные строковые поля payment_method, payment_code, shipping_method и shipping_code. При миграции их нужно преобразовать в структуру OpenCart 4.

Не оставляйте старое строковое значение там, где OpenCart 4 ожидает JSON. Иначе просмотр или печать старого заказа может работать некорректно.

Шаг 5. Перенесите товары заказа

Для каждого order_id перенесите строки order_product:

product_id;
name;
model;
quantity;
price;
total;
tax;
reward.

Важно: название и цена в order_product — исторические. Не пересчитывайте старый заказ по текущей цене карточки товара.

Шаг 6. Перенесите опции заказа

Для каждого товара заказа перенесите order_option:

order_id;
order_product_id;
product_option_id;
product_option_value_id;
name;
value;
type.

Если product_option_id изменился, он должен быть пересчитан. При этом исторические поля name и value необходимо сохранить в любом случае.

Шаг 7. Перенесите итоги заказа

Таблица order_total содержит не только итоговую сумму. В ней могут находиться:

subtotal;
shipping;
tax;
coupon;
reward;
total;
другие компоненты сторонних расширений.

В OpenCart 4 структура order_total отличается от старых поколений и содержит отдельные поля extension и code. Поэтому старые записи нужно преобразовать.

После миграции сумма компонентов должна логически совпадать с полем total основного заказа.

Шаг 8. Перенесите историю заказа

Для каждого заказа сохраните:

order_status_id;
notify;
comment;
date_added.

Это позволит видеть в админке реальную последовательность: создан → оплачен → отправлен → завершен.

Шаг 9. Не пересылайте старые уведомления

Импорт истории не должен повторно отправлять email клиентам. Миграционный скрипт должен записывать исторические данные напрямую либо использовать специальный режим без уведомлений.

Шаг 10. Подписки и recurring

Если магазин использовал recurring payments, этот блок требует отдельной миграции. В OpenCart 4 используется новая система subscription и order_subscription. Простое копирование старых recurring-таблиц не подойдет.

Также отдельно проверьте активные подписки у самого платежного провайдера: Stripe, PayPal или другая система может продолжать списания независимо от базы OpenCart.

Шаг 11. Проверьте несколько типов старых заказов

Недостаточно открыть один заказ. Проверьте:

гостевой заказ;
заказ зарегистрированного клиента;
заказ со скидкой;
заказ с купоном;
заказ с доставкой;
цифровой заказ без доставки;
заказ с несколькими опциями;
заказ в другой валюте;
возвращенный или отмененный заказ;
старый заказ с удаленным товаром.

Шаг 12. Проверьте invoice и печать заказа

Откройте старый заказ в административной панели и сформируйте счет или печатную форму. Это быстро выявляет проблемы с адресами, payment_method, shipping_method и order_total.

Перенос остальных данных

Отзывы

Переносите отзывы после товаров и покупателей. Проверьте product_id, customer_id, author, rating, status и даты.

Возвраты

Перенос возвратов выполняется после заказов. Нужно сопоставить:

order_id;
customer_id;
product_id;
return_reason_id;
return_action_id;
return_status_id.

Также переносится история возврата, если она использовалась в старой версии.

Купоны

Перенесите основные купоны, затем ограничения по категориям и товарам. После этого проверьте количество использований, если оно влияет на возможность дальнейшего применения.

Сертификаты

Если подарочные сертификаты реализованы сторонним расширением либо отличающимся механизмом, их нельзя считать частью универсальной миграции. Нужно анализировать таблицы конкретного модуля.

Информационные страницы

Перенесите:

title;
description;
meta_title;
meta_description;
sort_order;
status;
store;
SEO URL.

Downloads

Если продаются цифровые товары, переносите не только записи в базе, но и физические файлы. Проверьте права доступа к каталогу downloads/storage.

Данные сторонних модулей

Для каждого расширения составьте отдельную таблицу:

Модуль	Собственные таблицы	Есть версия для OC4	Нужно переносить данные
Фильтр	Да/нет	Да/нет	Да/нет
1С	Да/нет	Да/нет	Да/нет
Бонусная система	Да/нет	Да/нет	Да/нет

Так становится понятно, что не покрывает стандартная база OpenCart.

Пошаговый перенос SEO URL

При обновлении CMS не нужно автоматически менять адреса страниц. Для SEO наиболее безопасный вариант — сохранить существующие URL.

OpenCart 1.5 и 2.x

В старых версиях обычно используется url_alias с конструкцией:

query = product_id=123;
keyword = iphone-case;

OpenCart 4

В текущей OpenCart 4 таблица seo_url хранит отдельные:

store_id;
language_id;
key;
value;
keyword;
sort_order.

Для товара старое:

product_id=123 → iphone-case

преобразуется по логике:

key=product_id;
value=123;
keyword=iphone-case;

Аналогично обрабатываются категории, производители и информационные страницы.

Если ID изменились

Если старый товар 123 получил новый product_id 875, SEO URL должен ссылаться уже на 875, но keyword можно и желательно оставить прежним:

key=product_id;
value=875;
keyword=iphone-case;

Когда нужен 301

301 нужен, только если сохранить старый URL невозможно.

/old-product → /new-product

Не создавайте цепочки:

/a → /b → /c

Лучше:

/a → /c

Что проверить после переноса SEO

товар открывается по старому URL;
категория открывается;
производитель открывается;
information page открывается;
нет дублей keyword;
canonical правильный;
внутренние ссылки не ведут на старые технические маршруты;
robots.txt не блокирует сайт;
sitemap содержит актуальные URL.

Модули, OCMOD, VQMod и шаблон

VQMod

Старые XML VQMod не следует переносить автоматически. Сначала определите, какую функцию выполняет модификация, затем найдите современный модуль либо реализуйте изменение через механизм OpenCart 4.

OCMOD

OCMOD существует и в OpenCart 4, но XML от OpenCart 2 или 3 может искать код, которого в новом ядре уже нет. Поэтому каждый модификатор проверяется отдельно.

Events

Если функцию можно реализовать через Event без вмешательства в ядро, этот вариант обычно предпочтительнее прямого редактирования PHP-файлов.

Тема

OpenCart 1.5 и большинство OpenCart 2 используют .tpl. OpenCart 3 и 4 используют Twig, но даже Twig-тема OpenCart 3 не становится автоматически совместимой с 4.

При переносе дизайна нужно проверить:

header;
footer;
карточку товара;
категории;
поиск;
корзину;
checkout;
личный кабинет;
страницы информации;
мобильную версию.

Как выполнить финальную синхронизацию без потери новых заказов

Проблема любой долгой миграции в том, что рабочий магазин продолжает меняться.

Например, первую копию базы вы сделали 1 сентября, а запуск запланирован на 10 сентября. За это время появились новые клиенты и заказы.

Способ 1. Delta-синхронизация

Если миграционный скрипт это поддерживает, во второй проход переносите только новые и измененные данные после контрольной точки.

Обычно это:

новые order_id;
новые customer_id;
измененные остатки;
новые товары;
измененные цены.

Способ 2. Полностью повторить миграцию

Для старых и сложных магазинов это зачастую надежнее.

Отработать скрипт на staging.
Исправить все ошибки.
В день запуска включить maintenance.
Получить свежую копию рабочей базы.
Очистить тестовую целевую базу.
Повторно выполнить тот же полностью протестированный импорт.
Провести короткую контрольную проверку.
Переключить сайт.

Так вы не пытаетесь угадывать, какие записи изменились за несколько дней.

Полное тестирование после миграции

Каталог

товары открываются;
категории открываются;
поиск работает;
фильтр работает;
SKU/EAN находятся;
остатки правильные;
цены правильные;
специальные цены отображаются;
изображения работают;
опции выбираются.

Клиенты

старый клиент входит;
новый клиент регистрируется;
восстановление пароля работает;
адреса доступны;
wishlist сохранился;
бонусы и баланс корректны.

Заказы

старые заказы открываются;
invoice печатается;
статусы отображаются;
история отображается;
товары заказа совпадают;
итоговая сумма совпадает;
новый заказ создается;
email приходит;
статус нового заказа можно изменить.

Оплата

Для каждого активного способа оплаты проведите тестовую операцию либо sandbox-платеж. Проверяйте не только переход на платежную страницу, но и callback/webhook после оплаты.

Доставка

Проверьте разные регионы, вес, бесплатную доставку и нестандартные тарифы.

SEO

Возьмите заранее сохраненный список старых URL и автоматически проверьте ответы:

200;
301;
404;
500.

Все важные 404 нужно разобрать до открытия сайта поисковым роботам.

Интеграции

1С;
ERP;
CRM;
маркетплейсы;
Google Merchant;
аналитика;
email;
SMS;
онлайн-касса;
вебхуки;
cron.

SQL-проверки после переноса

После миграции полезно выполнить несколько простых SQL-проверок. Они помогают быстро найти записи, которые потеряли связи с основными сущностями.

Товары заказа, для которых отсутствует сам заказ:

SELECT COUNT(*)
FROM oc_order_product AS op
LEFT JOIN oc_order AS o
    ON o.order_id = op.order_id
WHERE o.order_id IS NULL;

В корректно перенесенной базе такой запрос обычно должен вернуть 0.

Адреса, связанные с несуществующими покупателями:

SELECT COUNT(*)
FROM oc_address AS a
LEFT JOIN oc_customer AS c
    ON c.customer_id = a.customer_id
WHERE c.customer_id IS NULL;

Если результат больше нуля, нужно определить, почему адреса потеряли связь с customer.

Связи товаров и категорий, в которых отсутствует товар или категория:

SELECT COUNT(*)
FROM oc_product_to_category AS pc
LEFT JOIN oc_product AS p
    ON p.product_id = pc.product_id
LEFT JOIN oc_category AS c
    ON c.category_id = pc.category_id
WHERE p.product_id IS NULL
   OR c.category_id IS NULL;

Опции заказа без соответствующего товара заказа:

SELECT COUNT(*)
FROM oc_order_option AS oo
LEFT JOIN oc_order_product AS op
    ON op.order_product_id = oo.order_product_id
WHERE op.order_product_id IS NULL;

История статусов без существующего заказа:

SELECT COUNT(*)
FROM oc_order_history AS oh
LEFT JOIN oc_order AS o
    ON o.order_id = oh.order_id
WHERE o.order_id IS NULL;

Характеристики, связанные с отсутствующим товаром:

SELECT COUNT(*)
FROM oc_product_attribute AS pa
LEFT JOIN oc_product AS p
    ON p.product_id = pa.product_id
WHERE p.product_id IS NULL;

Дополнительные изображения отсутствующих товаров:

SELECT COUNT(*)
FROM oc_product_image AS pi
LEFT JOIN oc_product AS p
    ON p.product_id = pi.product_id
WHERE p.product_id IS NULL;

Проверка дублирующихся email покупателей:

SELECT email, COUNT(*) AS total
FROM oc_customer
GROUP BY email
HAVING COUNT(*) > 1;

Дубликат email не всегда означает ошибку миграции: он мог существовать и в старой базе. Но такие записи стоит проверить до запуска авторизации покупателей.

Сравнение количества основных сущностей:

SELECT COUNT(*) AS products
FROM oc_product;

SELECT COUNT(*) AS categories
FROM oc_category;

SELECT COUNT(*) AS customers
FROM oc_customer;

SELECT COUNT(*) AS orders
FROM oc_order;

Полученные значения сравниваются с контрольными числами, сохраненными до начала миграции. Расхождения допустимы только тогда, когда их причина известна: например, вы сознательно не переносили тестовые заказы или удаленные товары.

Во всех примерах замените префикс oc_ на фактический префикс таблиц вашего магазина.

Проверка счетчиков AUTO_INCREMENT

Если ID переносились вручную, убедитесь, что следующее значение AUTO_INCREMENT больше максимального существующего ID.

Иначе первый новый заказ или пользователь после запуска может столкнуться с конфликтом ключа.

Не переносите кеш и сессии

После миграции не нужно копировать старые:

cache;
sessions;
compiled modifications;
temporary uploads.

OpenCart 4 должен создать их заново.

План отката

До переключения заранее определите, что делать, если после запуска обнаружится критическая ошибка.

Минимальный план

Сохранить старый магазин в полностью рабочем состоянии.
Не удалять старую базу.
Перед переключением сделать последний дамп.
Записать прежние DNS/IP и конфигурацию веб-сервера.
Определить максимальное время, после которого принимается решение об откате.

После запуска новой версии появляется важная проблема: в нее могут поступить новые заказы. Если затем просто включить старую базу, эти заказы потеряются. Поэтому перед откатом нужно экспортировать заказы, созданные уже после переключения, либо остановить оформление заказов до восстановления.

Запуск рабочего магазина

Включите maintenance на старом сайте.
Сделайте финальный бэкап.
Выполните финальную миграцию или delta sync.
Проверьте количество заказов и клиентов.
Проверьте старый URL товара.
Оформите контрольный заказ.
Переключите домен или document root.
Проверьте SSL.
Проверьте cron.
Проверьте webhook.
Отключите maintenance.
Проверьте реальный заказ.

Что проверять в первые дни после запуска

PHP error log;
OpenCart error log;
логи Nginx или Apache;
ошибки 404;
ошибки 500;
платежи;
заказы;
остатки;
интеграции;
индексацию;
органический трафик.

Старую версию магазина не удаляйте сразу. Закройте ее от публичного доступа и поисковых систем, но сохраните как источник для проверки спорных исторических данных.

Частые вопросы

Можно ли перейти с OpenCart 1.5 сразу на 4?

Да. Но это должна быть миграция на чистую OpenCart 4, а не копирование файлов поверх OpenCart 1.5.

Нужно ли сначала обновлять OpenCart 1.5 до 2, затем до 3 и только потом до 4?

Обычно нет. Это создает несколько промежуточных миграций вместо одной контролируемой.

Можно ли обновить OpenCart 2 сразу до 4?

Для сильно измененного магазина разумнее чистая установка OpenCart 4 с прямой миграцией данных. Последовательный вариант через OpenCart 3 используется только после тестирования.

Можно ли OpenCart 3 обновить штатно?

Да. Для 3.x существует официальный сценарий upgrade до OpenCart 4. Но тему и сторонние расширения необходимо проверять отдельно.

Можно ли просто импортировать старую базу в OpenCart 4?

Нет. Таблицы и поля между версиями отличаются. Нужна конвертация данных.

Сохранятся ли старые товары?

Да, если перенести основную запись и все связанные таблицы: descriptions, categories, images, attributes, options, prices и SEO.

Сохранятся ли заказы?

Да. Для этого необходимо перенести не только order, но и order_product, order_option, order_total и order_history.

Можно ли сохранить номера заказов?

Да, и для действующего магазина это обычно удобно. В чистой базе можно сохранить старые order_id, если нет конфликтов.

Сохранятся ли пароли клиентов?

Зависит от старой версии и формата хэша. OpenCart 4 умеет обрабатывать часть legacy-хэшей, но при чистой миграции salted-паролей требуется отдельная логика совместимости либо принудительное восстановление пароля.

Нужно ли переносить пользователей админки?

Обычно нет. Безопаснее создать новые admin-аккаунты и вручную настроить права.

Сохранятся ли SEO URL?

Да. Старые keyword можно перенести в новую структуру seo_url. Если ID сущностей меняются, меняется внутренняя привязка, но сам внешний URL можно оставить прежним.

Нужно ли делать 301 для всех страниц?

Нет. Если URL сохранен, редирект не нужен.

Что делать с product_special?

При миграции на актуальную OpenCart 4 данные специальных цен преобразуются в текущую структуру скидок, где предусмотрен отдельный признак специальной цены.

Что делать со SKU и EAN?

Перенести в современный механизм идентификаторов товара OpenCart 4, а не пытаться восстановить старую структуру таблицы product.

Как не потерять новые заказы во время миграции?

Выполнить финальную синхронизацию после перевода старого магазина в maintenance либо полностью повторить миграцию на свежем дампе уже протестированным скриптом.

Можно ли мигрировать без остановки магазина?

Основную часть — да. Но для финальной синхронизации обычно нужен небольшой период, когда записи на старом сайте прекращаются. Иначе невозможно гарантировать консистентность заказов, клиентов и остатков.

Можно ли гарантировать сохранение позиций?

Нет. Но риск снижается, если сохранить URL, контент, Title, Description, H1, canonical, внутренние ссылки и правильно настроить редиректы.

Итог

Полноценное обновление OpenCart до 4 — это работа не только с ядром CMS. Для OpenCart 1.5 и большинства OpenCart 2 правильнее говорить о миграции: создается чистая новая система, а затем в определенной последовательности переносятся справочники, категории, товары, изображения, цены, покупатели, адреса, заказы, история заказов, отзывы, возвраты, SEO URL и данные сторонних модулей.

OpenCart 3 можно обновлять штатным механизмом, но только после резервной копии и проверки на staging. Если проект сильно изменен, чистая миграция может оказаться надежнее и для третьей версии.

Самое важное — не переносить таблицы вслепую. Сначала определяются различия схем, затем строится карта соответствий ID и полей, после чего каждый блок данных переносится и проверяется отдельно. Именно такой подход позволяет сохранить каталог, клиентов, историю продаж и накопленный поисковый трафик без превращения обновления CMS в эксперимент на рабочем магазине.

Есть похожая задача?

Опишите ее в Telegram — я посмотрю и предложу следующий шаг.

Написать в Telegram