Оновлення магазину зривається не через складність самого процесу, а через несподіванки: модуль без версії під нову гілку, тема, яку писали під стару, платне розширення з мертвим автором. Усе це можна з'ясувати заздалегідь.
1. Точна версія й форк
Не «OpenCart 3», а конкретна підверсія — від неї залежить усе інше. Наприклад, між 3.0.3.7 і 3.0.4.1 змінився шаблонізатор, і конструкції, що працювали, у новій версії дають помилку завантаження шаблону. Форк теж має значення: ocStore відрізняється від стокового OpenCart набором таблиць і поведінкою.
2. Перелік модифікацій
Кожна модифікація шукає в коді конкретний фрагмент. Якщо в новій версії він змінився — зміна не застосується, причому часто без будь-якої помилки. Модуль виглядає встановленим, а не працює. Тому перед оновленням варто мати список: що є, що з цього критичне, що можна викинути.
3. Тема
Питання не «чи гарна вона», а наскільки далеко вона пішла від базової. Тема з десятком дрібних правок переїде; тема, переписана під конкретний макет, потребує окремої роботи.
4. Платні модулі
Для кожного треба з'ясувати три речі: чи існує версія під цільову гілку, скільки вона коштує і чи живий автор. Модуль без підтримки — найчастіша причина, чому оновлення відкладають на роки.
5. Версія PHP
Нова гілка вимагає новішої PHP, а на ній ламаються старі модулі. Тобто оновлення магазину майже завжди тягне за собою оновлення сумісності коду — це варто закладати в план одразу.
6. Стан бази
Накопичені за роки проблеми — биті зв'язки, дублі, залишки видалених модулів — при перенесенні виринають назовні. Краще знати про них до, а не під час.
Що робити з результатами
Нормальний результат такої перевірки — не завжди «оновлюємось». Часто висновок протилежний: лишитись на поточній гілці й вирішити конкретну проблему точково. Це чесніше й дешевше.
Готовий розбір із оцінкою обсягу — послуга аудиту сумісності. Якщо після нього рішення про перехід підтвердиться, далі йде міграція на OpenCart 4 або оновлення в межах гілки. Про те, що саме змінюється між версіями — окремий матеріал.
