Миграция на 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 обсудите альтернативу и состав работ до заключения договора на перенос.