You are moving your site from DLE to 1С-Bitrix, and users complain about broken URLs, missing comments, or a non-working login. DLE is a popular engine for news portals, but its architecture is outdated: MD5 password hashes, a flat database structure, and no built-in support for trade catalogs. The DLE migration to Bitrix is complex, but it opens access to the flexibility of infoblocks, REST API, and integration with 1С via CommerceML. Our team has specialized in 1С-Bitrix development for over 10 years, using ORM and event-driven architecture, with 50+ successful migrations. We handle full 1С-Bitrix migration with guaranteed data integrity. We will assess your project within two business days, no upfront payment.
What problems we solve
Passwords
DLE uses MD5 or SHA256 — Bitrix does not recognize these hashes. A simple replacement will lock out users. We implement a shim module: check the old hash on login, update through CUser::CheckPassword() to the standard format. The user doesn't notice the transition.
SEO URLs
DLE generates URLs like /category/article.html. In Bitrix, the structure is /catalog/article/. Without 301 redirects, you lose up to 70% of traffic. We map old alt_name to new CODE and configure redirects via mod_rewrite or the bitrix:main.urlrewrite component. Meta tags from dle_post_extras are transferred to infoblock SEO properties.
Data volume
With 50,000+ publications, standard SQL queries hang. We use batch insertion via CIBlockElement::Add with disabled events and caching. For high-traffic sites, we implement CDN integration and Redis caching. The ix_sort index and tagged caching (CACHE_TYPE = A) speed up catalog loading by 10 times.
How we do it
Transfer publications to the "News" infoblock. Field mapping:
DLE (dle_post) |
Bitrix (infoblock) |
title |
NAME |
short_story |
PREVIEW_TEXT (html) |
full_story |
DETAIL_TEXT (html) |
date |
ACTIVE_FROM |
alt_name |
CODE |
approve, category |
ACTIVE, IBLOCK_SECTION_ID |
Categories are created first via CIBlockSection::Add(), preserving hierarchy (parentid → IBLOCK_SECTION_ID).
Additional fields (xfields) are parsed from the string format field1|value1||field2|value2 and saved to infoblock properties:
// Парсинг extra_fields из DLE
$extraFields = [];
foreach (explode('||', $row['xfields']) as $pair) {
[$key, $val] = explode('|', $pair, 2);
$extraFields[$key] = $val;
}
In a real project with 20,000 publications, we transferred 150,000 images, rebuilt galleries, and restored category links. Post-migration audit showed only 3% discrepancy — all errors were fixed within a day.
How to handle user migration without data loss?
The DLE user base (dle_users) can contain up to 100,000 records. CUser::Add() in a loop is slow — we optimize by using CLanguage::GetList() and CGroup::GetList() for group caching. Passwords are kept in the PASSWORD field as a temporary hash, and upon login, we check using the old dle_hash() function. After the first password change, the user switches to the standard system. This ensures seamless user migration.
What to do with SEO links after migration?
All old URLs must redirect to new ones. We collect the list from dle_post.alt_name and dle_category.alt_name, generate 301 redirects in .htaccess or configure them in Bitrix via the bitrix:main.urlrewriter.add component. Meta tags are transferred to infoblock properties UF_SEO_TITLE and UF_SEO_DESCRIPTION. Our SEO migration process preserves up to 90% of search engine rankings. For a typical 20,000 post migration, our solution costs $3,500–$4,500, saving 30% over alternative vendors.
Process
-
Analysis — audit of DLE migration data, identification of incompatibilities, volume estimation. We create a field map.
- Design — create infoblocks, properties, sections. Set up tagged caching and 1С integration via CommerceML.
-
Implementation — export/import scripts in PHP 8.1+. Batch loading via
CIBlockElement::Add with disabled events. We use Bitrix D7 ORM, event handlers, and cache engine with Memcached for performance.
-
Testing — verify element counts, authorization, redirects, images.
- Deploy — transfer to production, log monitoring, one week of support.
Speed comparison: Bitrix with configured caching renders a catalog page 7.5 times faster than DLE — 0.2 s vs 1.5 s. A performance comparison was conducted on a typical 8 GB RAM server. On one project, migration reduced page generation time from 3 seconds to 0.3 seconds, directly impacting conversion and behavioral factors.
Estimated timelines
| Volume |
Timeline |
| Up to 5,000 posts, no xfields |
2–4 weeks |
| 5,000–50,000 posts, with users |
5–8 weeks |
| 50,000+, with galleries and comments |
2–4 months |
Prices start at $1,500 for sites with up to 5,000 posts.
Typical migration mistakes from DLE
- No 301 redirects — traffic drop of up to 70%.
- Ignoring xfields — loss of additional data.
- Direct insertion of password hashes — login blocked.
Deliverables
- Full database and file dump (safeguard against data loss).
- Documentation of migration process and access credentials.
- Creation of infoblocks, properties, sections.
- Transfer of posts, users, comments, images.
- Setup of 301 redirects and SEO metadata.
- Administrator training on Bitrix.
- 7 days of technical support after launch.
Example .htaccess redirect rule:
RewriteRule ^category/(.*)\.html$ /catalog/$1/ [R=301,L]
Get a consultation — we will estimate your project within two business days. We guarantee data integrity and transparent reporting at every stage. Our team has over 10 years of experience with Bitrix CMS and DLE, 50+ successful migrations. Order your migration today to avoid losing traffic and users. If you are planning a migration, contact us — we will assess the scope and timeline.
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
-
Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
-
Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
-
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.
-
Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
-
Final migration & switching — delta import, DNS switch, monitoring.
Detailed stage timeline
| Stage |
Duration |
Activities |
| Audit |
1–3 days |
Full site scan, integration register |
| Architecture |
2–5 days |
Infoblock design, field mapping |
| Scripts |
3–10 days |
PHP based migration engine |
| Staging |
1–2 days |
Full dry run, integrity checks |
| 301 redirects |
1–2 days |
Map in .htaccess or nginx.conf |
| Final migration |
1 day |
Delta import, DNS switch |
| Post‑migration |
2–4 weeks |
Monitor Search Console, fix crawl errors |
| Deliverable |
Description |
| Documentation |
Redirect map, mapping description, DB schema |
| Access |
Admin panel, FTP/SSH, API keys |
| Training |
Video tutorials or on‑boarding session |
| Support |
2 weeks post‑migration monitoring, bug fixing |
| Guarantee |
Rollback to old site within 48 hours |
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
| Project type |
Timeline |
Notes |
| Informational site (up to 500 pages) |
2–4 weeks |
Content + design + redirects |
| E‑commerce store (up to 10,000 products) |
4–8 weeks |
Catalog + orders + integrations |
| Large store (100,000+ products) |
2–4 months |
Custom scripts + load testing |
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.