Міграція на Adobe Commerce з Magento Open Source: приймання та переносимість

Магазин перенесли, каталог відкривається, але дилер бачить роздрібну ціну, а повторний запит створює зайве замовлення в обліку. Саме тому міграція на Adobe Commerce з Magento Open Source має завершуватися не демонстрацією нової хмари, а перевіркою торговельних операцій. До початку робіт погодьте, хто підтверджує правильність цін, оплат, залишків та історії покупок, а також як бізнес отримає свої дані й код для наступного переходу.

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

Спочатку визначте, яку саме хмару ви приймаєте

Назва Adobe Commerce Cloud недостатньо точна. Adobe Commerce on cloud infrastructure — платформа як послуга (PaaS), а Adobe Commerce as a Cloud Service — програмне забезпечення як послуга (SaaS). Тут розглядаємо Magento Open Source → Adobe Commerce on cloud infrastructure. Для SaaS потрібен інший план.

У офіційному порівнянні моделей Adobe для PaaS описана спільна відповідальність: Adobe керує хостинговою платформою, а продавець відповідає за прикладні патчі, власний код, конфігурацію та підтримувані залежності. У SaaS ядром і його оновленнями керує Adobe; змінювати код ядра не можна, розширення будують через підтримувані інтерфейси та сервіси. Отже, старий PHP-модуль не слід автоматично вважати придатним для обох моделей.

Зафіксуйте продукт, модель, застосовні версії та придбані можливості: ліцензії й B2B-розширення підтверджують окремо. Якщо потрібен лише надійніший хостинг, оцініть доопрацювання чинного Magento Open Source.

Перетворіть обіцянку «все працює» на критерії бізнес-приймання

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

Перевіряйте правила, а не тільки сторінки

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

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

Призначте власника кожного підтвердження

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

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

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

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

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

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

Умовний приклад: підтвердження замовлення загубилося між магазином та ERP

Розгляньмо умовний магазин запчастин із персональними цінами для дилерів. Покупець замовляє дві упаковки товару, а облік веде його в штуках. Інтеграція передає погоджену кількість, ERP створює замовлення, проте відповідь не доходить до магазину. Це навчальний сценарій для приймання, а не опис клієнта чи результату GL.ua.

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

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

Перевірте й запізніле повідомлення про оплату: хто та за яким підтвердженням змінює стан замовлення. Сторінка «Дякуємо» не доводить завершення всього ланцюжка.

Проведіть репетицію перемикання з умовами зупинки

Репетиція перевіряє послідовність і тривалість робіт на ваших даних. Інструкція Adobe з розгортання в Staging та Production передбачає передпродукційне тестування. Тестовий контур не повинен списувати реальні кошти чи надсилати клієнтам навчальні повідомлення.

1. Зафіксуйте стан джерела: версію коду, конфігурацію, контрольний набір записів і перелік активних обмінів.
2. Виконайте пробне перенесення та звірте не лише записи, а й повний маршрут замовлення, відмову, повернення та повторний запит.
3. Перевірте фінальне оновлення даних: які зміни накопичилися після пробного імпорту та як вони потраплять у ціль.
4. Погодьте момент зупинки записів і перемикання інтеграцій, щоб старий і новий магазин не приймали несумісні зміни одночасно.
5. Відтворіть критичний збій і рішення про відкат: хто його ухвалює, що відновлюють та як узгоджують нові транзакції.
6. Після тестового відкриття перевірте контрольні покупки, журнали обміну, фонові завдання й відповідальних за чергування.

Для відкату визначте граничний момент, після якого простого повернення старої бази вже недостатньо. Якщо новий магазин устиг прийняти оплату, відновлення старої копії саме собою не скасує платіж. Потрібна процедура звірки таких операцій. Це одна з причин не погоджувати обіцянку «відкотимо кнопкою» без репетиції.

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

Доведіть переносимість відновленням, а не передачею архіву

Переносимість інтернет-магазину — це можливість відтворити потрібні дані й поведінку в погодженому іншому середовищі з урахуванням ліцензій. Вона не означає, що ліцензовані функції Adobe Commerce можна безоплатно запустити в Magento Open Source чи іншій CMS. Якщо бізнес планує вихід, кожній такій функції потрібна заміна або окреме рішення.

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

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

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

Строки й бюджет оцінюйте за невідомими залежностями

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

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

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

Рішення про запуск має спиратися на докази

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

Розглядаєте іншу архітектуру? Передайте GL.ua (Глянець) торговельні правила, інтеграції та вимоги до переносимості. У межах розробки сайтів та інтернет-магазинів на Drupal обговоріть альтернативу та склад робіт до укладання договору на перенесення.