Headless Bitrix cart and checkout: five things we didn't see coming
The catalog took nine days in Next.js. The cart integration took a month. Checkout took another seven weeks.
How to move an e-commerce storefront to Next.js while the catalog, cart and 1C exchange stay on Bitrix. Notes on rewrite versus staged migration, redirects, auth, stock sync and deploying two independent parts.
31 articles
The catalog took nine days in Next.js. The cart integration took a month. Checkout took another seven weeks.
Before a large Bitrix/PHP rewrite, test the risk on a small slice: catalog, search, API, Core Web Vitals, SEO and integrations.
A rewrite rarely starts with architecture. It usually starts with a sentence: "we cannot keep developing the current site anymore."
When someone says “we need a rewrite,” they usually aren't describing the work yet.
When someone asks me, "How much would it cost to rewrite our Bitrix site on a normal stack?", I rarely answer with a number in the first message.
When a project already hurts, the natural request is: "Give us an estimate for the whole rewrite."
When someone comes to me with "we want to rewrite our 1C-Bitrix store on Next.js", I do not start with a price.
We spent two weeks asking "what does this method actually return?" when we moved a 28,000-product catalog to a headless architecture. Open the Bitrix REST docs — they're three months behind the actual version. Open the debugger, call the method, look at the real response, infer the shape, write an interface. Next day, a teammate does the same with another method. Slightly different assumptions.
One PHP backend. Two Next.js frontends. Two domains. Two brands.
Every failed headless pitch I've seen used the same line.
We went headless in February. In April, our SEO consultant sent a spreadsheet: 340 broken links. Three years of redirect rules, gone the day we deployed Next.js. No errors in the logs. Next.js had no idea these rules were supposed to exist in the first place.
We launched headless Bitrix + Next.js. LCP got worse.
A client messaged me last year. 30,000 SKU store on Bitrix, "everything's slow," ready to migrate to headless. I asked three questions: what percentage of requests take more than two seconds? Is composite mode enabled? When did you last check slow_query_log?
We moved a 28,000-product catalog to Next.js. The first two days after deploy were about CSS and performance. On day three, a ticket arrived: "Authenticated users see the login form instead of their account."
Three warehouses. 28,000 SKUs. A promise to the client: real-time stock data.
Bitrix upgrade lifecycle planning isn't something most teams think about at project kickoff. They think about it when a security advisory lands in their inbox on a Friday afternoon.
I walked into the project with a bias.
When a client says "we're going headless," the first question isn't "which framework." It's: what actually stays on Bitrix?
The first question I get about headless Bitrix is about architecture. The second is about deployment. The third nobody asks out loud — but everyone runs into it in the first week: how do you actually develop when you don't have Bitrix on your machine?
In a headless Bitrix + Next.js architecture, the split is straightforward in theory: Bitrix owns the data and business logic, Next.js owns the rendering. In practice, most teams get this wrong within the first year.
I've spent more time with Bitrix REST API than I expected. Not because the API is broken. Because the documentation covers syntax, not behavior.
The complaint came on day three after the headless launch. A store manager updated a price in Bitrix at 10:47. A customer added the product to their cart at 11:20 — at the old price. The Next.js page was cached for one hour.
We went headless. The frontend started deploying in 3 minutes. The backend didn't.
The first question I ask before any proposal: "Who's editing content after we're done, and where?"
In the past two years I've turned down headless three times. Not because I don't believe in it — I've built it, I know what it delivers. But each time, five questions made the answer obvious before we touched a wireframe. The fourth client got the full Next.js + Bitrix split. It's one of the best ecommerce projects I've worked on.
I build headless sites on Next.js + Bitrix. I've migrated a catalog of 28,000 SKUs. I turned down a $40K contract because rewriting a working monolith made no sense. And when a client walks in asking for headless, my first question is always: "Why headless, exactly?"
A client came to me with a request: "We need to rewrite the backend. It's old." I asked: "What specifically is broken?" Pause. "Well... it's old."
Three years ago a client messaged me: we found a critical vulnerability in the payment module. How soon can we update Bitrix?
Every third conversation about Bitrix starts with "it's slow." I stopped arguing. I ask to see the profiler instead.
The call was straightforward. A client wanted their Bitrix shop rewritten from scratch.
How do you modernize a 28,000-product 1C-Bitrix store without a risky rewrite? In this case study, I break down a Headless migration using Next.js + Elasticsearch that improved performance, preserved SEO, and kept the business running.