Переезд с 1С-Битрикс на самописную архитектуру: как не потерять данные

Переезд с 1С-Битрикс на самописную архитектуру: как не потерять данные

Сайт на 1С-Битрикс ещё работает, но каждый релиз — это неделя боли. Хостинг с трудом выдерживает нагрузку, а доработка вроде вывода остатков в личный кабинет превращается в квест на 200 000 ₽ и два месяца согласований. Вы уже думали о переезде на самописную архитектуру, но останавливает не объём кода, а два страха: потерять историю клиентов и заказов и оставить бизнес без сайта на несколько дней.

Переезд не обязан быть «заменой движка» с отключением старого сайта и молитвой на удачу. Это может быть поэтапный проект, где каждый шаг проверяется, данные сверяются контрольными суммами, а откат занимает часы, а не недели. Рассказываю, как это устроено на практике.

Когда 1С-Битрикс перестаёт быть инструментом, а становится тормозом

Симптомы торможения видны не в коде, а в метриках и процессах разработки.

Скорость страниц. Каталог грузится 4–6 секунд вместо 1,5. На каждом этапе воронки это теряет до 20% заявок — и это не магия, а данные из Яндекс Метрики и Google Analytics. Менеджеры видят отказы, но не могут ускорить платформу.

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

Каждая доработка — это «улучшение платформы». Задача «вывести остатки в личный кабинет» обрастает ограничениями движка, совместимостью с версией и кастомизацией административного интерфейса. Сроки растут кратно, бюджет уходит на борьбу с платформой, а не на решение задачи бизнеса.

Лицензия и хостинг. Ежегодные лицензионные платежи и серверные мощности, заточенные под «тяжёлый» движок, несоразмерны отдаче для продаж.

Когда таких симптомов три и больше, вопрос не «переезжать или нет», а «как переехать без потерь».

Аудит текущей системы перед миграцией: что именно вы переносите

Главная ошибка — копировать всё подряд. В Битриксе за годы накапливается мусор, и его перенос только множит проблемы. Аудит помогает отделить критичные данные от второстепенных.

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

Проверьте качество данных. Сколько дублей клиентов в базе, сколько заказов с ошибками в сумме или статусах, в каких полях хранится «мусор» вроде тестовых записей. Переносить нужно только то, что реально работает на бизнес. Если в Битриксе 10 000 клиентов, а реальных покупателей — 3 000, остальных можно отбросить, и это упростит миграцию.

Оцените кастомные модули и настройки. После переезда их придётся переписывать с нуля. Сразу определите, какие модули действительно нужны в новой архитектуре, а какие были «костылями». Часто выясняется, что половина кастомизаций существовала только для компенсации ограничений самого Битрикса — в новой системе они не понадобятся.

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

Результат аудита — реестр сущностей с пометками «критично», «желательно», «можно восстановить». На его основе составляется план миграции и оценивается трудоёмкость.

План переноса данных: как не потерять ни одного заказа

Выгрузить всю базу одним файлом и импортировать в новую систему — гарантия потери связей и появления ошибок. Заказы связаны со статусами, оплатами, доставками, историей изменений. Если переносить их изолированно, история превращается в бесполезный набор строк.

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

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

SEO-параметры переносятся вместе с данными: URL, редиректы, метатеги, sitemap. Если старые адреса начнут выдавать 404, поисковый трафик упадёт мгновенно. Поэтому сохраняем структуру URL и настраиваем редиректы до переключения домена.

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

Тестирование на каждом этапе: почему «переехали и забыли» не работает

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

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

Проверяйте не только целостность данных, но и бизнес-метрики: время оформления заказа, количество ошибок ввода, точки торможения интерфейса. Тестирование оценивает удобство и скорость для ежедневной работы сотрудников.

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

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

Как провести переключение без простоя сайта

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

Планируйте переключение на период минимальных продаж, но не «в полночь на пятницу». Выберите окно в 4–6 часов, когда трафик минимален, и пропишите пошаговый план: перенос последних изменений, обновление DNS, включение редиректов, деактивация старой системы. Чёткий тайминг позволяет уложиться в одни сутки без потери заказов.

Подготовьте страницу технических работ. Если переключение займёт больше времени, чем планировалось, пользователь должен увидеть понятное сообщение — «ведутся технические работы, мы скоро вернёмся», а не «502 Bad Gateway». Это сохранит доверие клиентов и снизит поток обращений в поддержку.

Сделайте финальный бэкап Битрикса в момент остановки продаж и храните его несколько месяцев. Даже после успешного перехода он нужен как страховка: для сверки спорных заказов, восстановления утерянных файлов, ответа на претензии клиентов.

Чек-лист безопасного переезда с 1С-Битрикс на самописную архитектуру

Обязательные шаги миграции. Каждый пункт подтверждается документально ответственным специалистом.

• Провести аудит данных: реестр всех сущностей с пометками критичности и ответственными.
• Сделать полный бэкап Битрикса (файлы, БД, настройки) и проверить его развёртывание на тестовом сервере.
• Разработать маппинг полей: таблица соответствия «поле в Битриксе» → «поле в новой системе» для каждой сущности.
• Написать и прогнать на тестовой базе скрипты переноса по блокам.
• Сверить контрольные суммы и выборочные записи: не только количество, но и содержимое 5–10 случайных заказов.
• Протестировать все интеграционные сценарии: оформление заказа, оплата, выгрузка в 1С, синхронизация с CRM.
• Провести нагрузочное тестирование новой системы на реальных данных: главная, каталог, корзина, админка.
• Обучить сотрудников работе в новой системе: минимум один-два дня работы с реальными задачами до переключения.
• Выполнить переключение по плану: DNS, редиректы, отключение старой системы, включение новой.
• Наблюдать за системой первые 72 часа: метрики, логи, обращения пользователей, скорость обработки заказов.

Последний пункт — самый важный. После переезда система требует внимания: кто-то должен следить за логами, отвечать менеджерам, оперативно исправлять мелкие ошибки. Это нормальная работа в первые дни, и к ней нужно быть готовым.

Вывод

Переезд с Битрикса на самописную архитектуру — это не «технический долг», а проект по повышению управляемости бизнеса. Он даёт контроль над данными, скоростью и стоимостью доработок — но только при условии чёткого планирования данных и тестирования на каждом шаге.

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

Digital Hook проектирует архитектуру под задачи бизнеса, переносит данные по чек-листу и сохраняет историю заказов и клиентов. Мы берём на себя аудит текущей системы, план миграции и откатные сценарии, чтобы сайт не остановил продажи. Если узнали свои симптомы — обсудим ваш проект и посчитаем сроки и объём работ.

Частые вопросы

Как организован процесс переезда и сколько времени он занимает?

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

Из чего складывается бюджет на миграцию?

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

Что потребуется от нас как от заказчика?

Нужны доступы к текущей системе, участие в согласовании плана и эксперт, который знает бизнес-процессы. Также потребуется выделить время для тестирования на пилотном запуске. Мы подготовим подробные регламенты и будем вести документацию.