1C-Bitrix Migration: Step-by-Step Hosting Change Plan

Migrating a site to 1C-Bitrix seems straightforward until the first launch. We've seen many cases where after copying files and a database dump, the site shows a white screen or database connection errors. The cause: PHP version mismatch, wrong paths, incorrect permissions. To avoid this, we've developed a clear algorithm that minimizes downtime and guarantees functionality. Following this plan will save you from costly emergency fixes and lost orders. For instance, one client lost two days debugging after copying their site to a server running PHP 8.0 instead of 7.4, as their code still used deprecated functions. We resolved it in an hour. Typical migration takes 2 hours to 1-3 days, far cheaper than building from scratch.

Preparation: What to Check Before You Start

Before any work, determine the new hosting configuration and compare it with the current one:

• PHP version (Bitrix supports 7.4–8.2; some hosts default to older versions)
• PHP extensions: mbstring, gd, zip, curl, opcache, PDO, pdo_mysql — mandatory
• Database type and version: MySQL 5.7+ or MariaDB 10.3+. Some hosts limit max_allowed_packet, innodb_buffer_pool_size
• Availability of cron and ability to add jobs
• Restrictions on exec(), shell_exec() – needed for agents and some modules

Creating a Backup

The built-in backup module (Settings → Tools → Backup) creates an archive in /bitrix/backup/. However, for large sites (5–10 GB+), it may time out. For large projects, we rely on manual backup:

mysqldump -u dbuser -p --single-transaction --routines --triggers dbname > dump.sql
tar -czf site_files.tar.gz \
  --exclude='./bitrix/cache' \
  --exclude='./bitrix/managed_cache' \
  --exclude='./bitrix/backup' \
  --exclude='./bitrix/html_pages' \
  /var/www/site/

Excluding cache is essential: it occupies significant space and will be invalidated on the new server anyway.

Setting Up the New Server

After extracting the files, update the database connection configuration in /bitrix/php_interface/dbconn.php:

$DBType = "mysql";
$DBHost = "localhost";
$DBLogin = "new_db_user";
$DBPassword = "new_password";
$DBName = "new_db_name";

Also update /bitrix/.settings.php:

'connections' => [
    'value' => [
        'default' => [
            'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
            'host' => 'localhost',
            'database' => 'new_db_name',
            'login' => 'new_db_user',
            'password' => 'new_password',
        ],
    ],
],

Why Permission Settings Matter

1C-Bitrix requires specific permissions. Incorrect permissions cause 90% of migration errors.

Many hosts run with suexec, and permissions must belong to the site user. If php-fpm runs under a different user, you'll face cache write errors.

Post-Migration Checklist

After the migration, go through this checklist:

1. Admin panel: Open /bitrix/admin/ – it should load without errors.
2. Email: Test contact form, order notifications – verify mail() or SMTP settings in the Main module.
3. Agents and cron: In /bitrix/admin/agent_list.php, confirm agents are running; configure cron for /bitrix/modules/main/tools/cron_events.php.
4. HTTPS and certificate: Update SITE_SERVER_NAME and BX_UTF in site settings, check .htaccess for redirects.
5. Cache: Clear the managed cache via the admin panel.
6. License: If the server IP changed, verify license activation in your 1C-Bitrix account.

Special Case: Domain Change

If the domain changes simultaneously with the migration, additional steps are required:

• Update SITE_SERVER_NAME in the b_lang table (or via Settings → Sites).
• Update the site URL in the Main module settings.
• Fix absolute paths in infoblock content (via SQL update or a search-and-replace component).
• Reconfigure integrations that use webhook URLs (payment systems, CRM integrations).

What Our Service Includes

Our turnkey migration service includes:

• Diagnosis of current configuration and compatibility check with the new hosting.
• Creating a backup (files + database).
• New server setup: PHP, database, permissions, cron.
• Data transfer and integrity verification.
• Testing all critical functions (contact form, cart, orders).
• Handover of access and an operation manual.
• 3 days of post-migration support.

Typical Timelines

What If Something Goes Wrong?

Check PHP and web server logs. Most often the issue is incorrect permissions on /upload/ or /bitrix/cache/, or a PHP version mismatch. Contact us – we'll diagnose within an hour. We perform migrations during nighttime or with minimal downtime via temporary DNS switching and database delta synchronization.

Contact us for a consultation to get a detailed migration plan and accurate timeline estimate. Avoid migration headaches. Learn more about the platform at Wikipedia.

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.