Legacy · Bitrix24 · strangler migration
Rewriting the deal-processing core without stopping sales
Client:
Automotive marketplace, NDA
Category: Legacy
Stack: PHP 8.3, Bitrix24 D7, 1C (HTTP API), feature flags, CLI parity tests, cron
Timeline: about 2 months, in stages
Problem
Deal processing — from the preliminary contract to vehicle handover — rested on a legacy script where building the 1C package alone took about 2,500 lines. Any change risked halting sales at every dealership, and there were no tests.
Constraints
Sales cannot stop even for an hour; the legacy code keeps changing in parallel with the migration; test submissions to the production 1C are forbidden — comparison is read-only.
What I did
- Six deal-card buttons, the approval pages and pre-checks moved into the new module in slices, each behind its own flag
- Shadow comparison: on a live submission, the new code builds the package in parallel while legacy still sends it; any mismatch is logged with a structured diff
- Parity tests against legacy: 812 checks across pipelines, 787 on button permissions, and a drift watchdog tracking the md5 of 49 legacy files
- Three-position flags "everyone / pilot / nobody" and one-command rollback — for a feature, an employee or the whole pilot
- The port caught up with legacy on the second pipeline — used cars — and on every change made to legacy during the migration
Architecture
A flag on every request
→ New module or legacy
→ Shadow package comparison
→ 1C client
→ Parity tests and drift watchdog
Result
The new core is ready and is being rolled out to production by flags in September 2026: shadow comparison matched on 468 of 468 submissions, parity tests are green, and the old code remains a fallback until the full switchover.
What can be reused
Strangler scheme with "everyone / pilot / nobody" flags
Shadow comparison of new code on live traffic
md5-based legacy drift watchdog