1C-Bitrix Development: What Lies Behind Platform Selection
We often observe: the most costly mistake in a Bitrix project is choosing the wrong edition. A client buys "Business" for a significant amount, and six months later it turns out that a multi-regional catalog with personalized prices requires "Business Enterprise." The difference is not only in license cost—it's a different data storage architecture, a different approach to clustering, a different performance ceiling. Migrating between editions on a live project with 80,000 products and 200 orders per day is not just updating a license—it's a full-fledged engineering project taking 3–6 weeks. Saving through correct initial selection can amount to a substantial sum on licenses and migration costs alone. More details about the platform can be found in Wikipedia.
Why Choosing the Bitrix Edition Is a Key Architectural Decision?
Infoblocks—the basis of Bitrix for content storage—have a structural limitation. Each element property is a record in b_iblock_element_property (EAV model), and when filtering a catalog, MySQL builds a JOIN for each property involved in the filter. With 5,000 products, it works. With 50,000, catalog queries start taking 3–8 seconds. With 200,000, the site simply falls under any filter.
Starting from version 17.0, highload-blocks appeared: properties are stored not in an EAV table, but in a separate flat table with columns. Filtering by 10 parameters—one query without JOIN. Highload-blocks are 5–10 times faster than classic infoblocks for filtering on catalogs of over 50,000 products. But they do not support versioning, out-of-the-box SEO properties, and familiar events. The choice between infoblocks and highload is an architectural decision at the start, and redoing it on a live project is more expensive than spending two days on analysis at the beginning.
We start every project with an audit of future load. How many products now and how many in a year. How many concurrent visitors. What filters are needed. Whether multi-warehouse will be used. And from there, we build the architecture, not the other way around.
Typical Pitfalls in Bitrix Online Stores
An online store is the most common request. And the most underestimated in complexity.
The sale module in Bitrix is powerful but confusing. Cart, order, payment, delivery—four subsystems, each with its own API. Since version 17.0, orders have migrated to the new D7 core (\Bitrix\Sale\Order), but half of the marketplace modules still work through the old CSaleOrder. The result is conflicts when customizing the checkout, especially when third-party delivery or payment modules are connected.
A specific example from practice: a client connected the CDEK delivery module and the YuKassa payment module. Individually—they work. Together—under a certain combination (pickup + QR payment), the order was created with zero delivery cost, although the correct amount was displayed on the screen. The reason: both modules overrode the OnSaleComponentOrderResultPrepared handler, and the call order depended on the sorting in b_module_to_module. Fix—half an hour. Finding the cause—two days.
Another systemic issue is the catalog page performance. The standard catalog.section component executes 40 to 120 SQL queries per page, depending on the number of properties, SKUs, and price types. Enabling composite caching helps for anonymous users, but authorized users see personalized prices—and each query goes to the database. We solve this by pre-caching price matrices in Redis and delivering them via AJAX after page load.
How to Avoid Catalog Filter Performance Drops?
Optimized caching in Redis reduces response time by 60% compared to standard file caching. We use tagged caching: when the price or stock of one product changes, only the cache associated with that product is invalidated, not the entire catalog. This is critical for online stores with high update frequency.
| Problem | Standard Solution | Our Solution | Performance Gain |
|---|---|---|---|
| Filtering by properties (50,000+ products) | EAV queries with JOIN | Highload-blocks + indexes | 5–10 times |
| Personalized prices for authorized users | Generation on each request | Cache of price matrices in Redis + AJAX loading | 60% reduction in response time |
| Multiple SQL queries in catalog.section component | Composite cache for anonymous | Custom component with query aggregation | 2–3 times reduction in query count |
Bitrix24, CRM, and Business Process Automation
A separate area is corporate portals and CRM based on Bitrix24. Here, specifics include REST API with limits of 2 requests per second for on-premise versions (50 per second for Enterprise), business processes in the visual editor that breaks on complex branching, and integrations with external services via webhooks.
We often connect Bitrix24 with 1C:Enterprise. Counterparties, invoices, acts—two-way synchronization. The manager works in CRM, accounting in 1C, data does not diverge. Technically, this is REST API + custom handlers on the 1C side, with Redis queues for buffering peak loads.
Implementation Details of 1C Exchange
For synchronization, we use **CommerceML 2.0** via web services. On the Bitrix24 side, we create external handlers on the `OnCrmDealUpdate` event, which form an XML packet and send it to 1C via HTTP. Asynchronous reception is configured on the 1C side to avoid blocking the user interface. This approach handles up to 1000 deals per day without data loss.Security: Not an Option, but a Necessity
The proactive protection module (security) covers basic vectors: WAF, session protection, activity control. But it will not save from vulnerabilities in custom code or outdated marketplace modules. We conduct a separate security audit: check SQL injections in custom components, XSS in templates, CSRF in forms, file access rights on the server.
A common finding is backup files in the public directory. bitrix/backup/ with a full database dump, accessible via direct URL. Or bitrix/.settings.php with the database password, which is served under incorrect nginx configuration.
If you suspect vulnerabilities in your project, order a security audit—we will find and fix them.
Migration, Support, SEO Optimization
Migration to Bitrix from other CMS (WordPress, OpenCart, custom solutions) takes 2 to 8 weeks depending on content volume and logic complexity. It is critical to preserve URL structure and 301 redirects, otherwise SEO positions drop.
Support is not just "fix a bug." Bitrix updates are frequent, and each update can break custom components. We maintain a registry of modifications for each project and check compatibility before updating. For ongoing support of your project, contact us—we will offer the best plan.
SEO in Bitrix is a separate story. The seo module can generate sitemap.xml, manage meta tags and canonical. But for serious SEO, you need work with Schema.org microdata, Core Web Vitals optimization (LCP, CLS, INP), server caching configuration. Standard Bitrix serves HTML with inline styles and scripts, which kills PageSpeed—we rewrite templates for asynchronous loading and move CSS to separate files.
What Is Included in a Bitrix Project
Upon project completion, you receive:
- Technical documentation: solution architecture, description of custom components, deployment instructions.
- Access to the management system, server, and repository (Git).
- Administrator training: adding products, order management, property configuration.
- Warranty support for 1 month after launch—critical bug fixes and consultations.
How We Estimate a Project
Each project starts with an audit of the current state (if an existing site) or requirements analysis (if from scratch). Stages:
- Requirements gathering—what the business needs, integrations, catalog volume
- Technical design—edition selection, data architecture, infrastructure
- Effort estimation—decomposition into specific tasks with hourly estimates
- Development—iterations of 2 weeks with demo after each
- Testing—functional, load, security checks
- Launch and stabilization—first 2–4 weeks post-launch in enhanced monitoring mode
The cost is calculated individually after requirements analysis. Discuss your project with a specialist — get an estimate and a work plan.
| Project Type | Estimated Timeline |
|---|---|
| Corporate website | 3–6 weeks |
| Online store up to 10,000 SKUs | 6–12 weeks |
| Large e-commerce with integrations | 3–6 months |
| Bitrix24 CRM implementation | 2–8 weeks |
| Migration from another CMS | 2–8 weeks |
| Security and performance audit | 3–10 days |
Order an audit of your project—we will determine the edition, architecture, and budget, and you will receive a transparent work plan.