Pimcore 11.5 и Pimcore 2025+: что изменилось для бизнеса, если функционально PIM остался почти тем же

10.7.2026 В 2024 году Pimcore 11.5 / Platform Version 2024.4 был удобной точкой входа для PIM-проектов: можно было развернуть систему, настроить модель данных, интеграцию с ERP, фиды для маркетплейсов и дальше масштабировать категории без отдельного лицензионного расчета по обороту компании. С 2025 года выбор стал менее техническим и более управленческим. Pimcore перешел на POCL, ввел обязательную регистрацию экземпляров и разделил сценарии использования по редакциям и коммерческим условиям.

Для бизнеса это означает: при том же базовом PIM-сценарии меняется не столько список функций, сколько стоимость владения, юридическая модель и ответственность за дальнейшие обновления.

В 2025.1 Pimcore ввел обязательную Product Registration: до установки или использования нужен Product Key, а каждый экземпляр проекта должен быть зарегистрирован. В этой же версии все модули были переведены на POCL, а часть возможностей изменила место в редакциях. В 2026.1 Pimcore закрепил новую архитектуру: Studio заменяет Admin UI Classic, все bundles переходят на единую версионность, а требования к стеку становятся жестче - PHP 8.4 или 8.5 и Symfony 7.x.

Это нормальная эволюция платформы, но для внедрения она добавляет работы:

• нужно учитывать совместимость расширений
• миграцию интерфейсных сценариев
• изменения в installer-процессе
• новую лицензионную процедуру

Если задача - запустить MVP PIM для товарных данных, интегрировать его с ERP и вывести фиды в несколько каналов продаж, обе ветки решают основную задачу. В типовом сценарии нужны не уникальные enterprise-модули, а понятная модель данных, правила качества, загрузка товаров, сопоставление категорий, маппинг атрибутов и стабильная выгрузка. Поэтому функциональный спор 2024.4 против 2025+/2026.x часто оказывается вторичным.

Для первой очереди важнее ответить на другие вопросы:

• сколько категорий нужно запустить сразу
• сколько каналов продаж подключать в MVP
• кто сопровождает правила валидации
• как быстро бизнес будет менять структуру каталога
• какой лицензионный риск компания готова принять

Новая ветка безопаснее, если проект сразу планируется как долгосрочная платформа, а компания крупная, проходит комплаенс-аудиты, хочет официальную коммерческую лицензию и не хочет строить развитие на последнем GPLv3-релизе. Это особенно важно, если PIM должен стать частью более широкой PXM/MDM-архитектуры, работать с несколькими командами, регулярно обновляться и использовать будущие возможности Studio.

В этом сценарии дополнительные расходы на лицензию лучше считать не переплатой за те же кнопки, а ценой снижения юридического и операционного риска. Но даже тогда нужно отдельно оценить миграцию Admin UI Classic, совместимость расширений и стоимость сопровождения.

Открытые источники для проверки: Pimcore о переходе с GPLv3 на POCL - https://pimcore.com/en/resources/blog/breaking-free-pimcore-says-goodbye-to-gpl-and-enters-a-new-era-with-pocl. Release notes 2024.4 - https://docs.pimcore.com/platform/Pimcore_Platform/Updating_Pimcore/Release_Notes/07_2024.4/. Release notes 2025.1 - https://docs.pimcore.com/platform/Pimcore_Platform/Updating_Pimcore/Release_Notes/06_2025.1/.

Release notes 2026.1 - https://docs.pimcore.com/platform/Pimcore_Platform/Updating_Pimcore/Release_Notes/02_2026.1/. Pimcore Editions - https://docs.pimcore.com/platform/Pimcore_Platform/Pimcore_Editions/. POCL license text - https://github.com/pimcore/platform-version/blob/2026.x/LICENSE.md.

Расчет экономики в статье приведен по обезличенной модели PIM-MVP:

• из него исключены названия клиента
• внутренние роли
• имена поставщиков
• проектные аббревиатуры и любые данные
• позволяющие связать оценку с конкретной компанией