Перенесення магазину WooCommerce на інший хостинг, домен або сервер потребує особливої уваги до замовлень, оплат і даних клієнтів. Найнебезпечніший сценарій — виконати повне копіювання сайту, а потім замінити його новою версією, не врахувавши замовлення, які надійшли під час міграції.
Щоб зменшити ризик втрати даних, потрібно заздалегідь спланувати вікно перенесення, зробити резервні копії, перевірити структуру бази даних і тимчасово контролювати всі операції з оплатами. Якщо магазин переноситься з маркетплейсу або іншої платформи, окремо варто врахувати особливості імпорту товарів, клієнтів і замовлень. Наприклад, під час Перенесення інтернет-магазину з Прома важливо не лише завантажити каталог, а й правильно підготувати нову систему до роботи з покупцями та оплатами.
Планування вікна міграції
Міграцію краще проводити в період найнижчої активності магазину. Проте навіть уночі або у вихідні можуть надходити нові замовлення, працювати автоматичні оплати, оновлюватися залишки чи змінюватися статуси доставки. Тому «вікно міграції» не означає просто вибрати зручний час і скопіювати файли.
Перед початком потрібно:
- визначити поточну версію WordPress, WooCommerce, PHP і бази даних;
- скласти список активних плагінів, теми, платіжних і служб доставки;
- перевірити, де зберігаються файли, медіа, логи та резервні копії;
- створити повну копію файлів і бази даних;
- переконатися, що резервну копію можна відновити, а не лише успішно створити;
- визначити момент, після якого приймання нових замовлень буде тимчасово призупинене або переведене під посилений контроль.
До резервної копії бажано додати окремий експорт замовлень, користувачів, товарів і налаштувань WooCommerce. Не варто видаляти старий сайт або базу даних одразу після запуску нової версії: попереднє середовище може знадобитися для перевірки й відновлення даних.
Копіювання товарів і клієнтів
Під час міграції важливо перенести не тільки сторінки та зображення, а й пов’язану структуру WooCommerce. До неї належать атрибути, варіації товарів, категорії, теги, ціни, залишки, податки, купони, способи доставки та метадані.
Копіювання бази даних «як є» часто є безпечнішим за вибірковий імпорт, але це залежить від завдання. Якщо сайт переноситься на іншу платформу або потрібно об’єднати старі й нові дані, імпорт може створити дублікати товарів і клієнтів. Особливо обережно потрібно працювати з ідентифікаторами товарів, SKU, email-адресами та паролями користувачів.
Для клієнтів слід перевірити:
- чи перенесені облікові записи та ролі користувачів;
- чи збережені адреси доставки й оплати, якщо вони потрібні магазину;
- чи працює авторизація після зміни домену або структури URL;
- чи не порушено політику конфіденційності під час експорту та передачі даних;
- чи не втрачено зв’язок між клієнтом і його попередніми замовленнями.
Після перенесення потрібно перевірити кількість товарів, варіацій, клієнтів і замовлень у старій та новій системах. Незначні розбіжності іноді пояснюються фільтрами імпорту, але будь-яку різницю слід з’ясувати до відкриття магазину для покупців.
Синхронізація останніх замовлень
Саме на етапі синхронізації найчастіше виникає ризик втрати нових замовлень. Якщо після створення копії на старому сайті надійшли покупки, вони не потраплять до нової бази автоматично. Просте повторне відновлення всієї бази може, навпаки, перезаписати нові дані, які вже з’явилися на новому сайті.
Безпечна послідовність зазвичай виглядає так:
- зробити повну резервну копію старого сайту безпосередньо перед міграцією;
- скопіювати сайт на тестовий або новий сервер;
- перевірити каталог, клієнтів, налаштування та замовлення;
- на короткий узгоджений період обмежити зміни на старому сайті або чітко зафіксувати момент переходу;
- перенести замовлення, створені після початкового копіювання, окремим контрольованим способом;
- порівняти номери замовлень, суми, статуси, дані клієнтів і спосіб оплати;
- лише після перевірки направити домен і трафік на новий сервер.
Не рекомендується вручну редагувати записи без резервної копії або без розуміння структури таблиць WooCommerce. Замовлення можуть бути пов’язані з метаданими, товарами, податками, доставкою та транзакціями. Некоректне редагування бази даних здатне призвести до дублювання, зміни сум або втрати зв’язків.
Якщо магазин працює безперервно й не може призупинити прийом замовлень, може знадобитися двостороння синхронізація або тимчасова схема маршрутизації замовлень. Такі рішення залежать від плагінів, способу оплати, структури бази даних і навантаження, тому їх краще готувати на копії сайту заздалегідь.
Платіжні інтеграції
Після перенесення сайт може відкриватися коректно, але платежі не проходитимуть. Причиною бувають змінені ключі API, домен, SSL-сертифікат, вебхуки, IP-адреса сервера або обмеження платіжного сервісу.
Для кожної інтеграції потрібно перевірити:
- ключі та секрети API, не публікуючи їх у відкритому доступі;
- URL для callback і webhook-повідомлень;
- режим тестування або бойовий режим;
- відповідність домену й SSL-сертифіката вимогам платіжної системи;
- створення замовлення після успішної та невдалої оплати;
- коректну зміну статусу замовлення після отримання повідомлення від сервісу;
- надсилання листів клієнту й адміністратору.
Не можна перевіряти бойову оплату випадковими операціями без узгодження з платіжним сервісом: це може спричинити реальне списання коштів або створення зайвих замовлень. Якщо тестове середовище недоступне, варто заздалегідь погодити спосіб контролю платежів і перевірити журнали інтеграції.
Також потрібно врахувати системи доставки, CRM, складський облік, email-маркетинг і сервіси аналітики. Після зміни домену або сервера вони можуть продовжити надсилати дані на стару адресу або створювати дублікати операцій.
Тестова покупка
До відкриття магазину виконайте контрольний сценарій від початку до кінця. Перевірте сторінку товару, вибір варіації, додавання в кошик, оформлення замовлення, промокод, доставку, оплату та листи. Окремо протестуйте мобільну версію, оскільки помилки форми або платіжної кнопки часто проявляються саме на смартфонах.
Після тестової покупки потрібно перевірити:
- чи створився запис замовлення з правильним номером;
- чи відповідають сума, знижка, доставка та податки очікуваним значенням;
- чи зменшилися залишки товару;
- чи отримали повідомлення клієнт і адміністратор;
- чи передалися дані до CRM, служби доставки або облікової системи;
- чи змінився статус після оплати або скасування;
- чи немає помилок у логах WordPress, WooCommerce та сервера.
Після перемикання домену варто ще раз перевірити кілька реальних сценаріїв і тимчасово контролювати нові замовлення вручну. Якщо зникають замовлення, виникають дублікати, не приходять webhook-повідомлення або платежі зависають у невірному статусі, не слід продовжувати експерименти на бойовому сайті. Спочатку створіть резервну копію поточного стану та зверніться до спеціаліста для діагностики.
Міграція WooCommerce без втрати нових замовлень — це не одноразове копіювання файлів, а контрольований процес із резервуванням, перевіркою інтеграцій і синхронізацією даних. Точна схема залежить від поточної конфігурації магазину, обсягу замовлень і способу перенесення, тому перед початком робіт важливо провести технічну діагностику.