Перенос CRM из облака на собственный сервер: что учесть и в каком порядке переезжать

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

Что на самом деле переезжает, когда переносишь CRM на свой сервер

Когда директор говорит «хочу перенести CRM к себе», он обычно имеет в виду базу клиентов. Это одна пятая работы. Вместе с базой переезжают ещё три слоя: интеграции (почта, телефония, формы сайта, обмен с учётной системой), доступы людей и ответственность за то, что система работает в понедельник в девять утра. В облаке это ответственность вендора. На своём сервере она ваша или вашего подрядчика. Мы в АйТи-Фреш разворачиваем open-source CRM на вашем сервере и сразу договариваемся, кто отвечает за каждый из этих слоёв, потому что без такого разговора переезд заканчивается красивым дашбордом и ночным звонком от менеджера по продажам.

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

Отдельно про границы статьи. Про то, какие сущности вообще можно вынести из amoCRM и Битрикс24, как сопоставлять поля и склеивать дубли, я уже писал в разборе про выгрузку данных из amoCRM и Битрикс24. Здесь не повторяю. Эта статья про другую половину задачи: куда и как переезжать инфраструктурно, в какой день переключаться и как откатиться, если что-то пошло не так. Если вы читаете это перед подписанием договора с подрядчиком, держите в голове вопрос: кто будет делать бэкап через полгода, когда проект закончится.

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

Куда ставить CRM: сервер в офисе, VPS или стойка в дата-центре

Первый вопрос, который задают в Москве: «у нас есть старый сервер в серверной, можно на нём?». Можно, но с оговорками. Сервер в офисе даёт максимальный контроль и самую низкую цену за год, если железо уже куплено. Минусы известны: единственный интернет-канал, электричество, отсутствие резерва, и копия, которая лежит в соседней стойке, а не в другом здании. Я ставлю CRM в офисе только если есть ИБП, второй провайдер или готовность терпеть простой в несколько часов, и если резервная копия уходит за пределы офиса.

Для компаний до 50 мест мой выбор по умолчанию — виртуальный сервер у российского хостера. Он стартует за день, диск и память масштабируются без закупки железа, канал выше офисного. Аренда стойки или выделенного сервера в дата-центре оправдана, когда рядом уже стоит 1С, файловая база и всё остальное и вы хотите держать это в одном месте. Ниже сводка по трём вариантам. | Вариант | Плюсы | Минусы | Когда я его выбираю | |---|---|---|---| | Сервер в офисе | железо уже есть, данные в здании | электричество, канал, нет резерва | есть ИБП, копия уходит наружу, команда в одном офисе | | VPS в российском ЦОД | быстрый старт, масштабируется, канал надёжнее офисного | ежемесячная плата, зависимость от хостера | вариант по умолчанию для 10–50 человек | | Стойка или выделенный сервер в ЦОД | своё железо, рядом остальная инфраструктура | дороже на старте, дольше закупка | уже есть 1С и другие серверы, хочется держать их вместе |

Отдельный фактор для России — закон о персональных данных. Часть 5 статьи 18 закона 152-ФЗ требует, чтобы запись, хранение и извлечение персональных данных граждан РФ при их сборе выполнялись с использованием баз данных, находящихся на территории России, с исключениями, перечисленными в пунктах 2, 3, 4 и 8 части 1 статьи 6. В CRM лежат ФИО, телефоны и почта клиентов, так что для компании с российскими клиентами это не абстракция. Я не юрист, поэтому формулировку и исключения под вашу ситуацию проверяйте по актуальной редакции закона и с юристом. Но для технического решения вывод простой: площадка в России снимает вопрос ещё до того, как он возникнет.

Размер сервера — отдельная тема, и подробные ориентиры по ядрам, памяти и диску я собрал в статье про требования к серверу под CRM. Здесь только практическое правило: считайте под пиковую нагрузку (квартальные отчёты, массовая рассылка, импорт при переезде), а не под среднюю. Для переезда я всегда беру сервер на ступень крупнее, чем нужен в обычный день, и уменьшаю, если после месяца работы видно, что запас избыточный. Увеличить сервер проще, чем объяснять директору, почему в день переключения всё подвисло.

Как развернуть новую CRM до переезда: контейнеры, HTTPS и первый бэкап

В наших проектах CRM — это ITfresh CRM на основе Frappe и ERPNext, и я разворачиваю её в Docker. По документации проекта frappe_docker, канонический способ для production — файл compose.yml плюс файлы-дополнения из каталога overrides. Файл pwd.yml предназначен для быстрого знакомства и в документации прямо помечен как «не для production». Ещё одна деталь, на которой спотыкаются: приложения вроде CRM нужно включать в образ на этапе его сборки, а не доустанавливать в работающий контейнер. Подробную пошаговую установку я разбирал в статье про установку ERPNext в Docker для production, а про сам продукт — в материале про установку Frappe CRM в Docker, поэтому останавливаюсь только на том, что важно именно для переезда.

Из основного compose-файла поднимаются сервисы configurator, backend, frontend (nginx), websocket, очереди фоновых задач и планировщик scheduler. Базы данных в основном файле нет, её добавляют отдельным файлом, например compose.mariadb.yaml. Сервис configurator запускается при каждом старте, прописывает доступы к базе и Redis и завершается, остальные сервисы ждут его выхода. Это важно помнить, когда пишете скрипты: перед созданием сайта подождите, пока сервис db заработает, а configurator выйдет, обычно до десяти секунд.

HTTPS для одиночного стека делается через дополнение compose.https.yaml, где встроенный Traefik сам получает сертификат Let's Encrypt. Нужны переменные SITES_RULE и LETSENCRYPT_EMAIL, порты 80 и 443 должны быть доступны снаружи, потому что используется проверка HTTP-01, а DNS-запись должна уже смотреть на новый сервер. Это создаёт неудобство: пока старая CRM живёт на старом адресе, сертификат на новый адрес получать некуда. Я решаю это поддоменом для пилота, например crm-new.example.com, а в день переключения либо перевыпускаю сертификат на основной адрес, либо заранее получаю его для двух имён.

Сайт в контейнере создаётся командой bench new-site через сервис backend. Если запускали стек с параметром -p, то добавляйте его в каждую команду:

docker compose -p erpnext exec backend bench new-site \
  --mariadb-user-host-login-scope=% \
  --db-root-password <пароль-root-базы> \
  --admin-password <пароль-администратора> \
  crm-new.example.com

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

В каком порядке переносить данные: пилот, тестовая загрузка, финальная выгрузка

Данные переезжают дважды: сначала репетиция, потом боевой прогон. Репетиция идёт на копии, на пилотном адресе, и цель у неё одна — найти то, что не ложится. Берёте выгрузку, загружаете в порядке «пользователи, справочники, компании, контакты, сделки, задачи и заметки», проверяете связи на двадцати–тридцати карточках, считаете количество записей по этапам и сумму закрытых сделок. Что именно переносить и как сопоставлять поля, я описал в статье про уход из amoCRM и Битрикс24. Для переезда важно другое: репетицию надо повторить минимум дважды, а на второй раз засечь время, потому что именно оно определит размер окна в день переключения.

Если облачная система — тоже на Frappe или ERPNext, повезло. Тогда можно переносить не записи, а целиком сайт: резервная копия базы, публичные и приватные файлы. Бэкап снимается командой bench backup. По умолчанию файлы кладутся в каталог sites/<имя-сайта>/private/backups, флаг --with-files добавляет публичные и приватные файлы, а --compress сжимает архивы в tgz. Восстановление делает bench restore: аргументом идёт путь к дампу базы в формате sql.gz или sql, а файлы подключаются опциями --with-public-files и --with-private-files. Имена файлов подставьте реальные, я их здесь не придумываю.

Пример переноса на новый сервер, где файлы бэкапа сначала копируются в контейнер, а затем восстанавливаются:

docker compose -p erpnext cp ./backup/<файл-базы>.sql.gz backend:/tmp/
docker compose -p erpnext cp ./backup/<файл-публичных>.tar backend:/tmp/
docker compose -p erpnext cp ./backup/<файл-приватных>.tar backend:/tmp/
docker compose -p erpnext exec backend bench --site crm-new.example.com restore \
  /tmp/<файл-базы>.sql.gz \
  --with-public-files /tmp/<файл-публичных>.tar \
  --with-private-files /tmp/<файл-приватных>.tar
docker compose -p erpnext exec backend bench --site crm-new.example.com migrate

Команда docker compose cp копирует файлы между хостом и сервисом в обе стороны, это описано в документации Docker. Последняя строка нужна, чтобы привести схему и фоновые задачи сайта в соответствие с установленными приложениями. Документация предупреждает, что bench migrate не стоит запускать с флагом --skip-failing в production.

Главное ограничение: понижение версии сайта при восстановлении не поддерживается. Это значит, что версия Frappe и ERPNext на новом сервере должна быть не ниже, чем в источнике. Я всегда сначала смотрю, какая версия стоит у источника, и только потом собираю образ. Если нужно ещё и обновиться, делаю это отдельным шагом после стабилизации, как описано в статье про обновление ERPNext с версии 15 на версию 16, а не в день переключения. Правило простое: в один день меняем одну вещь. Ещё два момента, о которых узнают уже после восстановления. Если сайт существует, bench restore запросит пароль root базы данных (его можно передать опцией --db-root-password), поэтому команду я запускаю интерактивно, а не из скрипта. И перенесите со старого сервера ключ encryption_key из site_config.json сайта: без него Frappe не расшифрует сохранённые пароли почтовых учётных записей и интеграций, и их придётся вводить заново.

День переключения: окно, заморозка, сверка и откат

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

Сверка — это не «посмотрели, вроде нормально». Я сравниваю количество компаний и контактов, количество сделок по этапам, сумму закрытых сделок за период и проверяю выборочно двадцать карточек глазами менеджера, который ими занимается. Отдельно проверяю права: что вошедший под ролью менеджера видит только своё. Если числа не сходятся в пределах уже известного расхождения из репетиции (например, из-за склеенных дублей), идём дальше. Если расхождение новое — стоп и откат до выяснения причины. Откат решается заранее: старая CRM остаётся в режиме чтения с оплаченной подпиской ещё на месяц, DNS возвращается на прежнее значение.

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

Бэкапы и мониторинг после переезда: что нельзя экономить

После переключения CRM становится вашим сервисом, и первый вопрос — где лежит копия. В документации frappe_docker для production приведён вариант расписания: раз в шесть часов выполнять bench --site all backup с флагом --with-files через cron, а копии отправлять во внешнее S3-совместимое хранилище утилитой restic с хранением последних тридцати снапшотов. Это хорошая отправная точка. Для запуска из cron в команду docker compose exec нужно добавлять флаг -T, потому что у cron нет терминала (в примере frappe_docker этого флага нет, я добавляю его сам). Документация Docker пишет, что по умолчанию docker compose exec выделяет TTY, а -T отключает псевдо-TTY, а как именно он ведёт себя в вашей версии Compose, проверьте тестовым запуском.

0 */6 * * * docker compose -p erpnext exec -T backend bench --site all backup --with-files > /dev/null

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

Про восстановление отдельно. Оно описано выше: bench restore с путём к дампу и опциями для файлов. Подробности по бэкапам и восстановлению именно ERPNext я собрал в материале про бэкапы и восстановление ERPNext. Здесь только организационная часть: напишите на одной странице, где лежит CRM, как делаются копии, кому приходят оповещения и как восстановить. И подключите мониторинг на память, диск, состояние контейнеров и результат ночного бэкапа. Мониторинг, который молчит, когда бэкап не выполнился, хуже его отсутствия: он создаёт ощущение безопасности.

Кейс: озеленение «Сезон роста», 25 рабочих мест, три недели

Компания «Сезон роста» занимается озеленением и обслуживанием участков. В CRM работали 25 человек: менеджеры по продажам, бригадиры, офис-менеджер и руководители. Причина переезда была двумя словами: стоимость подписки и желание, чтобы клиентская база лежала на сервере, к которому у компании есть полный доступ. Исходная система была облачной, перенос делали в ITfresh CRM на ERPNext и Frappe, под управлением Docker, на виртуальном сервере в российском дата-центре.

Сервер — 4 vCPU, 8 ГБ памяти, 80 ГБ SSD, что укладывается в мои ориентиры для команды до тридцати пользователей из статьи про требования к серверу, с запасом на импорт в день переезда. Первая неделя ушла на площадку, развёртывание и бэкап: контейнеры, HTTPS через Traefik на пилотном поддомене, расписание бэкапа каждые шесть часов с отправкой копий во внешнее хранилище. Тестовое восстановление из копии на чистом стенде заняло около 40 минут. Вторая неделя — две репетиции переноса данных, замеры времени, сверка чисел и перенос интеграций почты и формы сайта на тестовый адрес. Третья — обучение по ролям и подготовка чек-листа.

Переключение назначили на субботу, окно с 18:00 до 23:00, то есть пять часов. За два дня до этого снизили TTL у DNS, пользователей предупредили, старую систему перевели в режим чтения. В окно уложились, сверка по количеству записей и сумме закрытых сделок сошлась, откат не понадобился. Старая подписка оставалась ещё месяц как страховка, после чего её закрыли. Итог по срокам: три недели от первой встречи до понедельника на новой системе. Итог по результату: клиентская база и бэкапы под контролем компании, менеджеры в понедельник работали без звонков в поддержку. Цифры условные, но порядок действий и пропорции я использую в реальных проектах.

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