Перенос сайта с 1С-Битрикс
Разбираем инфоблоки, компоненты, каталог, обмен с 1С и кастомные модули. Переносим полезную бизнес-логику, а не ограничения старой архитектуры.
- 1С-Битрикс
- Каталог
- Интеграция с 1С
Проектируем и разрабатываем сайты, приложения и цифровые системы, которые помогают бизнесу расти.
Website migration
Переносим проекты с 1С-Битрикс, WordPress и самописного PHP. Сохраняем поисковый капитал и строим платформу, которую проще развивать.
Обсудить переносОбсудить переносНовая платформа должна сохранить всё, что приносит трафик, заявки и выручку, — и убрать причины, которые мешали проекту расти.
Поэтому миграция начинается с инвентаризации URL, данных и процессов. Дизайн, контент, интеграции и инфраструктуру рассматриваем как части одной системы.
Для каждой системы — свой способ извлечения данных, проверки связей и воспроизведения функций.
Разбираем инфоблоки, компоненты, каталог, обмен с 1С и кастомные модули. Переносим полезную бизнес-логику, а не ограничения старой архитектуры.
Мигрируем записи, страницы, рубрики, медиа и SEO-данные. Заменяем хрупкую связку плагинов управляемой CMS и документированными интеграциями.
Восстанавливаем правила самописной системы, отделяем критичные процессы от накопившегося legacy-кода и поэтапно переносим их на Django.
SEO-план — часть разработки и приёмки, а не список исправлений после релиза.
Собираем адреса из sitemap, аналитики, поисковых систем, базы данных и серверных логов — не ограничиваемся обходом меню.
Сохраняем прежние адреса там, где это возможно. Для изменённых страниц готовим точные постоянные редиректы без цепочек.
Переносим title, description, H1–H3, canonical, Open Graph, alt-тексты, пагинацию и международные атрибуты.
Восстанавливаем и проверяем Schema.org для организации, товаров, статей, хлебных крошек и других сущностей проекта.
Готовим robots.txt и sitemap, переносим счётчики и цели, закрываем тестовый стенд и открываем production только после проверки.
Отслеживаем 404, редиректы, сканирование, позиции, трафик и Core Web Vitals. Исправляем расхождения по фактическим данным.
Импорт делаем повторяемым: его можно прогнать на тестовом стенде, сверить и выполнить ещё раз перед запуском.
Старый и новый сайт работают параллельно до тех пор, пока новая система не пройдёт техническую, контентную и SEO-приёмку.
Фиксируем текущее устройство сайта, источники данных, интеграции, URL, поисковые показатели и причины, из-за которых платформу пора менять.
Определяем модель данных, CMS, роли, архитектуру Django, необходимость Next.js, правила кэширования и инфраструктуру.
Переносим контрольную выборку сложных сущностей и заранее проверяем форматирование, связи, медиа и скорость повторного импорта.
Создаём новую систему и воспроизводимый миграционный pipeline. Старый сайт продолжает работать, пока мы синхронизируем изменения.
Сравниваем страницы и данные, проверяем редиректы, формы, интеграции и производительность. Репетируем переключение и план возврата.
Выполняем финальную синхронизацию, переключаем трафик и контролируем ошибки, индексацию, конверсии и состояние инфраструктуры.
Утверждены реестр URL, объём данных, критерии приёмки, окно переключения и ответственные.
Замораживаем изменения на короткий период, выполняем delta-импорт, прогреваем кэш и проверяем критичные сценарии.
Мониторим приложение, серверные логи, 404, поисковые панели, аналитику и обращения редакторов.
Абсолютную неизменность позиций не может гарантировать никто: поисковые системы сами принимают решение о ранжировании. Мы снижаем риск — сохраняем URL и контент, переносим метаданные, настраиваем точные 301-редиректы и контролируем индексацию после запуска.
Нет. Ценные URL стараемся сохранить один в один, даже если внутренняя структура Django отличается. Адрес меняем только при обоснованной переработке структуры и всегда задаём прямое соответствие старой и новой страницы.
Сначала определяем, какую бизнес-задачу решает каждый модуль. Нужные сценарии воспроизводим в новой архитектуре, ненужные и дублирующие исключаем. Механически переносить уязвимые плагины и legacy-код обычно не имеет смысла.
Основная работа проходит параллельно на отдельном окружении. Для финальной синхронизации может понадобиться короткое окно, когда редакторы не меняют данные. Его длительность определяем после аудита и репетиции переключения.
Не всегда. Django и Wagtail могут обслуживать сайт целиком. Next.js добавляем, когда проекту нужен насыщенный интерфейс, независимый frontend, несколько клиентских приложений или особая стратегия рендеринга и кэширования.
Срок зависит от количества типов контента, качества исходных данных, интеграций и объёма переработки интерфейса. После аудита делим проект на этапы и отдельно оцениваем первый безопасный релиз.

Начнём с вашей задачи
[ Соединяем стратегию, дизайн и технологии, чтобы цифровой продукт решал задачи бизнеса и развивался вместе с ним. ]