Миграция рациональна, когда упираетесь в интеграции (1С/ERP/CRM), сложный каталог с SKU/правилами цен, ролевую модель и нагрузку на корзину/чекаут. Если одновременно критичны хотя бы два из этих факторов — разработка сайта на Битрикс снизит TCO за счёт композита, кэш-тегов, зрелых модулей магазина и предсказуемой поддержки.
Риски и как их погасить
Главная тройка: потеря SEO (смена URL), искажение данных (заказы/пользователи/остатки), падение CR на оформлении. Гасим их стендом со «срезом» БД, полным 1:1 маппингом URL с 301 и репетицией релиза. План отката обязателен: снапшот БД/файлов и обратный переключатель DNS/прокси.
Этапы миграции на 1С-Битрикс
- Переход на 1С-Битрикс — это не просто смена CMS, а инженерный процесс, который требует поэтапного подхода и точного контроля на каждом шаге. Каждый этап влияет на устойчивость системы и эффективность будущей разработки сайта на Битрикс.
- Аудит источника. В начале проекта проводится анализ текущей платформы: структура данных, карта URL, шаблоны мета-тегов, интеграции и бизнес-логика. Это фундамент для построения новой архитектуры и безошибочной миграции.
- Проектирование модели данных. Разрабатываются инфоблоки и Highload-блоки, определяются связи между сущностями, каталогом и предложениями. Цель — создать гибкую модель, готовую к масштабированию и дальнейшей интеграции.
- Настройка SEO-слоя. Создаётся таблица соответствий старых и новых URL, формируются 301-редиректы, хлебные крошки и мета-шаблоны. Такой подход позволяет сохранить поисковый трафик и позиции в выдаче.
- Перенос данных (ETL). На этом шаге очищаются и нормализуются данные, выстраивается корректный ЧПУ, переносятся изображения и связи. После загрузки проводится контроль уникальности и проверка на ошибки.
- Интеграции. Настраиваются обмены с 1С, ERP и CRM-системами. Отрабатываются очереди, расписания, обработка ошибок. Это обеспечивает стабильный обмен данными и согласованность каталогов, заказов и остатков.
- UX и корзина. Проверяются пользовательские сценарии оформления заказа, оплаты, доставки и применения купонов. Задача — не допустить падения конверсии при переходе на новую систему.
- Производительность. Включается композит, оптимизируется кэш, подключается CDN и современные форматы изображений. Контролируются показатели LCP, INP, CLS для стабильной скорости загрузки.
- Релиз и контроль качества. Перед запуском выполняется контент-фриз, финальная синхронизация и smoke-тесты. Создаётся план отката и система мониторинга ошибок. После проверки сайт выходит в продуктив без простоев.
Архитектура данных: ИБ/HL и стабильные связи
Каталог строим на двух инфоблоках: «Товары» и «Торговые предложения». Все справочники (бренд, коллекция, цвет, размер) выносим в Highload-блоки, чтобы обеспечить устойчивые ключи, быстрые JOIN и чистые значения для фильтра. Фильтруемые свойства храним строго типизированными, а значения для ЧПУ фиксируем транслитом с «белым списком» символов. Для бесшовной миграции сохраняем идентификаторы источника в отдельные поля (external_id) — это упрощает повторные догрузки и розыск несоответствий.
Нормализация атрибутов
Свободный текст преобразуем в словари HL, единицы приводим к единому реестру (мм/см/м; г/кг), значения «залипаем» к справочникам по ключам. Это ускоряет фильтр, стабилизирует ЧПУ и снижает брак в аналитике. На этапе ETL устраняем дубликаты и «мусорные» значения, которые в старой системе попадали из форм без валидации.
SEO-сохранность: 1:1 карта и консистентные сниппеты
Карта URL формируется до разработки шаблонов. На каждый старый адрес — строгий 301 на целевую страницу; 302 и «мягкие» 200-заглушки исключаем. Переносим мета-шаблоны, хлебные крошки и микроразметку (Product, Breadcrumb, Organization). Важный нюанс — страницы фильтра: задаём фиксированный порядок свойств в ЧПУ и канонизируем все нецелевые комбо на базовую посадочную; популярные пресеты оформляем как самостоятельные лендинги с уникальными Title/H1/Description и статическим каноникалом.
ETL контента и медиа
Процесс строго идемпотентный: повторный прогон не создаёт дублей и не ломает связи. В трансформациях приводим артикулы и SKU к единому формату, конвертируем изображения в WebP/AVIF и перестраиваем внутренние ссылки на новую схему ЧПУ. Отчёты по батчам храним рядом с исходниками, чтобы при расхождениях быстро локализовать брак на уровне набора.
Интеграции с 1С/ERP/CRM и аналитикой
Обмен товарами, остатками, ценами и заказами выполняется по расписанию, с журналированием и очередями для повторов при 5xx. Для конфликтов определяем «систему-источник»: цены и остатки обычно доминируют в ERP, маркетинговые атрибуты — в Битрикс. CRM подключаем через REST/вебхуки с ретраями и дедупликацией по внешним ключам. Аналитику строим на Enhanced Ecommerce и сервер-сайд событиях (view_item, add_to_cart, purchase), чтобы разработка сайтов завершалась проверяемыми метриками бизнес-результата.
Корзина и чекаут
Повторяем успешные сценарии старого сайта: гостевой заказ, автоподстановка адреса и контактных данных, прозрачные комиссии и предсказуемая доставка. Валидация купонов/сертификатов и возвратов проходит на стейдже с реальными тестовыми стендами шлюзов. Метрики begin_checkout, add_payment_info, add_shipping_info и purchase должны сходиться с сервер-сайд логами — это признак консистентности воронки.
Производительность: композит и кэш-теги
Компоненты разделяем на статические и динамические, подключая композитную схему там, где блоки не зависят от пользователя. Инвалидацию кэша привязываем к бизнес-событиям (изменение цены/остатка), а не к времени. Статику раздаём через CDN; изображения — с srcset и lazy-loading. Контроль LCP/INP/CLS ведём на реальных устройствах в ключевых шаблонах: листинг, карточка и чекаут.
Безопасность и права
Ролевую модель проектируем заранее: мерчандайзеру не нужны права редактора новостей, а маркетологу — доступ к служебным полям ИБ. Админку закрываем 2FA и IP-фильтром, отключаем вывод ошибок и держим ядро/модули на актуальных патчах. Журналы и дампы доступны только через VPN, алерты на аномалии (401/403/5xx) приходят в мониторинг.
DevOps и релизный цикл
Единая среда (Docker) для dev/stage/prod, CI/CD с миграциями схемы, smoke-наборами и автоматической раскаткой. E2E-тесты покрывают каталог, фильтр, карточку, корзину, чекаут, оплату, доставку и SEO-редиректы. Наблюдаемость включает аптайм, перцентили TTFB и отчёты по обменам. Такой процесс делает разработка сайта на битрикс предсказуемой и управляемой.
Перенос пользователей и заказов
Пользователей переносим с логинами, адресами и согласиями на обработку данных. Если исходные хэши паролей несовместимы, включаем сценарий «первого входа» со сбросом. История заказов переносится целиком, включая документы и статусы; купоны и бонусы привязываются к новым идентификаторам пользователей по надёжному ключу.
Тест-план и релиз
Финальная приёмка проходит без чек-листов-«простыней»: проверяем полноту данных и связей, соответствие 301-карт, корректность каноникалов и микроразметки, поведение корзины/чекаута и скорость шаблонов под нагрузкой. Запуск проводим в тихое окно с контент-фризом и финальной синхронизацией БД; дальше — короткие smoke-прогоны и мониторинг 404/500/CR. План отката готов и уже обкатан на стейдже.
Первые 2–4 недели после релиза
Обновляем таблицу редиректов по свежим 404, обучаем редакторов регламентам карточек и посадочных фильтра, перестраиваем индексы/кэши и устраняем узкие места по логам. На этом этапе фиксируем SLA поддержки: приоритеты, сроки и «релиз-поезд» на накопленные улучшения.
Бюджет и реальная стоимость
Помимо лицензий учитываем ETL/очистку, адаптацию дизайна под компоненты, нагрузочные испытания, сервер/балансировщик/CDN и мониторинг. Это честная стоимость владения, без которой «дёшево и быстро» превращается в постоянный технический долг — и это уже не разработка сайтов, а латание дыр.
Частые pitfalls по источникам
WordPress → Битрикс
ACF/кастомные поля маппятся в свойства ИБ/HL, таксономии в разделы/свойства, шорткоды переписываются на компоненты. Важно закрыть дубляж из тегов/архивов и привести пагинацию к конечному числу страниц.
OpenCart → Битрикс
Опции конвертируются в ТП (SKU) с артикулами, ценами и остатками на уровне предложения. Перенос транслита категорий/товаров планируется заранее, мультивалютность и налоги согласуются с источником, модули оплаты/доставки подбираются с тестами возвратов.
Самопис → Битрикс
Начинаем с инвентаризации схемы и нормализации идентификаторов. Пароли проверяем на предмет солей/алгоритмов; при неопределённости запускать «сброс при первом входе». Уникальные бизнес-правила оформляем через события/агентов и очереди, а не «вплавляем» в шаблоны.