0

I am having A big problem migrating from 1.9.2.1 to 2.1.3

I have not found a solution on the web that worked for me.

When I run migration for the 1st time:

[Exception]                                                                                                                                           
  Notice: Undefined offset: 23 in ../../..//vendor/magento/data-migration-tool/src/Migration/Step/Eav/Data.php on line 532

When I run migration for the 2nd time:

Integrity constraint violation: 1062 Duplicate entry '1-Migration_Default' for key 'EAV_ATTRIBUTE_SET_ENTITY_TYPE_ID_ATTRIBUTE_SET_NAME'

The second message is understandable cause whes I look at the at EAV_ATTRIBUTE_SET table in magento 2 it's been migrated.

But the first notice message is where the problem start.

Does anyone came across this issue and perhaps guide me please on what else to look for I appreciate for help Thank you.

1

This type of error occurred due to something went wrong when migration process in working.

Please follow this step,

  • DROP Magento2 database and restore it.
  • If any extension in Magento2, then execute php bin/magento setup:upgrade.
  • php bin/magento migrate:settings vendor/magento/data-migration-tool/etc/ce-to-ce/1.9.2.4/config.xml
  • php bin/magento migrate:data --reset vendor/magento/data-migration-tool/etc/ce-to-ce/1.9.2.4/config.xml

Replace 1.9.2.4 with your Magento1 version.

After completed your migration process, ecxecute this command,

  • php bin/magento cache:flush
  • php bin/magento indexer:reindex

I hope this will work for you.

0

I have migrate 1.9 to 2.1 it is work for me

First install fresh magento setup without sample data after installation this module

https://github.com/ubertheme/module-ubdatamigration

  • Hi Sagar. thank you for the reply. I will give a go this module – Juliano Vargas Feb 28 '17 at 13:51
  • Hi Sagar. I have tried I got errors: – Juliano Vargas Feb 28 '17 at 14:11
  • Your requirements could not be resolved to an installable set of packages. Problem 1 - Conclusion: don't install ubertheme/module-ubdatamigration v1.0.4 - Conclusion: don't install ubertheme/module-ubdatamigration v1.0.3 - Conclusion: don't install ubertheme/module-ubdatamigration v1.0.2 - Conclusion: don't install ubertheme/module-ubdatamigration v1.0.1 - Conclusion: don't install ubertheme/module-ubdatamigration v1.0.0|remove magento/framework 100.1.3 - Conclusion: don't install ubertheme/module-ubdatamigration v1.0.0|don't install magento/framework 100.1.3 – Juliano Vargas Feb 28 '17 at 14:14
  • - Installation request for ubertheme/module-ubdatamigration ^1.0 -> satisfiable by ubertheme/module-ubdatamigration[v1.0.0, v1.0.1, v1.0.2, v1.0.3, v1.0.4]. - ubertheme/module-ubdatamigration v1.0.0 requires magento/framework 100.0.* -> satisfiable by magento/framework[100.0.2, 100.0.3, 100.0.4, 100.0.5, 100.0.6, 100.0.7, 100.0.8, 100.0.9, 100.0.10, 100.0.11, 100.0.12, 100.0.13, 100.0.14, 100.0.15]. - Can only install one of: magento/framework[100.1.3, 100.0.2]. - Can only install one of: magento/framework[100.1.3, 100.0.3]. – Juliano Vargas Feb 28 '17 at 14:14
  • Can only install one of: magento/framework[100.1.3, 100.0.3]. and tha goes on to [100.1.3, 100.0.15] – Juliano Vargas Feb 28 '17 at 14:15
0

I have had the same issue and here's what I figured out

ON AN "ERROR" DURING THE EAV STAGE, WHEN THE SYSTEM SAYS "REVERTING" IT DOES NOT REVERT THE ATTRIBUTE_SET AND ATTRIBUTE_GROUP DATA FULLY, AND SO WHEN RUN AGAIN THERE WILL BE ERRORS OVER AND OVER.

The attribute sets and attribute groups are also not reverted properly if you use --reset

m2's eav_attribute_set table ends up containing the "migration_" entries after the undefined offset error or any other error during a further substep of the eav process, hence causing the "duplicate" error next time

m2's eav_attribute_set table ends up completely empty after the Duplicate entry, hence causing the "undefined offset" next time

The tool itself is creating the situation for this error, and an endless loop of it!

I have managed to pass through by MANUALLY rebuilding the eav_attribute_set and eav_attribute_group tables in the database to have only the original entries (but with the IDs from after my first migration)

But if I then get another error in the EAV step (eg: class name reference from a module I am not planning to migrate) then this error is back on the next run so I have to do that manual clean up over and over.

And because especially on the EAV stage things are a trial and error process (what classes, fields etc does the system flag up? decide whether to migrate or ignore, rinse, repeat) this is very very frustrating.

It also means people are sidetracked by this error which has nothing to do with our data or site!


The "cleanup": In my case I have 13 attribute sets, so 14 is my ID to recreate the sets. m2_ is my prefix, adapt for yours.

INSERT INTO `m2_eav_attribute_set` (`attribute_set_id`, `entity_type_id`, `attribute_set_name`, `sort_order`) VALUES
(14, 1, 'Default', 2),
(15, 2, 'Default', 2),
(16, 3, 'Default', 1),
(17, 4, 'Default', 1),
(18, 5, 'Default', 1),
(19, 6, 'Default', 1),
(20, 7, 'Default', 1),
(21, 8, 'Default', 1);

Similarly, delete from eav_attribute_group all entries referring to attribute set id <14

And yes, I have to do this each time until I have figured out all the configuration changes necessary in the eav stage.

  • I have reported this on the github for the data migration tool – iphigenie Mar 8 '17 at 13:49
  • this still happens – iphigenie Jun 22 '17 at 9:31
  • this still happens – iphigenie Aug 17 '18 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.