How to transfer the store content from Magento 1

Question

Accepted Answer

Owners, executive figures, temporarily hired maintainers of Magento-based stores can use the freely available software toolset labeled with a clear identification name of Data Migration Tool. Sometimes it is a handy piece for vast relocation of the content available in the store in any form.

The executive specialist can use it for any existing store based on Adobe's widely popular Magento 1 that has reached its end of life. The store can be conveniently relocated to any major supported Magento release, which is currently 2.XX.XX.

This programmatic utensil is based on the command line interface (CLI), executed on the server. It confirms the content solidity when the transfer is physically conducted from an old platform to a new one.

During its work, the discussed piece makes verifications for the solidity of information elements, controls the process of information being transferred, writes logs. It additionally does some tests at the end to confirm that the massive process has been completed without any problems.

The aforementioned utensil can be operated in several modes:

Settings. In this mode, a tool is used for relocating configurations.
Data. Makes a database bulk migration.
Delta. It can be used for transferring incremental information additions that were added while the utensil was executed in two previous modes.

Every mode comprises a few necessary stages necessary for actions explicit to the mode. Namely, these tasks can be URL modifies, settings, etc.

Each stage at first checks the integrity of the main components - data and the structure. These components are checked for Magento 1 and Magento 2 to verify the information can be migrated, and if possible, the migration process starts. At this point, the Tool actually examines the amount of information moved.

STEP 1. Checking

Before beginning relocation from one version to another, please ensure the accompanying necessities given below are met.

Magento 2 is deployed. Install Magento2 software on the server.
Cron. Check that Cron jobs are stopped and avoid launching new ones.
Database. Make a backup of a database for freshly installed Magento 2. This step is crucial since it allows to quickly restore the initial state in case migration encounters errors.
Network access is available for the Data Migration Tool to be able to make connections to the databases of Magento 1 and Magento 2. This might require configuring the server firewall to open the corresponding ports.
For all used MySQL accounts, ensure the availability of required database access privileges. On the off chance that Binary Logging is empowered for a Magento 1, set the global MySQL system variable log_bin_trust_function_creators to 1. Alternatively, set the SUPER access privilege for the account.

Note: Try to avoid making new data substances (items, classifications, credits, and so on) in a Magento 2 store before the relocation is finished. This recommendation stems from the fact that the Data Migration Tool overwrites such new elements with those that already exist in Magento 1.

STEP 2. Working with the tool for migration

Install this tool

Verify that the version numbers match both the ecommerce platform and the migration instrument.

Getting a version of the ecommerce framework is rather easy and can be done in several ways depending on how the package was obtained:

Composer

In the event that a store admin downloaded the Magento package utilizing a Composer metapackage functionality, the version of the package could be obtained as php <magento_root>/bin/magento --version

GitHub

If the package was cloned using an available repository in GitHub, its version can be displayed via commands:

cd <Magento 2 clone directory>
git branch

Branch Develop should be changed to Released before proceeding.

In case that the Magento was not introduced onto the server yet, deploy it now. Assuming that this is done by downloading its copy from the available source at GitHub, make sure the checkout tag has been viewed.

Download the Data Migration Tool

In browser, navigate to the page Releases. Discover the appropriate release version.

Next, get a copy on the local drive and install it. This can be done in several ways:

Repo.magento.com

Refresh the composer.json to the latest version. This file is located in the root folder.

After the manager logs in to the server, he should have the owner level of rights to continue. On the next step, move to the root folder and execute:

composer config repositories.magento composer https://repo.magento.com
composer require magento/<data-migration-tool>:<version>

Replace with the exact version number the current ecommerce platform installation has.

During the execution of these commands, a system will require the authentication keys. Type the username as a public key and the password as a private key.

From GitHub

In case the Magento software was obtained by cloning from GitHub, it is easier to continue Data Migration Tool installation with the required version from this exact software source.

A store manager should have the owner level of rights when logged into the server. In the root directory, he should execute the following command:

composer config repositories.<data-migration-tool> git https://github.com/magento/<data-migration-tool>
composer require magento/<data-migration-tool>:<version>

Replace the version with the exact version number of the ecommerce installation.

Check the version

Switch to the location of <data-migration-tool> that is typically located by the path such as <vendor>/magento/.

Use a text editor for editing the composer.json file which contains, the version entry.

Upgrade the Tool

To ensure the version numbers match precisely, often the Tool must go through an update. But do not rush, and the store manager must manually perform maintenance before performing the update action:

Ensure the ecommerce platform is the most recent.
Backup the <data-migration-tool>.
All versions should match.

Migration Tool Backup

Before launching the update for the Tool make a backup of its existing files. This means to copy the <data-migration-tool> folder.

In case it is necessary, an entire Magento codebase and database can be backed up with

php <magento_root>/bin/magento setup:backup --code --db

How to upgrade Data Migration Tool

After logging in to the server, a store manager should have the owner level of rights to be able to continue. Then he should navigate to the root directory. In the terminal execute:

composer require magento/<data-migration-tool>:<version>

Replace the with the exact version number of installed Magento 2. For example:

composer require magento/<data-migration-tool>:2.1.2

How to configure a data migration

Overview of the Data Migration Tool configuration

When the Migration Tool is installed, the following directory contains all the files required for mapping and configuration:

<install dir>/vendor/magento/<data-migration-tool>/etc/opensource-to-opensource in case of Open Source to Open Source migration
<install dir>/vendor/magento/<data-migration-tool>/etc/opensource-to-commerce in case of Open Source to Adobe Commerce migration.
<install dir>/vendor/magento/<data-migration-tool>/etc/commerce-to-commerce in case of Adobe Commerce to Adobe Commerce migration.

Configuring the data migration

Make a setup in two ways:

Do it in a recommended way as an individual extension. In the terminal make the navigational actions in order to switch to the <install dir>/vendor/magento/<data-migration-tool>/etc/. The next step will be making some edits to those files located here.

Do it if the intention for the Data Migration Tool is strictly local use. A new module must be created for this purpose. Edit the file <install dir>/app/code/Vendor/Migration/composer.json:

{
    "name": "vendor/migration",
    "description": "Providing config for migration",
    "config": {
        "sort-packages": true
    },
    "require": {
        "magento/framework": "*",
        "magento/<data-migration-tool>": "*"
    },
    "type": "magento2-module",
    "autoload": {
        "files": [
            "registration.php"
        ],
        "psr-4": {
            "Vendor\\Migration\\": ""
        }
    },
    "version": "1.0.0"
}

Next is a file used for registration with the location <install dir>/app/code/Vendor/Migration/registration.php:

<?php

\Magento\Framework\Component\ComponentRegistrar::register(
    \Magento\Framework\Component\ComponentRegistrar::MODULE,
    'Vendor_Migration',
    __DIR__
);

When finished with a previous step proceed with the <install dir>/app/code/Vendor/Migration/etc/module.xml:

<?xml version="1.0"?>

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
    <module name="Vendor_Migration" setup_version="1.0.0">
        <sequence>
            <module name="Magento_DataMigrationTool"/>
        </sequence>
    </module>
</config>

The configuration file config.xml.dist should be copied from the default directory (<install dir>/<vendor>/magento/<data-migration-tool>/etc/<migration edition>/<version>) into active directory of the current installation <install dir>/app/code/<Vendor>/Migration/etc/<migration edition>/<version>/config.xml.

Set the required access data that is used to get access to the database for both source and recipient Magento installations, including the encryption key. Do this in the config.xml file.

Map source Magento configuration files that are regarded to store customizations.

Configure migration

Before any data can be transferred, a config.xml should be created. Use the provided example to obtain this file.

In the terminal with the owner rights, navigate to /vendor/magento//etc// and make this file with cp config.xml.dist config.xml.

Use any text editor currently available on the server and check that it includes the keys for database access for both source and recipient Magento installations:

<source>
   <database host="127.0.0.1" name="magento1" user="root"/>
</source>
<destination>
   <database host="127.0.0.1" name="magento2" user="root"/>
</destination>
<options>
   <crypt_key />
</options>

Optionally configure such details as table prefixes.

Use TLS at the stage when the configuration is made

A specific connection can be requested in the middle of the launched transfer process. It is requested to obtain access to the database of the online system which is utilized in the store. The request should be fulfilled. The access can be introduced through the means of the TLS protocol when the keys are specified.

It can be freely utilized during this process if the mandatory data on the SSL connection is added to the database.

The amount of the required information is not huge, but the ssl_ca is a must-have piece.

Obviously, to the subject of making the association, it can't be set up without having the ssl_cert field in the config. So, at last, make some efforts and do not forget to fill in the ssl_key.

Customized store

A store manager can make some custom mapping from one database to another. The functionality includes:

Changing table names
Changing field names
Ignoring tables or fields
Adapt data to Magento 2 format

The mapping is fully ready for configuration in the specific files. Those documents can be found in /<data-migration-tool>/etc folder. They should be transferred manually or in any other way to the <install dir>/app/code/Vendor/Migration/etc/<migration edition>/<version> folder.

Do all the necessary actions for copying after the currently present extension was removed.

Edit the configuration config.xml file in the section with manually making all necessary interventions to update the information contained inside to represent actual file paths for the changed places. This looks at the set of records discussed in the past segments.

The refreshed fields containing general way information for the moved documents can have various formats. They can be put in one of the formats: as an absolute (/var/www/html/app/code/Vendor/Migration/etc/opensource-to-opensource/1.9.4.1/map.xml), module relative (etc/opensource-to-opensource/1.9.4.1/map.xml), or root-relative (app/code/Vendor/Migration/etc/opensource-to-opensource/1.9.4.1/map.xml).

In some cases, the information made by custom code in Magento 1 does not match the format of Magento 2. Use the extension points of the Tool to relocate such information. Assuming that the information organization is something similar, the software can naturally move the information without any hassle.

In the end of this story, it is nececcary to admit that a store owner can greatly increase the functionality of his ecommerce business with Magento 2 extensions.