Переезд магазина с ИП на ООО в 2026: БД, API и чек-лист

Если интернет-магазин в Беларуси в 2026 году переезжает с ИП на ООО, это не история про заменить реквизиты в подвале сайта. С 1 января 2026 года ИП вправе продолжать деятельность только по видам из разрешенного перечня, а Закон Республики Беларусь от 22.04.2024 № 365-З предусмотрел механизм продолжения бизнеса через созданную коммерческую организацию с переходом прав и обязанностей. Для кода это означает не косметику, а рефакторинг сущностей, интеграций и доступа. Не случайно я отдельно выносил эту тему в свою контент-матрицу на 2026 год.

Почему это вообще задача разработчика, а не только юриста

Юрист поможет с регистрацией, уставом, уведомлениями и документами. Но магазин живет не в уставе, а в продакшене: в таблицах заказов, токенах эквайринга, вебхуках, складских интеграциях, CRM, 1С, карточках маркетплейсов и админке. Как только меняется субъект хозяйствования, старая связка seller = ИП перестает быть безопасной архитектурой.

Я обычно исхожу из простого правила: переезд с ИП на ООО нельзя делать через массовый UPDATE seller_id = new_id по всей базе. Исторические заказы, чеки, статусы оплат, возвраты и акты должны сохранять тот юридический контекст, в котором они реально возникли. Иначе потом начнется каша в бухгалтерии, сверках и спорах с платежкой.

Есть еще один неприятный момент. Закон о защите персональных данных № 99-З требует прозрачной обработки персональных данных, а НЦЗПД прямо пишет, что политика должна объяснять, кем, как, для каких целей, на каком основании и на какой срок данные обрабатываются. Если оператор меняется с ИП на ООО, это надо отражать не только в документах, но и в фактической логике обработки данных на сайте и в личном кабинете.

С чего я бы начал до первого SQL-скрипта

Перед миграцией я не лезу в код. Сначала собираю карту зависимостей.

Что нужно инвентаризировать:

• домен, SSL, хостинг, CDN;
• эквайринг, ЕРИП, онлайн-кассы, фискализация;
• CRM, ERP, 1С, WMS, курьерки;
• маркетплейсы и агрегаторы;
• email/SMS-провайдеров;
• шаблоны чеков, оферты, возвратов, политики данных;
• пользователей админки и их текущие доступы.

На этом этапе становится видно, где у вас реально зашит ИП. Иногда это красиво лежит в таблице merchants. А иногда всплывает в 14 местах: в шаблоне PDF-счета, в старом cron-джобе, в подписи webhook payload, в env-переменной, в callback URL банка и в Excel-выгрузке для бухгалтера.

Второе решение — выбрать режим миграции. Обычно вариантов два.

Big bang: ночью отключаем часть функционала, переносим, переключаем, открываем утром. Подходит только если магазин небольшой и связей мало.

Dual-run / zero-downtime: старая и новая юридическая сущность какое-то время живут параллельно, а приложение умеет маршрутизировать операции по дате, каналу или типу заказа. Для живого e-commerce это почти всегда разумнее.

Как я рефакторю модель данных

Главная ошибка — считать ИП или ООО “владельцем магазина” в виде одного поля на всей платформе. Правильнее разнести:

1. сам магазин как продуктовую сущность;
2. юридическое лицо как субъект расчетов и документов;
3. исторический снимок реквизитов, который привязан к заказу или платежу.

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

BEGIN;

CREATE TABLE legal_entities (
  id UUID PRIMARY KEY,
  type TEXT NOT NULL CHECK (type IN ('IP', 'LLC')),
  display_name TEXT NOT NULL,
  legal_name TEXT NOT NULL,
  unp TEXT NOT NULL,
  address TEXT,
  created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

CREATE TABLE shop_legal_entity_periods (
  id UUID PRIMARY KEY,
  shop_id UUID NOT NULL,
  legal_entity_id UUID NOT NULL REFERENCES legal_entities(id),
  valid_from TIMESTAMP NOT NULL,
  valid_to TIMESTAMP NULL,
  UNIQUE (shop_id, valid_from)
);

ALTER TABLE orders
  ADD COLUMN legal_entity_snapshot JSONB,
  ADD COLUMN legal_entity_id UUID NULL REFERENCES legal_entities(id);

COMMIT;

Дальше я не переписываю старые заказы “задним числом”. Я заполняю legal_entity_snapshot на момент оформления заказа и использую его для чеков, актов, возвратов и выгрузок. Это банально спасает от споров вида “почему заказ за октябрь 2025 внезапно показывается как продажа ООО, которого тогда еще не было”.

Если заказов много, миграцию нужно дробить. Не один жирный скрипт на 40 минут, а батчи с идемпотентностью, логированием и возможностью повторного запуска. И да — BEGIN/COMMIT/ROLLBACK тут не украшение, а страховка. Этот тезис я тоже отдельно отмечал для самой структуры статьи.

API: где миграция обычно ломается больнее всего

На практике больнее всего страдает не БД, а внешние интеграции.

Когда меняется субъект расчетов, я сразу предполагаю, что придется заново проверить:

• merchant ID и секреты эквайринга;
• подписи webhook;
• счета и назначения платежей;
• шаблоны электронных чеков;
• callback URL и whitelist IP;
• ERP/1С-обмен, если там фигурируют реквизиты продавца;
• API маркетплейсов, если кабинет продавца оформлен на другой субъект.

В исходном PDF я тоже отмечал, что при такой миграции обычно приходится заново выпускать ключи платежных интеграций, перестраивать вебхуки и вводить RBAC вместо режима “один владелец — одна админка”.

Я делаю это через версионирование контрактов, а не через “давайте заменим поле и надеемся”.

type LegalContext = {
  legalEntityId: string;
  legalEntityType: "IP" | "LLC";
  unp: string;
  validFrom: string;
};

type OrderCreateV2 = {
  cartId: string;
  customerId: string;
  paymentMethod: "card" | "erip" | "invoice";
  legalContext: LegalContext;
};

Почему так лучше:

• старые клиенты API не падают сразу;
• новый контекст можно катить постепенно;
• проще трассировать, какой заказ ушел под какой субъект;
• легче включить feature flag по каналам продаж.

Еще один совет из практики: добавьте correlation_id и таблицу событий интеграции. Когда в день переключения банк, CRM и склад начинают жить в разных состояниях, без сквозного ID вы не поймете, где именно потерялся заказ.

Публичный слой: что забывают почти все

Переезд с ИП на ООО — это не только backend.

Нужно пройтись по всему, что видит покупатель:

• карточка продавца на сайте;
• footer и контакты;
• публичная оферта;
• политика обработки персональных данных;
• политика cookie, если вы используете не только технические cookie;
• формы возврата и претензий;
• email-шаблоны “заказ принят”, “оплата получена”, “возврат оформлен”.

МАРТ ведет сведения Торгового реестра, а в публичной информации интернет-магазина должны отображаться данные продавца. Для юрлица и для ИП состав таких сведений различается, поэтому после переезда нельзя оставлять старые реквизиты “на потом”.

По персональным данным логика такая же: если оператором теперь является ООО, а не ИП, это должно быть отражено в политике, каналах обратной связи, основаниях и сроках хранения данных. НЦЗПД отдельно рекомендует писать такие политики простым и понятным языком и при необходимости выносить отдельную политику по cookie.

Админка после переезда: одному ИП хватало, ООО — уже нет

У ИП админка часто строится по принципу “я и мой помощник”. У ООО почти сразу появляются роли: директор, бухгалтер, менеджер заказов, контентщик, закупщик, техподдержка.

Поэтому я бы не переносил старую схему прав 1:1. Это хороший повод сделать RBAC нормально:

• owner / director
• accountant
• sales_manager
• content_manager
• support
• integration_service

Минимум, что нужно добавить: матрицу прав, аудит действий и запрет на общий логин “admin”. Если потом будет спор по возврату, скидке, удалению заказа или ручной правке платежа, журнал действий спасает больше, чем любые воспоминания команды.

Что это значит на практике

Если вы владелец интернет-магазина. Не считайте миграцию закрытой после регистрации ООО. Пока не обновлены БД, платежи, документы, публичные реквизиты и интеграции, ваш переезд юридически состоялся, а технически — нет.

Если вы разработчик на аутсорсе. Продавайте это не как “поменяем реквизиты”, а как отдельный migration project: audit, schema refactor, integrations cutover, rollback plan, post-release verification. Иначе вас же потом позовут тушить пожар бесплатно.

Если вы PM или CTO. Закладывайте отдельный бюджет на тестовый контур, двойной прогон платежей, smoke-тесты checkout, сверку исторических заказов и проверку документов. Самая дорогая ошибка здесь — не сломанный endpoint, а незаметно испорченная учетная история.

Если вы работаете с персональными данными покупателей. После смены оператора проверьте политику, формы согласий, шаблоны ответов по запросам субъектов данных и внутренние регламенты. Закон № 99-З тут не декоративный. Уточняйте актуальность процедур по официальным источникам, если у вас нестандартная схема хранения или несколько операторов.

Чек-лист миграции

Перед релизом я бы прогнал такой список:

• создана новая сущность юрлица в БД;
• магазин привязан к ней через период действия, а не “навсегда одним полем”;
• старые заказы сохраняют исторический snapshot реквизитов;
• новые заказы создаются уже под ООО;
• платежные ключи и webhook secrets перевыпущены или подтверждены;
• ERP/CRM/1С принимают новый legalContext;
• чеки, счета, акты и email-шаблоны обновлены;
• сайт, оферта и политика данных показывают нового оператора;
• записи в торговых и партнерских кабинетах проверены;
• админка переведена на ролевую модель;
• есть rollback plan;
• есть post-migration reconciliation по заказам, оплатам и возвратам.

Если упростить до одной мысли, то переезд магазина с ИП на ООО — это не rename. Это разрыв старой архитектурной гипотезы, где “бизнес = один человек = один набор реквизитов = одна админка”. В 2026 году такая модель уже слишком хрупкая для нормального e-commerce в Беларуси. Если нужно пройти такую миграцию без грязи в данных и без сюрпризов на проде — пишите в Telegram или через velutich.com.