Migration Tool¶

Used to migrate a Magento 1 website to Magento 2.

Installation¶

Use composer to install the data migration tool

Mapping¶

Session data¶

If you are working on a large site that has many concurrent visitors it is worth considering ignoring the sessions table core_session.

This means the data will will not be ported across and can improve migration speeds considerably. Some sites can hold on to session data in excess of 4GB.

Wildcard ignore¶

You can use wildcards * to ignore multiple documents (tables). For example

<source>
    <document_rules>
    <ignore>
        <document>m_table1</document>
    </ignore>
    <ignore>
        <document>m_table2</document>
    </ignore>
    <ignore>
        <document>m_table3</document>
    </ignore>
    <ignore>
        <document>m_table4</document>
    </ignore>
    </document_rules>
</source>

Becomes

<source>
    <document_rules>
        <ignore>
            <document>m_*</document>
        </ignore>
    </document_rules>
</source>

Commands¶

Setting Migration `migrate:settings`¶

This will migrate all configuration data across to Magento 2, even if there is no module available to consume the data.

Data Migration `migrate:data`¶

Migrates all other data (sales, orders, and so on). This is the most time consuming part of the migration process.

Delta Migration `migrate:delta`¶

To be able to run a delta migration, you must have first run a full data migration. The reason for this is that the data migration modifies the source database and adds a number of tables.

These tables will keep track of what has and has not been migrated, making it easier to keep track and ensure that the delta migration runs faster and does not bottle neck a live Magento 1 site. Source

Note

Delta is not designed to be run outside of the live environment, it uses triggers added to the source database to add identifiers to the migration tables, it then regularly checks these tables for data and migrates the rest of the entities and documents across.

The state of different entities are stored in tables prefixed with m2_cl_ These tables need to exist for delta to work.

This means that if you regularly destroy your source database then you will need to back up these tables before destroying the database.

You can get the list of tables using the following.

mysql -NB -e " SELECT table_name FROM information_schema.tables WHERE table_schema = 'magento1_source_database' AND table_name LIKE 'm2_cl%';"

Using this, you can then dump those tables exclusively using a pipe or variable.

mysql -NB -e " SELECT table_name FROM information_schema.tables WHERE table_schema = 'magento1_source_database' AND table_name LIKE 'm2_cl%';" \
| xargs mysqldump magento1_source_database

Using delta outside of Live¶

To be able to use delta with database dumps as opposed to being run on the live server, you will need to manually populate the migration tables on the Magento 1 source database.

You will need to manually inject the relevant records in to the source database's tables. Source

Delta Data¶

When a delta migration is run, only the sales and customer data is migrated. No catalogue or config changes of any kind are migrated across.

JiraShell¶

This can be used to queue and then send tickets to Jira. You can find docs here.