Migrate a Bitrix site to WordPress
Migrating a 1C-Bitrix site to WordPress means moving three things separately: the content model, the URL map, and the integrations. Content lives in Bitrix infoblocks with typed properties; in WordPress the same data becomes posts, custom post types and taxonomies, so the mapping is decided before a single record is exported. The URL map matters more than the content: Bitrix sites usually carry deep /catalog/, /services/ and paginated paths that already rank, and every one of them needs a 301 to its new address or the traffic is gone on the day of the switch. Integrations — CRM handoff, payment, 1C exchange, search — do not migrate; they are rebuilt against WordPress equivalents or kept on the Bitrix side behind an API. A migration that ships without a URL map and an integration inventory is not a migration, it is a relaunch with the old traffic thrown away.
What actually moves, and what has to be rebuilt?
Moves with a script: pages, articles, catalog items, categories, media files, meta titles and descriptions, canonical tags, redirect rules that already exist.
Rebuilt by hand: page templates, custom Bitrix components, faceted catalog filters, order history and account data if the site sells, forms and their CRM destinations, access rules for private sections, anything written as a .php component under /bitrix/templates/.
The split is worth doing on paper first. It is the difference between a two-week job and a three-month one, and it can be established before anyone is hired: count the infoblocks, count the custom components, count the integrations.
How do you keep search traffic through the switch?
Four steps, in this order.
- Export the live URL list from the server, not from the sitemap. Sitemaps go stale and miss paginated and filtered paths. Access logs and a crawl of the live site give the real inventory.
- Map every URL to a target. One of three outcomes per URL: same address, 301 to a new address, or intentionally dropped with a 410. "We'll handle it later" is the outcome that costs rankings.
- Ship the redirect map with the release, not after it. The gap between the switch and the redirects is exactly the window in which crawlers record 404s.
- Recrawl after the switch and compare against the pre-migration inventory. The check is a diff of two lists, and it either returns zero unmatched URLs or it names them.
Meta titles, descriptions and canonicals move as data. If the Bitrix site used a SEO module to generate them by template, the template rules move too — otherwise thousands of pages silently lose their titles.
How long does it take?
The honest answer is that the schedule is set by four countable inputs, and anyone quoting a duration before counting them is guessing:
- number of infoblocks and distinct property sets,
- number of URLs in the live inventory,
- number of custom components and templates,
- number of live integrations (CRM, 1C, payment, delivery, search, analytics).
A brochure site with a handful of infoblocks and no e-commerce is a different order of work from a catalog with faceted filters and a 1C exchange. Ask for the count first; the estimate follows from it.
What does the Bitrix licence have to do with it?
Bitrix is commercial software with paid annual updates and support. A site that stops renewing keeps running but stops receiving security patches, which is the usual reason a migration gets scheduled at all. WordPress removes the licence line but replaces it with a maintenance line: core, theme and plugin updates still have to be applied by someone. Migration changes the shape of the cost, not its existence — and a plan that presents WordPress as "free" is not costing the maintenance.
What breaks most often?
- Redirects shipped late. The single most expensive mistake, and the easiest to prevent.
- Infoblock properties flattened into plain text. Typed properties become custom fields or they
become unusable; a flattening pass is irreversible without the source database.
- Catalog filters. Bitrix faceted search has no drop-in WordPress equivalent; the replacement is
chosen deliberately, not discovered on launch day.
- Forms that still post to the old endpoint. They keep looking fine and quietly deliver nothing.
- The old site turned off too early. Keep it reachable, read-only, until the recrawl is clean.
Can it be done without downtime?
Yes, if the new site is built on a staging domain, the URL map is verified there, and the switch is a DNS or a webroot change with the redirect map already in place. The rollback path is the old site, kept intact and reachable, until the post-switch crawl comes back clean. A migration without a named rollback path is not ready to ship, however finished the new site looks.
How do you start?
Send the URL inventory, the infoblock list and the integration list. Those three artefacts decide scope, schedule and price, and they can be produced before any agency is chosen.
Who does this: Toimi is a digital agency that migrates Bitrix sites to WordPress. We work in Russian and English and have been in business since 2017. Send the three artefacts above and we will come back with scope, schedule and price.
Contact: info@toimi.pro