Как уйти с 1С-Битрикс: перенос данных, заказов, интеграций и SEO

Уйти с 1С-Битрикс — не значит скопировать товары в новую CMS и переключить домен. Интернет-магазин продолжает принимать заказы, обмениваться данными с 1С, показывать цены и остатки, обслуживать покупателей в приложении и получать переходы из поиска. При замене платформы всё это должно работать и после запуска.

Поэтому план перехода начинается с двух вопросов: что бизнес хочет изменить и что обязано сохраниться без изменений. Ниже — практическая последовательность для действующего интернет-магазина, а не обещание переезда без единого риска.

Сначала определите, нужна ли замена

Если проблема локальна — например, медленно работает один раздел каталога или неудобен отдельный экран админки, — начните с диагностики и оценки доработки. У Битрикса есть «Монитор производительности», который помогает найти нагруженные страницы и компоненты. Сам факт медленной работы не доказывает необходимость новой платформы. Документация 1С-Битрикс.

Замена становится предметом расчёта, когда ограничения связаны между собой: новый дизайн упирается в старую логику, сайт и приложение развиваются с разной скоростью, товары и заказы требуют ручной работы, а каждое изменение затрагивает множество интеграций. Сравните два конкретных плана на одинаковый объём бизнес-задач: оздоровить текущую систему или перейти на новую. Не нужно менять Битрикс только потому, что существует более современный стек.

Что сохраняем, а что заменяем

В большинстве проектов учётная система 1С остаётся. Заменяется платформа интернет-магазина и те её части, которые действительно мешают развитию. Важно заранее договориться о границах:

• Данные и процессы. Товары, цены, остатки, клиенты, заказы, статусы и правила продаж сохраняют бизнес-смысл, но не обязаны повторять таблицы Битрикса.
• Сайт. Если его интерфейс уже отделён от Битрикса и работает через API, его можно временно оставить. Сайт на шаблонах Битрикса обычно пересобирают вместе с новым дизайном.
• Мобильное приложение. Его можно подключить к новой серверной части через совместимый API или заменить отдельным этапом. Это относится и к приложениям на внешних платформах, включая IMSHOP.
• Внешние сервисы. Оплата, доставка, лояльность, CRM, поиск и аналитика остаются там, где они полезны; меняются правила их подключения к магазину.

Такой разбор предотвращает две ошибки: попытку переписать всё сразу без необходимости и обещание «сохранить всё», не выяснив, что именно сегодня работает в старой системе.

Шаг 1. Составить карту действующего магазина

До оценки сроков соберите не только список модулей, но и фактическое поведение системы:

1. Откуда приходят товары, описания, цены и остатки; какая система для каждого типа данных главная.
2. Какие состояния проходят заказ, оплата, доставка, отмена и возврат; какие действия выполняют операторы вручную.
3. Какие обмены идут с 1С и другими системами, как часто, в каком формате и что происходит при ошибке или повторной отправке.
4. Какие API используют сайт и приложение; какие фоновые задания, права сотрудников и нестандартные правила спрятаны в доработках Битрикса.
5. Какие адреса страниц получают поисковые показы, переходы и внешние ссылки; какие страницы доступны только через фильтры или поиск по сайту.

Итог — карта зависимостей и список проверок, без которых нельзя принимать новую систему. Код и документация помогают, но реальные правила приходится сверять также с данными, логами и работой сотрудников.

Шаг 2. Перенести данные и доказать полноту переноса

Для каждой сущности укажите источник, место в новой системе и правило преобразования. Например, товар может приходить из 1С, описание карточки — редактироваться в системе управления товарами, а наличие — рассчитываться по складам. Если эти источники не развести до миграции, новая база быстро начнёт противоречить старой.

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

Особое внимание — данным, которые изменятся во время подготовки запуска. Между первым переносом и переключением появятся новые заказы, изменятся цены и остатки. Для них нужен сценарий переноса изменений и точное время последней сверки. Если старый способ хранения учётных данных не позволяет безопасно перенести вход покупателей, заранее подготовьте понятный сценарий повторного входа.

Шаг 3. Не потерять и не продублировать заказы

Заказ — не одна строка в базе. У него есть состав, скидки, платежи, доставка, изменения, отмены и возвраты. До переключения решите, какая система отвечает за каждый заказ, начатый до запуска, и где оператор увидит его актуальное состояние.

Проверьте сквозные сценарии: оформление покупки, подтверждение оплаты, передачу заказа в 1С, изменение статуса, частичную отмену и возврат. Повторное сообщение от платёжного или логистического сервиса не должно создавать второй заказ или повторно применять операцию. Если часть заказов остаётся в старой системе на время перехода, сотрудникам нужна ясная граница между двумя контурами.

В день запуска сравнивайте число и сумму заказов в магазине, оплате и 1С. Расхождение должно вести к разбору конкретных заказов, а не к ручной «подгонке» итогов.

Шаг 4. Проверить обмен с 1С и другие интеграции

Сохранить 1С — не значит просто подключить к ней новый адрес. Нужно воспроизвести согласованные правила: загрузку каталога, цен и остатков, выгрузку заказов, получение статусов и обработку ошибок. В конкретном магазине поверх типового обмена часто есть собственные поля и исключения; их нужно выявить до оценки.

Для каждого обмена подготовьте тесты на обычный день и сбой: задержку одной стороны, частично обработанный пакет, повтор сообщения, изменение порядка событий и недоступность внешнего сервиса. Те же вопросы относятся к оплате, доставке, программе лояльности и уведомлениям. Если старый контракт неудобен, его можно улучшить, но изменение должно быть отдельным согласованным решением, а не неожиданным эффектом переезда.

Шаг 5. Сохранить поисковые страницы при смене платформы

SEO-переезд проектируют до разработки нового сайта. Сначала выгрузите адреса из карты сайта, аналитики, Google Search Console, Яндекс Вебмастера и обхода старого магазина. Для каждого значимого URL определите: он остаётся, переходит на новый адрес или удаляется без подходящей замены.

Проверьте до запуска:

• постоянные перенаправления со старых адресов на соответствующие новые, без массового переноса товаров на главную;
• заголовки, описания, основной адрес страницы, правила для поисковых роботов и актуальную карту сайта;
• обычные ссылки на категории и товары, по которым робот может пройти без действий пользователя;
• страницы фильтров и вариантов товара: какие должны индексироваться, а какие создают дубли;
• видимые покупателю цену и наличие, данные в товарной разметке и выгрузках.

Google рекомендует заранее составить карту старых и новых URL, обновить внутренние ссылки и использовать постоянные серверные перенаправления. Яндекс также рекомендует 301 при смене структуры и обновление Sitemap. Даже при правильном переносе поисковый трафик может временно колебаться; обещать неизменные позиции нельзя. Рекомендации Google, рекомендации Яндекса.

Шаг 6. Провести репетицию и переключить магазин

Пробный перенос на данных сопоставимого объёма покажет, сколько времени занимают выгрузка, преобразование, загрузка и проверки. На репетиции пройдите путь покупателя и оператора, проверьте обмены и составьте пошаговый план запуска с ответственными и критериями остановки.

Переключение можно провести в одно согласованное окно или по частям — например, сохранив действующее приложение на совместимом API. Поэтапность не всегда безопаснее: две системы, одновременно изменяющие цены или заказы, могут создать конфликт. Сценарий выбирают по связности данных и допустимому времени ограничений продаж.

План возврата к прежней системе нужен до запуска, но после появления новых заказов простой откат уже может стать невозможным без отдельной сверки. Поэтому заранее определите, в какой момент ещё можно отменить переключение и как обработать операции, которые успели пройти в новой системе.

Что контролировать после запуска

В первые часы и дни смотрите на реальные продажи: заказы и оплаты, ошибки оформления, остатки, задержки обмена с 1С, отмены и возвраты. Для поиска проверяйте ответы страниц, перенаправления, индексацию, показы и клики. Один удачный тестовый заказ не означает, что миграция завершена.

Хороший результат перехода подтверждают не обещания новой технологии, а материалы приёмки: сверка данных, пройденные сценарии, проверки интеграций, карта адресов и наблюдение после запуска.

Как помогает Surf

Мы берёмся за замену 1С-Битрикс, когда ограничения уже мешают бизнесу. Сохраняем 1С и нужные внешние сервисы, переносим данные и заказы с проверками, строим новую серверную часть и удобное управление контентом, товарами и заказами. Если входит в согласованный состав проекта, одновременно обновляем сайт и мобильное приложение в едином современном дизайне.

Срок три месяца и фиксированную цену предлагаем для состава работ, который определён после разбора действующего контура. Если диагностика покажет, что достаточно локальной доработки Битрикса, не будем выдавать замену за единственный разумный путь.

CTA: Обсудить переход с 1С-Битрикс