Strangler Fig in Practice: A Category Page Migration, Commit by Commit

Revised English edition, 11 October 2026. This edition focuses on the engineering workflow. Historical project figures are not presented as a forecast or a verified current customer result.

The strangler fig approach replaces a legacy system in stages. Here we look inside the first stage: moving category pages while the rest of a 1C-Bitrix store remains in place. The practical question is what to change, how to measure it and when to stop.

A category-page pilot should be a separate decision. A successful category rollout does not automatically authorize a product-page, basket or checkout migration. Keep the catalog, orders, prices and existing integrations under their established ownership.

Before implementation: define the boundary

Record which routes are in scope, which system serves them now, and which system remains the source of truth. A route such as /catalog/* is a starting boundary, not permission to move every commerce function.

• Inventory category URLs, filters, pagination, sorting and product links.
• Record redirects, canonical tags, titles, descriptions and sitemap entries.
• Document customer-specific prices, warehouse availability and regional rules.
• Choose one decision owner and agree on the rollback trigger.

Capture a baseline before changing routing. Measure response-time percentiles, server errors and the relevant buyer journey. Separate changes caused by the frontend from changes in traffic, stock, promotions or the catalog itself.

Stage 1: introduce a catalog API

Build an API layer that reads the existing backend and returns a stable contract. Typical fields include id, name, slug, price, in_stock, images, attributes and variants.

The mapper is as important as the endpoint. Test nested categories, missing attributes, unavailable variants, regional prices and empty results. Decide how an API failure differs from a genuinely empty category. An error must not silently become an empty product list.

Agree on cache invalidation and freshness. A cache duration is an engineering choice, not a universal promise: stock, contract prices and public category content may need different policies. Document which layer owns each cache and how to inspect the current data version.

Stage 2: reproduce one category on staging

Create the new category view against that contract. Keep the existing design if the pilot is about architecture rather than redesign. Product cards, filters and sorting should behave consistently enough to make the comparison useful.

Preserve the production URL and canonical destination during rollout. A staging host must not become the canonical URL of a production category. Test metadata, pagination and all links, not just the first visible screen.

Use representative fixtures in tests: nested categories, missing images, unavailable products and customer-specific data. Add a smoke check that verifies actual rendered HTML and the links to the existing basket and product pages.

Stage 3: make the two versions comparable

Before assigning real traffic, identify each request and its rollout group. Useful log fields include req_id, endpoint, status, bytes, latency_ms, data_version and rollout_group.

Show legacy and new-frontend metrics side by side. Inspect response-time percentiles, error rate, payload size and throughput. Track the same buyer events on both versions, such as category views, filter use and add-to-cart actions.

Agree on minimum evidence before drawing a conversion conclusion. A small early sample can reveal a broken interaction; it cannot by itself establish a stable revenue uplift. Segment by device, region and traffic source where the sample supports it.

Stage 4: start a limited canary

Use stable assignment so a person does not jump between frontends during one journey. The routing layer must connect that assignment to the correct upstream. A cookie and an HTTP header are different mechanisms: the proxy needs an explicit mapping between them.

Start with the agreed limited share. Watch the first hours, overnight behavior and a representative business period. Check both technical metrics and actual category interactions. Verify that the rollback mechanism works before relying on it during an incident.

Nested categories are a useful failure example. A mapper may work for a flat category yet return an empty list for a deeper branch. Compare payload size and product counts as well as HTTP status; a successful response with the wrong catalog data is still a failure.

Stage 5: increase traffic only when the checks pass

Expand in agreed increments rather than by a calendar alone. Each step needs a decision: continue, hold or roll back. Document incidents and fixes so the same failure does not recur at the next traffic level.

Cold caches can make a release slower even when steady-state performance is good. If warmup is needed, use representative routes and verify the result. Test after deployment, not only against a previously warmed development server.

Stage 6: stabilize and document the handover

Keep the old category route available as the rollback path for the agreed period. Record how routing is changed, how caches are cleared and who can approve the switch. Removing legacy code is a later decision after stable operation.

• Document the API contract and mapper assumptions.
• Explain how to add a category and test special catalog rules.
• Retain the deployment and rollback procedure.
• Compare matched measurement windows before proposing the next stage.

What stays outside this pilot

The basket, checkout, admin interface and ERP synchronization do not need to move with category pages. A redesign and a change to the SEO URL structure also require separate scope. These boundaries make the result attributable and the rollback practical.

Apply the workflow to your store

Start with four questions: which route has a clear buyer problem, whether the backend exposes the required data, whether routing and monitoring support a canary, and who owns the decision. Then agree on the acceptance criteria and price for that scope.

Explore Frontbox for an existing 1C-Bitrix store or review the storefront migration service. Share your catalog and integration constraints before choosing a rollout plan.