IDETA: Migration of users and orders

What this solution does

The IDETA module for User and Order Migration transfers data from an old website to the 1C-Bitrix platform. It migrates users, groups, user fields, avatars, passwords, and order history. Only one file needs to be uploaded to the old site; the solution is compatible with PHP 7 and the windows-1251 encoding. The migration process is step-by-step, allowing users to pause and resume operations, while a re-run prevents the creation of duplicate records. The client base is transferred along with passwords, enabling users to log in to their personal account on the new site using their existing credentials and view their complete order history.

Transferred data includes:

Users: all profile fields, registration and last login dates, and activity status.

Passwords: hashes are transferred as-is, so users do not need to reset their passwords.

Selective migration: instead of transferring entire groups, you can specify a list of specific IDs, logins, or e-mail addresses. The module will migrate only the specified users and their orders, while logging any users that cannot be found.

The module allows transferring users from multiple groups in a single run. For each source group, you can choose one of three actions: add users to an existing group on the new site, create an identical group, or not assign a group at all.

User fields (UF_*) are supported: string, number, date, date and time, yes or no, list, link, and file. Fields are created automatically, and list values are mapped by XML_ID and name.

Files are transferred: profile photos and logos, as well as files in user fields. Cloud storage files are also supported.

Orders are transferred: cart with item properties, order properties, payment and shipping details, status, cancellation, comments, original dates, and order number.

The old site connects in two ways. The first method uses a dump file: the module on the new site generates a single PHP file, which is uploaded to the old site via FTP. No additional software installation is required on the old site; the file works with older editions of the core and online store in windows-1251 encoding. The second method requires installing the module on both sites; it is suitable if the old site runs on PHP 8.2 or higher and core 23 or higher. Neither method requires the old site administrator password or database access.

Secure data exchange. Each request is signed with a secret key using the HMAC-SHA256 algorithm and remains valid for five minutes. Access can be restricted by IP address. Download files have a limited validity period (default seven days). Changing the key invalidates all previously downloaded files.

The transfer process is step-by-step with resume capability. Data is transferred in batches with a progress indicator. The operation can be paused, the browser tab closed, and resumed later. If the connection is interrupted, the current step is automatically repeated.

The module prevents duplicates: it tracks already transferred users, orders, and files. Re-running the transfer processes only new data.

For existing users, matches are identified by login or email address. A matching account can be left unchanged (with only orders attached) or updated. Administrator accounts on the new site are never modified.

Orders are migrated as historical data. The catalog and stock levels of the new site remain untouched: no reservations are created, no write-offs occur, discounts are not recalculated, and customer emails are not sent. Products are linked to the new site catalog via the XML_ID identifier if found. Payer types, statuses, payment systems, and delivery services are matched automatically. This mapping can be manually adjusted in the wizard. If the new site lacks specific statuses or payment systems, the module creates them automatically (payment systems are created as inactive). Financial data is preserved: unmatched payments are transferred to the default payment system while retaining the amount, the paid status flag, and the original system name.

Re-migrate orders. If the matching process fails, the task includes a button to retry. The module deletes the orders it previously created and migrates them again with the updated settings. Orders created on the site by other means are not affected.

Detailed event log. If a user or order fails to migrate, the log displays the specific record and the reason for the failure. An error on one record does not stop the migration of the remaining data.

This module is suitable for:

Migrating an online store to a new site or a new edition.

Merging multiple sites into one.

Transferring the client base between a test site and a production site in both directions.

Migration limitations

User fields referencing catalogs from the old site (links to InfoBlock elements or sections, employees, etc.) are not migrated. Each such field is logged.

All order items are combined into a single shipment, even if the old site had multiple shipments.

Orders with an unmatched payer type are not migrated.

In older versions of the Online Store (prior to 16.0), orders contained only one payment and one delivery method; these are migrated. Location property values are migrated as-is: if the old site used an ID instead of a location code, these values must be verified.

Order event handlers on the new site (such as 1C exchange, CRM integration, etc.) trigger for every migrated order. Disable them during migration if necessary.

System requirements

PHP version: 8.2 or higher.

Main module: version 23.0 or higher.

Encoding: UTF-8.

Database: MySQL.

Option 1: Export file (compatible with any old site)

1. Install the module on the new site.

2. Open Module Settings and navigate to the Receiver section.

3. Specify the address of the old site and select the option "export file uploaded to source".

Two configuration options are available for data migration. The first method works on any old site: download the export file, upload it to the /bitrix/tools/ directory on the old site via FTP or the hosting file manager, then click the Save and check connection button. Next, open Settings → IDETA: User and Order Migration → New Migration, select the required groups and parameters, and map the relevant reference books if migrating orders. After the process completes, delete the ideta_tu_export.php file from the old site.

The second method is available if the module is installed on both sites, provided the old site runs on PHP version 8.2 or higher and core version 23 or newer. Install the module on both resources. On the old site, go to Module Settings → Source, enable the Allow export option, and copy the generated secret key. On the new site, open Module Settings → Receiver, select the option indicating the module is installed on the source, specify the old site address, paste the key, and click Save and check connection. Start the migration following the first method's procedure. Once the work is finished, disable the export on the old site.

The module has been completely rewritten using D7. Data exchange is performed via a signed API, eliminating the need to log in to the administrative section using a password.

IDETA: User and Order Migration Module

New features include mapping and automatic creation of order statuses and payment systems, with a default payment system assigned to unmatched payments. A button to re-migrate orders has been added.

Users can now be migrated individually by a list of IDs, logins, or email addresses. Existing users can be searched using a chain of keys: login, email, phone, XML_ID, and custom fields.

A dump file format for legacy sites is now supported. Installing the module on the source site is no longer required; the system supports PHP 7.0 and above with windows-1251 encoding.

Migration of orders, files, and avatars has been updated. Group mapping is now supported, allowing multiple groups to be processed in a single run.

Tasks support pausing and resuming, an error log is maintained, and duplicate data creation is prevented.

The administrator password from the old site is no longer stored in the module settings.

General iT can take care of implementing “IDETA: Migration of users and orders”, including installation, configuration and result verification.