Данные и ETL
Новая предметная модель в PostgreSQL, явный mapping источника и цели, управляемый перенос и автоматические проверки полноты.
[ ЗАМЕНА 1С-БИТРИКС · ДЛЯ IT-КОМАНД ]
Новый e-commerce-контур с доказуемым parity — за 3 месяца
Проектируем новую модель данных и backend, создаём ETL, воспроизводим необходимые API и интеграции, обновляем web, mobile, CMS, PIM и OMS. Границы, критерии готовности, срок и стоимость фиксируем до старта.
Не мигрируем PHP-код. Переносим домен и контракты
Ценность legacy-системы находится не в устройстве Битрикса, а в данных, бизнес-правилах и внешнем поведении. Поэтому мы извлекаем предметную область: сущности, статусы, процессы, API, интеграционные контракты и критичные сценарии.
Затем проектируем целевую систему без наследования внутренней архитектуры платформы.
Снаружи — зафиксированные контракты. Внутри — новая предметная модель и чистая реализация.
[ ГРАНИЦЫ МИГРАЦИИ ]
Что оставляем контрактом, а что пересобираем
Сохраняем и проверяем: необходимые данные и связи, взаимодействие с 1С и смежными системами, публичные и клиентские API, критичные пользовательские и операторские сценарии, значимые статусы и побочные эффекты.
Пересобираем: схему данных, backend, кастомную бизнес-логику, frontend на шаблонах Битрикса, mobile при необходимости, CMS, PIM, OMS и административные интерфейсы.
Parity ограничен согласованным scope: до старта явно фиксируем, что должно совпасть, а что осознанно меняется.
[ ТЕХНИЧЕСКИЙ РЕЗУЛЬТАТ ]
Данные и ETL
Новая предметная модель в PostgreSQL, явный mapping источника и цели, управляемый перенос и автоматические проверки полноты.
API и BFF
Совместимый backend for frontend для сохранённого web или mobile: endpoints, структуры данных, ошибки и критичные цепочки вызовов.
Интеграции
Контракты с 1С и внешними системами повторяем like-for-like либо перепроектируем как отдельное согласованное решение.
Backend
Registry CRUDL для типовых ресурсов, extension-owned services для составных операций и явные state models для статусов.
Web и mobile
Сохраняем отделённый frontend или создаём новый на React и Next.js; действующее приложение сохраняем по API или заменяем на Flutter.
CMS, PIM и OMS
Разделяем контуры ответственности и проектируем schema-driven admin под реальные процессы контент-менеджеров и операторов.
[ PARITY ]
Миграция данных с доказуемым результатом
- Разворачиваем дамп Битрикса и анализируем фактические таблицы, поля, связи и данные.
- Отделяем предметную область от технических структур платформы.
- Проектируем целевую модель в PostgreSQL: связи, ограничения, JSONB для вариативных структур, FSM для статусов и идемпотентность для чувствительных операций.
- Фиксируем mapping каждой переносимой сущности и осознанные исключения.
- Создаём ETL для финального переноса актуальных данных.
- Автоматически проверяем необходимые сущности, поля, записи, связи и доменные инварианты.
Интеграционный периметр
Для каждого обмена фиксируем направление, формат, trigger или расписание, правила ошибок и ожидаемые побочные эффекты.
- Like-for-like, если смежная система не должна заметить замену.
- Тот же контракт, новая реализация, если внутренний механизм можно упростить.
- Новый контракт, если текущая интеграция неэффективна и изменение согласовано с владельцами систем.
Синхронную доменную логику держим в extension-owned services. Импорты, экспорты и обмены с требованиями к retry, replay, idempotency и audit реализуем как durable workflows или через connector packages.
[ АРХИТЕКТУРНЫЕ ПРИНЦИПЫ ]
Скорость из архитектуры, а не из героизма
AI-агенты работают внутри заранее определённых контрактов и архитектурных рельсов. Типовой инфраструктурный код генерируется из декларативной модели, а команда концентрируется на домене и уникальном поведении.
CRUDL first
Стандартные ресурсы, списки, формы, фильтры, связи, права и audit описываются декларативно.
Явная бизнес-логика
Multi-table writes, команды и сложные переходы принадлежат сервисам домена, а не случайным route handlers.
Долговечные интеграции
Внешние процессы с retry, replay и idempotency получают workflow или connector boundary.
Spec-Driven Development
Markdown-спецификации, критерии приёмки и тесты определяют, что строим и как доказываем готовность.
CRUDL first
Стандартные ресурсы, списки, формы, фильтры, связи, права и audit описываются декларативно.
Явная бизнес-логика
Multi-table writes, команды и сложные переходы принадлежат сервисам домена, а не случайным route handlers.
Долговечные интеграции
Внешние процессы с retry, replay и idempotency получают workflow или connector boundary.
Spec-Driven Development
Markdown-спецификации, критерии приёмки и тесты определяют, что строим и как доказываем готовность.
[ ОПЫТ ]
Продуктовая и инженерная школа Surf
15 лет создаём сложные digital-продукты для e-commerce, food, fashion, grocery, книг, DIY и аптек. Берём ответственность за весь контур: архитектуру, backend, web, mobile, дизайн, данные и интеграции.
Технический процесс замены
[ 01 ]
Инвентаризация
Дамп, схема интеграций, frontend, mobile, API и критичные бизнес-сценарии.
[ 02 ]
Контракт миграции
Scope parity, mapping данных, критерии приёмки и осознанные изменения.
[ 03 ]
Целевая модель
Предметная схема PostgreSQL, ресурсы, статусы и архитектурные границы.
[ 04 ]
API и интеграции
BFF, внешние контракты, services, workflows и connector boundaries.
[ 05 ]
ETL и проверки
Перенос данных и автоматическое доказательство полноты и инвариантов.
[ 06 ]
Web, mobile и admin
Реализация выбранной стратегии frontend, приложения, CMS, PIM и OMS.
[ 07 ]
Сквозные тесты
API, интеграционные и пользовательские сценарии по критериям готовности.
[ 08 ]
Cutover
Финальный перенос актуальных данных и переключение на целевую систему.
[ DESIGN + ENGINEERING ]
Дизайн тоже становится частью спецификации
Исследование e-commerce-бенчмарков и лучших референсов превращаем в пользовательские флоу и проверяемые продуктовые гипотезы.
Исследование → интерактивная концепция → дизайн-система → Markdown-спецификации → критерии приёмки → аналитика.
Дизайн создаём как адаптивный интерфейс в коде. Команда сразу видит реальные состояния, переходы, контент и анимации, а разработка получает компонентную основу без отдельного этапа переноса статичных макетов.
AI здесь не заменяет архитектуру и тестирование: агент реализует ограниченную спецификацией задачу, а готовность подтверждается детерминированными проверками.
[ СТЕК ]
На чём строим
Backend: Python, FastAPI, Mini, PostgreSQL 18, Redis
Web: React, Next.js, shadcn/ui
Mobile: Flutter
Поиск и данные: Elasticsearch, ClickHouse
Продуктовые интеграции: Mindbox, Яндекс.Метрика, AppMetrica, GA4, Firebase и сервисы конкретного контура
Трёхмесячный fixed scope возможен только при явно зафиксированных границах: данные, API, интеграции, пользовательские сценарии, нефункциональные требования, критерии приёмки и cutover-план.
[ FAQ ]
Технические вопросы о замене 1С-Битрикс
Нет. Базовый периметр — замена 1С-Битрикс. Интеграцию с 1С воспроизводим по текущему контракту либо перепроектируем как отдельное согласованное изменение.
Да, если он отделён от шаблонизаторов Битрикса и работает через API. Создадим совместимый BFF и подтвердим критичные контракты API-тестами.
Через явный mapping источника и цели, автоматические проверки сущностей, полей, записей, связей и доменных инвариантов. Набор доказательств входит в критерии готовности.
Только там, где изменение контракта создаёт риск для смежных систем. Неэффективный обмен можно перепроектировать, но как отдельное решение с новыми критериями приёмки.
Потому что перенос внутренней реализации сохраняет исходную сложность. Мы переносим домен, данные и необходимые внешние контракты, а внутреннюю архитектуру проектируем заново.
Обычные ресурсы, формы, списки, фильтры и связи остаются в registry CRUDL. Составные операции, multi-table writes и внешние эффекты реализуются в extension-owned services и открываются через явные контракты.
До старта согласуем mapping данных, список API и интеграций, frontend/mobile-стратегию, состав CMS/PIM/OMS, сквозные сценарии, нефункциональные требования и критерии приёмки.
Разработка
Услуги
Технологии