Ушли с Odoo на Dolibarr: где стало легче, а где пришлось доделывать руками

MAATRIX

Odoo на своём сервере рано или поздно упирается в одну и ту же стену: чем больше модулей включено, тем тяжелее апдейты, тем капризнее производительность и тем чаще приходится звать специалиста, чтобы просто обновить версию. У части компаний в какой-то момент возникает вопрос — а точно ли нужен весь этот вес, если реально используются продажи, склад, счета и немного CRM? Dolibarr — один из ответов на этот вопрос: более простая ERP/CRM система, которая изначально не пытается быть всем для всех. Ниже — не маркетинговое сравнение, а разбор того, что конкретно меняется на сервере и в ежедневной работе после такого переезда, включая то, что стало хуже.

Почему вообще уходят с Odoo

Чаще всего причина не в цене Enterprise-лицензии (Community-редакция Odoo бесплатна) и не в отдельном «плохом» модуле, а в накопившейся сложности эксплуатации. Типичный сценарий: компания три-четыре года назад подняла Odoo на VPS под десяток пользователей, постепенно включила склад, производство, HR, сайт и подписки — и теперь каждое крупное обновление версии превращается в проект на несколько дней с миграцией кастомных модулей и тестированием на копии базы.

Второй частый триггер — сервер стал узким местом. Odoo построен на Python и ORM поверх PostgreSQL, и с ростом числа одновременных пользователей и объёма данных требования к CPU и памяти растут заметно быстрее, чем кажется на старте. Апгрейд VPS решает проблему на время, но не устраняет её причину: система тяжёлая по архитектуре, потому что рассчитана на закрытие практически любого бизнес-процесса из коробки.

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

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

Что такое Dolibarr и чем он принципиально проще

Dolibarr — это ERP/CRM с открытым кодом на PHP и MySQL/MariaDB, то есть классический LAMP-стек, знакомый почти любому, кто когда-либо администрировал WordPress или другой PHP-проект. В отличие от Odoo, где ядро и модули построены на Python-фреймворке собственной разработки с ORM, ролями и своей логикой миграций, Dolibarr ближе к традиционному веб-приложению: файлы, конфиг, база данных, cron-задачи через обычный crontab.

Функционально Dolibarr закрывает базовый набор: продажи и коммерческие предложения, счета и платежи, склад и запасы, проекты, HR-модуль базового уровня, CRM-функции (контакты, воронка, задачи), модуль подписок и точку продаж (POS) для розницы. Всё это — модульная система, где включаются только нужные блоки через административную панель, без пересборки и без Docker-образов с десятками сервисов.

Ключевое архитектурное отличие — отсутствие тяжёлого ORM-слоя и очереди задач наподобие Odoo с его worker-процессами. Dolibarr в базовой конфигурации работает как обычное PHP-приложение под Apache или Nginx + PHP-FPM, обращается к MySQL напрямую и не требует отдельного процесса для очередей или скриптов вроде тех, что использует Odoo для крон-задач и почтовых рассылок. Это не значит, что Dolibarr «лучше» — просто он проще как система, и это прямо отражается на требованиях к серверу.

Требования к серверу: что изменилось

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

Практическое следствие: там, где под Odoo с запасом брали VPS на 4 ядра и 8 ГБ RAM, под Dolibarr с тем же количеством пользователей часто хватает конфигурации в два раза скромнее — и не потому что Dolibarr «обрезан», а потому что архитектурно он не тащит ORM-слой, встроенный веб-сервер на Python и отдельные worker-процессы, которые в Odoo потребляют память даже в простое.

Если сервер уже арендован под Odoo и на нём есть запас, для Dolibarr можно даже не пересматривать тариф — переезд не потребует увеличения ресурсов, скорее наоборот, освобождается запас под другие задачи на том же VPS. Ориентиры по памяти для конкретных версий Odoo разбирались отдельно в статье «Сколько RAM нужно для Odoo» — полезно свериться, от какой базы вы вообще отталкиваетесь.

Что реально стало проще

Первое и самое заметное — администрирование сервера. Развёртывание Dolibarr — это, по сути, классическая связка LAMP: PHP, веб-сервер, MySQL, распаковка архива дистрибутива или клонирование репозитория, настройка конфига через веб-мастер при первом запуске. Человек, который умеет ставить и обновлять WordPress или любой другой PHP-проект, разберётся с Dolibarr без специфического опыта именно с Odoo-стеком. Для сравнения, разворачивание Odoo с нуля разбиралось в отдельной статье про установку и настройку Odoo на VPS — там заметно больше шагов именно из-за архитектуры Python + отдельный сервис.

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

Третье — прозрачность стека для диагностики проблем. Когда Odoo тормозит, разбираться приходится в нескольких слоях: сам Python-процесс, воркеры, PostgreSQL с его специфичной нагрузкой от ORM-запросов, иногда Redis для очередей в более сложных конфигурациях. У Dolibarr классическая связка PHP-FPM + MySQL — те же инструменты диагностики (slow query log, top, htop, логи Apache/Nginx), что и для любого стандартного веб-проекта, и специалистов, которые умеют чинить LAMP-стек, найти проще и дешевле, чем тех, кто глубоко разбирается именно в Odoo.

Четвёртое — время развёртывания и восстановления после сбоя. Поднять Dolibarr с нуля на чистом VPS и восстановить из бэкапа (файлы + дамп MySQL) — задача на порядок быстрее, чем аналогичное восстановление Odoo, где нужно поднять правильную версию Python-зависимостей, PostgreSQL, а иногда и повторно установить кастомные модули из отдельного репозитория.

Что пришлось доделывать руками

Честная часть — то, что автоматически из Odoo в Dolibarr не переезжает и что стоило времени и ручной работы.

Миграция данных. Прямого инструмента импорта «из Odoo в Dolibarr» в базовой поставке нет. Данные — клиенты, товары, счета, история заказов — выгружались из Odoo через встроенный экспорт в CSV/Excel по каждой сущности отдельно, затем приводились к формату, который ожидает импорт Dolibarr (у него свои требования к структуре CSV для каждого модуля — товаров, третьих лиц, счетов). На выгрузку, чистку и загрузку данных по паре тысяч записей клиентов и товаров ушло заметно больше времени, чем изначально закладывалось — прежде всего из-за расхождений в полях и справочниках (единицы измерения, налоговые ставки, статусы заказов не совпадают один в один).

История и связи между документами. Odoo хранит цепочки документов (предложение → заказ → счёт → оплата) со сквозными ссылками. При переносе через CSV эти связи не переносятся автоматически — счета и заказы в Dolibarr после миграции существуют как отдельные записи, если специально не восстанавливать связи вручную или скриптом через прямые запросы к базе Dolibarr. Для старых закрытых периодов решили не тратить на это время и оставили архив истории доступным в режиме «только чтение» на старом сервере ещё на несколько месяцев — практичнее, чем гнаться за идеальной миграцией.

Настройка печатных форм и шаблонов документов. Кастомные шаблоны счетов, коммерческих предложений и накладных, сделанные в Odoo через QWeb-редактор, никак не переносятся — Dolibarr использует собственный движок ODT-шаблонов (LibreOffice-документы с плейсхолдерами). Все фирменные шаблоны документов пришлось собирать заново вручную в LibreOffice Writer с нуля.

Интеграции. Если в Odoo были настроены интеграции с внешними сервисами (платёжные шлюзы, доставка, бухгалтерский экспорт, синхронизация с интернет-магазином) через готовые модули из App Store, для Dolibarr придётся искать модули из его собственного каталога (DoliStore) — набор там заметно меньше и не все интеграции сделаны так же гладко. По части интеграций часть вещей пришлось реализовывать через встроенный API Dolibarr и собственные скрипты, а не готовыми плагинами.

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

Чего не хватает по функциональности после Odoo

Это стоит проговорить прямо, потому что именно здесь чаще всего разочаровываются те, кто ждал «Odoo, только легче».

• Производство (MRP). У Odoo есть полноценный модуль производства с спецификациями (BOM), рабочими центрами, маршрутами и планированием. У Dolibarr производственных возможностей практически нет — только базовый учёт складских перемещений. Для компаний с реальным производственным циклом это блокирующее ограничение.
• Глубина отчётности и BI. Встроенная аналитика Odoo с настраиваемыми сводными таблицами и дашбордами заметно мощнее того, что предлагает Dolibarr из коробки. В Dolibarr отчёты более базовые, и для серьёзной аналитики придётся либо выгружать данные во внешний BI-инструмент, либо мириться с ограничениями.
• Автоматизация процессов. У Odoo есть встроенный конструктор автоматических действий (Automated Actions) и мощный движок workflow между модулями. В Dolibarr автоматизация ограничена триггерами через модуль workflow, который покрывает куда более узкий набор сценариев.
• Экосистема модулей. У Odoo App Store — тысячи модулей, включая нишевые отраслевые решения. У DoliStore каталог заметно скромнее, и под специфичную задачу модуля просто может не найтись — придётся дорабатывать самостоятельно или искать обходной путь.
• Многосклад и сложная логистика. Odoo поддерживает сложные складские маршруты, правила пополнения и мультискладские операции на другом уровне детализации, чем базовый складской модуль Dolibarr.

Если у бизнеса есть производство или сложная многоуровневая логистика, переход на Dolibarr, скорее всего, будет шагом назад по функциональности, и это стоит трезво учитывать до миграции, а не после.

Для какого масштаба бизнеса переход оправдан

По опыту такой переезд имеет смысл в довольно конкретном профиле компании: 5-30 пользователей, торговля товарами или услугами без сложного производства, основные процессы — продажи, счета, склад, немного проектного учёта и CRM. Для такого профиля Odoo часто изначально был избыточен, и Dolibarr закрывает те же задачи с меньшей операционной нагрузкой на сервер и на администратора.

Обратная сторона: если в компании уже плотно используются производственные модули, расширенная аналитика, сложные workflow-автоматизации или десятки кастомных интеграций через App Store, миграция на Dolibarr будет не облегчением, а откатом по функциям, который придётся компенсировать ручной работой и внешними инструментами — и в такой ситуации разумнее либо остаться на Odoo, либо посмотреть в сторону других open-source ERP с более широким функционалом, например ERPNext, сравнение которого с Odoo разбиралось отдельно в статье «Odoo или ERPNext: что выгоднее и когда».

Отдельный практический момент: переход не стоит делать «за выходные». Разумный сценарий — поднять Dolibarr параллельно на отдельном VPS или хотя бы в отдельном контейнере на том же сервере, перенести данные, дать ключевым сотрудникам протестировать реальные рабочие сценарии пару недель, и только после этого переключать продакшн-процессы и отключать старую систему Odoo. Держать Odoo в режиме «только для чтения» ещё месяц-два после перехода — недорогая страховка на случай, если в миграции данных что-то упущено.

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