Joomla to 1C-Bitrix Migration: Step-by-Step Guide and Timelines

Migration from Joomla to 1C-Bitrix: Step-by-Step Guide and Timelines

Joomla is a versatile CMS with a flexible extension structure. Most sites on it are corporate portals, news outlets, or catalogs without full-fledged commerce. When a business grows and needs a proper online store with 1C, CRM, and ERP integration, they start looking towards Bitrix. The migration task is nontrivial: Joomla lacks a unified data model—everything depends on installed extensions. We handle the full migration cycle: from audit to final testing. We restore structure, SEO, and functionality turnkey.

Why Migration from Joomla to Bitrix Is Complex

The main challenge is the non-standardized data schema of Joomla. The database almost always contains custom extensions—VirtueMart, HikaShop, JEvents, Phoca Gallery. Each stores data in its own tables. For example, VirtueMart uses jos_virtuemart_products, while HikaShop uses jos_hikashop_product. During the audit stage, we map out the extensions and determine which data is critical for transfer.

Audit of the Source Site

Before writing the migration script, we inventory the data. In Joomla, data is stored in tables with a prefix (usually jos_ or custom):

• Articles — jos_content, fields: title, alias, introtext, fulltext, catid, created, modified, metadesc, metakey, images (JSON).
• Categories — jos_categories (shared table for all content types, filter by extension = 'com_content').
• Users — jos_users, jos_user_profiles, jos_usergroups.
• Menu — jos_menu, jos_menu_types.
• Tags — jos_tags, jos_contentitem_tag_map.

If VirtueMart is present—separate tables jos_virtuemart_products, jos_virtuemart_product_prices, jos_virtuemart_categories. If HikaShop—its own jos_hikashop_product. We determine this during the audit and build a migration plan for the specific configuration.

Data Structure in Bitrix

Joomla news articles and static pages are migrated to information blocks (b_iblock_element). For a corporate site, we usually create information blocks "News", "Articles", "Blog" with the necessary properties. Joomla categories → information block sections (b_iblock_section).

If Joomla ran VirtueMart and you need to transfer to a Bitrix online store, the approach is similar to migrating from OpenCart: products go to the catalog information block, prices to b_catalog_price.

Joomla menu items are converted to Bitrix menu items using the bitrix:menu component—the structure is stored in .menu.php files in site directories.

How to Transfer Content Without Loss

The bulk of the data is articles. The transfer scheme:

1. Read from jos_content JOIN jos_categories — get the article with the category path.
2. Create an information block section via CIBlockSection::Add() if not yet created (keep a mapping of catid → SECTION_ID).
3. Create an information block element via CIBlockElement::Add(): NAME = title, PREVIEW_TEXT = introtext, DETAIL_TEXT = fulltext, CODE = alias, ACTIVE_FROM = created.
4. Meta-tags are written into element properties or via the main module into the table b_iblock_element_property.

Images in Joomla are stored in the images field as JSON: {"image_intro":"images/catalog/photo.jpg","image_fulltext":""}. Parse JSON, download files, register via CFile::SaveFile().

HTML content. Joomla editors often insert non-standard extension shortcodes—{loadmodule mod_name}, {phocagallery ...}, etc. Before migration, we run the content through regex, removing unrecognizable tags or replacing them with Bitrix analogs (embedding components inside text via <?$APPLICATION->IncludeComponent(...)?> is undesirable—better to remove and handle logic separately).

Users

jos_users stores passwords in bcrypt—an algorithm compatible with PHP password_hash(). Bitrix can work with bcrypt if BX_SECURITY_SESSION_CACHE_MODE is configured. However, the standard path is to create users via CUser::Add() with a temporary password and send password reset emails. Joomla groups (jos_usergroups) are mapped to Bitrix groups.

SEO and Redirects

Joomla constructs URLs based on component templates. With SEF enabled, the URL looks like /news/category-alias/article-alias.html or /news/article-alias. Without SEF: /index.php?option=com_content&view=article&id=42&catid=5.

We create a mapping table of old and new URLs. For each article, the old URL is determined by alias and the category path. The new URL in Bitrix depends on the SEF settings of the component. Redirects are set up via UrlRewriter::add() or in the web server config.

Special attention goes to sitemap.xml and robots.txt. If the site had accumulated SEO weight, we do not change the URL structure without 301 redirects.

Extensions Without Direct Analogs

What's Included in the Migration Service

We provide a full package:

• Detailed audit of the current CMS and extensions.
• Data transfer scheme: which tables are mapped, which require custom handling.
• Migration scripts (PHP console commands) tested on a copy of the site.
• Transfer of images, media files, and their attachment to elements.
• Setup of SEO redirects (301) for all pages.
• Transfer of users with access groups.
• Final testing and training for your team on working with Bitrix.

Timelines

The timeline increases if Joomla had VirtueMart with a large catalog (over 5000 products) or many non-standard extensions with their own tables.

We guarantee data integrity and a transparent process. We can assess your project for free—contact us, and our engineer will conduct an audit within one day.

According to the official Bitrix documentation, information blocks v2.0 support up to 16 million elements—enough for large catalogs. Our experience confirms stability under loads of up to 100,000 products with the trade catalog enabled.

Why URL Structure Matters in Bitrix Migration?

Skipping URL mapping during a website migration to Bitrix crashes organic traffic by 50–80% in two weeks. WordPress uses /product/item-name/, OpenCart uses /index.php?route=product/product&product_id=123, Bitrix defaults to /catalog/section/element/. Without a 301 redirect map, search engines index mass 404s. We start every migration with Screaming Frog scanning the old site, then compile a complete redirect map before writing a single line of code. Proper migration requires full URL mapping — every indexed page gets a correspondent.

Over seven years we have completed 50+ projects: landing pages, catalogs with 300,000 products, e‑commerce stores. Typical duration 2–8 weeks. Contact us for a free project estimate within one day.

How Migration Preserves SEO Positions

Losing organic traffic is the biggest fear, and it's justified. Here is how we avoid it.

• URL mapping 1:1 — where possible, via CUrlRewriter and infoblock SEF settings we keep the exact structure. When impossible — 301 redirect. Auto‑generation of redirect map: parse Screaming Frog export, match with new element slugs, generate nginx config. Each redirect verified with curl -I after switching.
• Transfer of meta tags — title, description, h1 moved into properties ELEMENT_META_TITLE and ELEMENT_META_DESCRIPTION. Canonical via Bitrix SEO component. Duplicates cut: www/non‑www, http/https, sorting parameters. Sitemap: new sitemap.xml generated by Bitrix seo module, submitted to Search Console immediately after DNS switch.
• Speed comparison — Bitrix processes a catalog of 100,000 products 3x faster than OpenCart due to tagged caching and query optimization for b_catalog_product.

What Data Gets Transferred?

Content — pages, articles, news → information infoblocks. Catalog: categories → sections, products → elements linked to b_catalog_product, properties → infoblock properties or highload directories. Images, reviews, FAQ.

E‑commerce — products with trade offers (SKUs), prices in b_catalog_price (multi‑currency via b_catalog_currency), stock balances b_catalog_store_product, discounts (b_sale_discount), order history (b_sale_order + b_sale_basket).

Users — client base b_user plus custom UF fields. Passwords are hashed differently: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. We write a custom CUser::LoginByHash with fallback to old algorithm — client enters password once, system rehashes to Bitrix bcrypt.

SEO data — meta tags, alt attributes, URL structure. Main task: preserve every indexed URL or set 301.

Media — images, documents, videos — transferred preserving paths and optimized via CFile::MakeFileArray().

How to Plan a Successful Migration: 5 Key Steps

1. Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
2. Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
3. Migration scripts — PHP scripts read from old DB (or API), transform and write via Bitrix API (CIBlockElement::Add, \Bitrix\Sale\Order::create). Re‑run during testing.
4. Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
5. Final migration & switching — delta import, DNS switch, monitoring.

Typical Migration Mistakes and How to Avoid Them

Each of these errors has caused loss of positions and clients.

• Loss of URLs without redirects — the most destructive mistake. /product/123 instead of /catalog/item-name.html — without 301 this means mass 404s and traffic collapse. We auto‑generate the map and verify every redirect after switching.
• Content duplication — one product accessible with and without www, via HTTP and HTTPS, with GET filter parameters → five URLs instead of one. SEO weight dilutes. Set up canonical, 301 for variants, robots.txt with Disallow for parameters.
• Broken images — absolute URLs in content (src="https://old-site.ru/img/photo.jpg"), quality loss during compression. Replace with relative paths, transfer preserving structure, check HTTP 200 for each file.
• Loss of meta tags and microdata — title, description, Schema.org may not transfer. Do full mapping and verify on staging.
• Broken forms and integrations — changed IDs, API keys, webhooks. Compile integration register before start and test each after.
• Mobile version — old m.site.ru → responsive Bitrix. Without mobile URL redirect → 404 for mobile users. Include in redirect map.

Timelines and Cost Savings

Businesses typically save $3,000–$8,000 annually after migration — no old CMS license fees, reduced plugin and hosting costs. Annual hosting savings alone can reach $1,200. Add the affordable licensing cost of 1C‑Bitrix — it pays off quickly.

Contact us for a free migration estimate. We also provide a preliminary calculation within one day — request a consultation with our Bitrix specialists.