Міграція інтернет-магазину на нову платформу і як зберегти позиції

Ця стаття про ситуацію, коли інтернет-магазин уже працює на власному рушії і ви думаєте змінити його на інший. WooCommerce на щось інше, OpenCart на Laravel, стара самописна система на сучасну платформу.

Якщо ви йдете з орендованої платформи, де рушій вам не належить, у вас інше завдання та інші обмеження: там усе вирішує повнота вивантаження до закриття акаунта. Про це є окремий розбір, як перейти з Хорошопа або Prom на власний сайт. Далі мова про переїзд між системами, які ви контролюєте з обох боків.

Спочатку відокремте симптом від причини

Почніть із переліку конкретних проблем. Формулювання «платформа більше не підходить» не допомагає нікому. Корисні записи конкретні. Наприклад, оновлення залишку затримується на годину, фільтр створює надто багато запитів, оператор переносить адресу в систему доставки руками, а зміна правила знижки займає кілька днів.

Інтернет-магазин проєктують навколо даних та операцій, а платформа лише підтримує цю модель. Якщо сама модель помилкова, назва нового продукту її не врятує. Якщо ж процес описаний чітко, але система змушує будувати дедалі складніші обхідні рішення, з’являється підстава рахувати міграцію.

Що часто ремонтується без переїзду

Повільна сторінка може бути наслідком важкої теми, неоптимізованих зображень, невдалого запиту або слабкого сервера. Конфлікт після оновлення часто виникає через застарілий модуль без підтримки. Хаос в адмінці зазвичай спричинений надмірними правами й дубльованими полями. Усе це виправляється аудитом, прибиранням залежностей і зміною процесу розгортання.

Навіть великий каталог сам по собі не доводить потребу переїзду. Важливі характер фільтрації, число варіацій, частота синхронізації та якість запитів. Спочатку виміряйте повільні операції, розмір таблиць, черги фонових завдань і навантаження в пік. Після вимірювання майже завжди видно невелику кількість вузьких місць.

Що вказує на системне обмеження

Системним є обмеження, яке повторюється в різних функціях і щоразу вимагає обходити базову модель. Наприклад, магазин працює як B2B-портал із персональними договорами, лімітами, кількома рівнями погодження і розподілом одного замовлення між складами. Якщо кожна операція потребує окремої надбудови, загальна складність стає важливішою за зручність окремого модуля.

Другий сигнал це неможливість безпечно змінювати систему. Код не розділений на незалежні частини, модулі перезаписують поведінку один одного, тестового середовища немає, а оновлення можливе лише під час довгого простою. Частину технічного боргу можна прибрати. Якщо ж перебудова фундаменту наближається за обсягом до нового рішення, порівняння платформ стає раціональним.

Коли переїзд буде зайвим

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

Переїзд передчасний і тоді, коли вимоги не описані. Без карти процесів нову систему будуватимуть за випадковими прикладами старої. Команда повторить знайомі недоліки, а під час приймання виявить пропущені винятки. Коротке дослідження перед рішенням дешевше за міграцію, яку доведеться переробляти.

Обережно ставтеся до аргументу «нова платформа швидша». Швидкість залежить від реалізації, даних, інфраструктури й навантаження. Потрібен цільовий показник для конкретних сторінок і операцій та тест на реальному каталозі. Загальна обіцянка доказом не є.

Якщо ви ще на стадії вибору між рушіями, а не переїзду, подивіться порівняння: OpenCart чи WooCommerce.

Чим зміна власного рушія відрізняється від виходу з оренди

Різниця не косметична, і саме через неї плани, написані під один випадок, не працюють в іншому.

• Дані у вас уже є. Не треба встигати вивантажити до закриття акаунта: база під рукою, і можна робити скільки завгодно тестових прогонів.
• Стару систему можна залишити живою. Це основа плану відкату, якого зазвичай немає, коли йдете з орендованої платформи.
• Структура адрес під вашим контролем. На новому рушії її можна зберегти точно такою, якою вона була, а не приймати ту, що нав’яже платформа.
• Інтеграції треба переписувати. Облік, доставка, оплата підключалися до старого рушія, і кожен зв’язок доведеться зібрати заново.
• Модулі не переїжджають узагалі. Усе, що робили плагіни, або є в новій системі, або пишеться. Це найчастіше недооцінена стаття кошторису.

Фіксація еталона до початку робіт

До того як щось змінювати, зафіксуйте старий інтернет-магазин у деталях. Ця частина здається марною доти, доки щось не зникне, і тоді виявиться, що відновити нема з чого.

• Повний обхід сайту. Реєстр усіх сторінок: категорії, фільтри, товари, статті, службові. З кодами відповіді, канонічними адресами, заголовками й описами.
• Сторінки з реальним трафіком. Список сторінок із показами за дванадцять місяців, отриманий через API Google Search Console. Вивантаження прямо зі звіту обрізається до 1000 рядків, а в інтернет-магазині таких сторінок буває значно більше. Так жодна комерційна сторінка не загубиться через те, що про неї забули.
• Контрольні позиції. Знімок поточних позицій за основним пулом запитів, щоб після переїзду було з чим порівнювати.
• Карта інтеграцій. Що з чим з’єднане, у який бік ідуть дані, як часто, і хто помітить, якщо зв’язок обірветься.
• Копія бази й файлів. Повна, працездатна, з перевіреним відновленням. Зберігайте її там, звідки можна відновити сайт.

Складіть це в одну таблицю з типом сторінки й новою адресою. Далі правила застосовуються групами, а винятки розглядаються окремо.

Стратегія адрес

Головне рішення всього переїзду ухвалюється тут і майже не переграється потім.

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

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

Третій варіант уже аварія. Він трапляється тоді, коли про адреси згадують після релізу.

Перенесення даних між рушіями

Тут головна відмінність від вивантаження з оренди: дані не експортують у файл, а зіставляють модель з моделлю.

• Карта відповідності полів. Що в старій системі було атрибутом, у новій може бути варіацією. Що було текстом, має стати значенням зі словника.
• Ідентифікатори зберігаються. Артикул і внутрішній код це основа зв’язків з обліком і каналами продажу. Їхня зміна ламає інтеграції мовчки.
• Тестовий прогін на повному каталозі. На всьому обсязі, бо проблеми виявляються саме в рідкісних випадках, яких на двадцяти товарах не видно.
• Звіт про розбіжності. Скільки товарів перенеслося, скільки відхилено й чому. Без звіту різниця виявляється через місяць.
• Клієнти й замовлення. Історія покупок і паролі переносяться, якщо алгоритм нової системи це дозволяє. Якщо ні, скидання паролів планують заздалегідь і попереджають людей.

Обсяг цих робіт прямо впливає на кошторис інтернет-магазину, і саме він зазвичай виявляється більшим за очікування, бо модулі старої системи ніхто не рахував.

Ціни на міграцію за прайсом не існує. Обсяг залежить від числа товарів, глибини інтеграцій і того, скільки функцій жило в модулях старої системи. Ми рахуємо за вашим каталогом і вашою картою інтеграцій та фіксуємо суму в договорі до початку робіт.

День перемикання

У день релізу порядок дій має бути записаний заздалегідь і виконуватися пункт за пунктом, а не з пам’яті.

• Знизьте TTL записів DNS. До п’яти хвилин, за добу до старту. Це дає можливість швидко повернутися назад.
• Заморозьте зміни каталогу. На коротке погоджене вікно, щоб фінальна синхронізація була повною.
• Зробіть фінальне перенесення. Замовлення і зміни залишків, що прийшли на старий інтернет-магазин у день перемикання, мають опинитися в новій системі.
• Перемкніть записи. І одразу перевірте, що сертифікат працює на всіх піддоменах.
• Зніміть заборону індексації. Тестове середовище закривали від пошуковиків, і на робочому сайті цю заборону треба зняти одразу після перемикання.
• Пройдіть контрольний список. Головна, категорія, товар, кошик, оформлення замовлення і кілька старих адрес.

Перевіряйте з кількох мереж і з чистих сесій: кеш і система доставки вмісту можуть віддавати різні версії, і на робочому ноутбуці все виглядатиме правильно.

План відкату

Це та перевага, якої немає, коли йдете з орендованої платформи, і саме тому її гріх не використати.

• Старий інтернет-магазин живий тридцять днів. На окремому сервері, у робочому стані, з базою. Магазин можна знову ввімкнути, якщо знадобиться відкат.
• Низький TTL до й після. Це скорочує затримку повернення, але строку не гарантує: частина проміжних кешів тримає стару адресу довше за оголошений TTL.
• Межа рішення названа заздалегідь. Це конкретні умови, за яких команда відкотиться.
• Черговий у перші години. Розробник і адміністратор із домовленим часом реакції та правом ухвалити це рішення.

Окремо продумайте, що робити із замовленнями, які прийдуть у новий магазин до відкату. Вони не повинні зникнути разом із перемиканням назад.

Типові фатальні помилки

• Про адреси згадали після релізу. Найгірше з можливого: старі сторінки зникають з індексу, накопичена вага обнуляється.
• Тестовий інтернет-магазин залишили відкритим. Копія на піддомені без заборони індексації розмиває основний домен і створює дублі.
• Заборону індексації не зняли. Бойовий інтернет-магазин залишився закритим від пошуковиків, і сторінки поступово випадають з індексу.
• Модулі не порахували. Кошторис склали за перенесення даних, а половина функцій жила в плагінах, яких у новій системі немає.
• Мета-теги згенерували заново. Шаблонні заголовки замість збережених унікальних це втрата роботи, яку робили роками.
• Стару систему вимкнули одразу. Плану відкату не стало в той момент, коли він знадобився.

Що робити після перемикання

Переїзд закінчується не в день релізу. Перші чотири тижні варто тримати посилений режим перевірки: редиректи, метадані, фільтри, мікророзмітку й журнали сервера дивляться щодня. Скільки триватиме обробка переїзду, залежить від кількості адрес і швидкості сайту, і наперед цей строк не називають.

Це окрема робота зі своїм порядком, і вона розібрана в продовженні: технічне SEO після переїзду інтернет-магазину.

Висновки

Зміна рушія для інтернет-магазину, який ви контролюєте, це керований проєкт. У вас є повна база, можливість тестових прогонів і жива стара система як страховка. Саме ці три речі відрізняють такий переїзд від виходу з орендованої платформи.

Найдорожчі помилки стосуються порядку дій. Про адреси думають після релізу, модулі не рахують у кошторисі, стару систему вимикають у день перемикання. Кожна з трьох виправляється рішенням, ухваленим до початку робіт.

Надішліть нам адресу магазину й опишіть, що саме його обмежує. Ми подивимося структуру, навантаження і журнали та скажемо, чи потрібен переїзд, чи достатньо прибрати вузькі місця на місці. Якщо переїзд потрібен, зберемо карту адрес і карту інтеграцій до початку робіт і візьмемо міграцію в межах розробки інтернет-магазинів.