Free Magento 1 to Magento 2 migration add-on helps to move data from Magento 1 store to Magento 2, or from one Magento 2 instance to another. With the add-on you connect together databases of two stores, choose which entity you want to migrate, and hit ‘Run’ button.

THE ADD-ON IS NO LONGER SUPPORTED

The latest version NOW SUPPORTS MIGRATION FROM MAGENTO 2 TO MAGENTO 2 in addition to M1>M2.

Installation

NOTE: you need to install Improved Import and Export extension prior to installing any add-ons.

To install the add-on follow these steps

1. Log into your FireBear account and proceed to My Extensions Download section.
2. Download Free Magento 1 to Magento 2 migration add-on package.
3. Extract the contents of the Free Magento 1 to Magento 2 migration add-on package to your Magento 2 root folder to app/code/Firebear folder.
4. Navigate to your store root folder in the SSH console of your server:
   
   
   cd path_to_the_store_root_folder

   1	cd path_to_the_store_root_folder

5. Enable the add-on by running:
   
   
   php bin/magento module:enable Firebear_PlatformM1

   1	php bin/magento module:enable Firebear_PlatformM1

6. Upgrade database
   
   
   php bin/magento setup:upgrade —keep-generated

   1	php bin/magento setup:upgrade —keep-generated

Configuration

The add-on configuration is all about specifying the credentials of the source store in the administrator panel. To access configuration section navigate to Stores > Configuration > Firebear Studio > Import/Export.

At the configuration section, expand Source Database section to see required credentials, they include:

• Host – the IP address of the source store server, where the database is located. (NOTE: you need to enable remote access to the database source, and use the host of the remote access. Check this article for instructions. If you are using hosting solution, contact the support team)
• Username – your account login to the source store server.
• Password – your account password to the source store server.
• Database Name – name of the source database that the add-on will use to transfer the data.

After filling all the fields above you are done with the add-on configuration and can proceed to the data migration.

NOTE

The data base of the target store MUST BE EMPTY. In other words, you need to make sure you don’t have any products, customers, categories, or other entities at the target store. This limitation comes from the fact that Magento uses IDs to check the entities integrity.

Migrating to a store with the populated database may result in errors or not all data being migrated.

Order of the entity migration

All entities in Magento 2 are interconnected. That’s why when migrating the data one must remember the native Magento 2 logic of how products and other entities behave.

Here is a couple of examples:

1. Products in Magento 2 must belong to a category and cannot exist without certain attributes. That’s why you cannot migrate right away. You need to have prepared the basis for them.
2. First you need to import categories, then product attributes, and only after this, you can proceed with the products import.
3. Orders in Magento 2 are placed by customers and include products. That’s why before migrating orders you need to have migrated customers and products.
   And before products again: categories and attributes.

Firebear development team strongly suggests you refer to the below list of the entity migration order:

1. First, migrate product categories.
2. Then, product attributes.
3. After, products.
4. Customers.
5. Quotes.
6. Orders.
7. Invoices.
8. Credit memos.

Make sure to stick to this migration order to avoid any issues.

Payment methods

Migration of Orders will also require the same payment methods available at the target Magento 2 instance. If you migrate the order and payment method reference will not be available such order may cause issues and won’t open from the administrator panel.

If for some reason particular payment method is not available for your Magento 2 – you need to create it manually and set it to:

checkout=false

By doing so, you will enable the orders with this payment method in the Magento 2 backend and will perform a successful order migration.

Running migrating from Magento 2 administrator panel

Free Magento 1 to Magento 2 migration add-on features the possibility to migrate all the necessary data directly from the Magento 2 backend without using command line or any programming knowledge.

The add-on’s migration interface can be accessed from System > Improved Import/Export > Data Migration.

The interface features the following elements:

• Path to Magento Root Directory – here you need to specify the path to the folder at your server, where the target Magento 2 instance is installed. The add-on automatically detects the installation folder of the current store, however, if you have multiple Magento 2 instances installed – you may want to use another path.
• Command – in this dropdown menu you select the entity you want to migrate. The add-on allows migrating every entity separately, unlike native migration tool that attempts to migrate the whole store at once.
• Run – when you specified and double-checked the path to the store and selected the entity you want to import – you hit ‘Run’ button.

In the improvised command line above you will see all the executed commands and the status of the migration.

Running M1 to M2 migration from command line

If you are migrating huge chunks of data you may prefer to use server command line and run migration manually. Magento 2 administrator panel may not be an option due to additional load on the system and architecture peculiarities.

With Free Magento 1 to Magento 2 migration add-on you have the possibility to also perform migration via command line. So the general rule is:

• Migration of a small amount of a single entity – use Magneto 2 administrator panel.
• Migration of huge amounts of data (several hundreds of Mbs of data) – use command line.

The commands for manual migration can be found below:

Running M2 to M2 migration from command line

The command list for Magento 2 to Magento 2 migration:

Running migration from particular date

The latest version of the add-on allows to migrate the data from a particular date. For example, if you want to migrate the data you have only added since Spring 2019, you can do this. To migrate the data from a particular date, after the command including desired entity type add:

The date format used is the native Magento 2 date format you can look in your database. For example, if you want to migrate products that have been added to the store starting from January 2019, you need to run:

That’s it. Now you can migrate the data from the particular date using Free Migration Add-on of Improved Import & Export extension.

Custom logic. Developer section

Custom methods can be implemented in the di.xml file of the add-on.

Add source and destination tables:

Specify columns you want to fetch from the source:

Specify columns you want to insert into the destination:

Specify mapping between columns:

To apply filter on the source data:

To apply field job:

To apply pre job:

To apply post job:

Filters

Use filters if you want to limit amount of data fetched from the source table. You have two options:

1. Use plain SQL directly in the configuration:

2. Encapsulate your logic in separate filter class to be reused in multiple tables:

Implement \Firebear\ImportExport\Model\Migration\FilterJobs\FilterJobsInterface to create filters for your needs.

Current filters:

* \Firebear\ImportExport\Model\Migration\FilterJobs\StoreId – filter the data by existing store ids.

* \Firebear\ImportExport\Model\Migration\FilterJobs\WebsiteId – filter the data by existing website ids.

* \Firebear\ImportExport\Model\Migration\FilterJobs\AttributeId – filter the data by existing entity attribute ids:

This filter will automatically fetch attribute ids for the specified entity type and attribute codes and then insert corresponding condition into the source data fetch query.

* \Firebear\ImportExport\Model\Migration\Filter\Exists – filter the data by values in another table:

This filter will fetch option_id values from eav_attribute_option table and filter attached field by those values.

Field processors

Use field processors if you need to transform the data from the source in some way.

Typical example would be store_id field. As we have different store ids in each system we have to transform store_id from the source to the corresponding store_id in the destination.

Implement \Firebear\ImportExport\Model\Migration\Field\JobInterface to create field processors for your needs.

Current field processors:

* \Firebear\ImportExport\Model\Migration\Field\Job\ConvertToJson – convert serialized value to json representation.

* \Firebear\ImportExport\Model\Migration\Field\Job\CopyValue – copy value from another field in the source:

* \Firebear\ImportExport\Model\Migration\Field\Job\SetValue – set specific value for the field:

* \Firebear\ImportExport\Model\Migration\Field\Job\SetAttributeId – special case of SetValue, set value to the attribute id of the given attribute code.

* \Firebear\ImportExport\Model\Migration\Field\Job\MapValue – set value according to the mapping specified in the configuration:

Use allowEmpty parameter to specify how processor should handle empty source values.

* \Firebear\ImportExport\Model\Migration\Field\Job\MapStoreId – special case of MapValue processor, used to transform store id according to the store id mapping.

* \Firebear\ImportExport\Model\Migration\Field\Job\MapWebsiteId – special case of MapValue processor, used to transform website id according to the website id mapping.

* \Firebear\ImportExport\Model\Migration\Field\Job\MapAttributeId – map attribute ids in the source to the attribute ids in the destination:

This filter will automatically map attribute ids for the specified entity type and attribute codes.

* \Firebear\ImportExport\Model\Migration\Field\Job\MapFromTable – map values based on the data from another table:

* \Firebear\ImportExport\Model\Migration\Field\Job\Replace – replace content with a regular expression:

This filter will replace Magento 1 block insert notation with Magento 2 format.

Pre jobs

Use pre jobs if you need to do something before the start of migration of the table. For example to truncate table or prepare additional data.

Implement \Firebear\PlatformM1\Api\PreJobInterface to create post processors for your needs.

Current pre job

* \Firebear\ImportExport\Model\Migration\PreJob\Truncate – use to truncate table:

Post Job

Use post processors if you need to do something after the migration for the table has been completed.

For example if you need to do some data cleanup or fix something in related tables.

Implement \Firebear\PlatformM1\Api\PostJobInterface to create post processors for your needs.

Grouping

You can group several jobs to be executed at once. Example:

That way if you run the migration for Categories entity code if will run all child migrations one by one.

Add new product attribute to migration

To include new attribute into data migration do the following:

* Adjust product attribute id filter Firebear\ImportExport\Model\Migration\Filter\ProductAttributeId to include data for your attribute in the source data fetch:

This way data for your attribute will be fetched from the source database.

* Adjust product attribute id processor Firebear\ImportExport\Model\Migration\Field\Job\MapProductAttributeId and add you attribute to the mapping:

This way product attribute id processor would be able to map old attribute id from the source database to the new attribute id in the destination database.

* Clean cache and run the following commands to migrate data for your attribute (attribute options, etc.) and attribute values for the products.:

Troubleshooting

Before contacting FireBear support team explore this chapter to see if some of the solutions can help you with the issues you face.

Note that there must be the outdated version of the add-on at Magento Marketplace, make sure to ask the team to upgrade the extension.

All changes you need to apply only to PlatformM1/etc/di.xml file

Whenever you change di.xml file, di compile command is mandatory for execution

ISSUE 1:

SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘databasename.sequence_catalog_category’ doesn’t exist

Solution:

The issue appears when you migrate to Magento 2 Open Source. Please find the following code (‘sequence’) in di.xml and comment it.

If you have similar issues with other entities, make sure to resolve them the same way by commenting sequence post jobs.

ISSUE 2:

eav_attribute_option_value table did not import any data

Solution:

Find option_id in field jobs of the virtual type and comment it:

ISSUE 3:

SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘databasename.catalog_product_entity_media_gallery_value_to_entity’ doesn’t exist

Solution:

change to:

Add suffix M2 at the end in the second virtual type at the line around 10266.

ISSUE 4

Where to add custom product attributes?

Solution:

Find the following code:

Add your custom product attributes at this end in this item list.

Also, use the following:

Add your custom product attributes at this end in this item list.

Note that di.xml must have a different name depending on the Magento 2 edition you use.

E.g., di_CE.xml – for Magento 2 Open Source
di_EE.xml – for Magento 2 Commerce

During migration from the Open Source edition to the Commerce edition make sure to replace all the entity_id attributes in the table with row_id.

Also make sure to apply the same changes in Field/Job.

E.g.,

change to:

Also, note that this topic is often discussed on forums and in various materials across the entire web. For instance, you can check this Magento 1 to Magento 2 Migration Guide to explore an alternative view on the process.