How do I successfully migrate data with MageFlow?

Home » Question » How do I successfully migrate data with MageFlow?
AnswersCategory: Data managementHow do I successfully migrate data with MageFlow?
Kratt Kaarel Staff asked 3 years ago
1 Answers
Marju Mihkelsoo Staff answered 3 years ago

Please follow these Data Migration Ground Rules in order to avoid problems caused by failed migrations or inconsistent data.

  1. Always make sure you have a recent backup of your Magento database before pulling or transferring data.
  2. Always transfer these dependencies first to make sure your instances are up to date:
    • Migrate websites / store groups / store views before anything else to make sure you have the entities with the correct identifiers in all of your instances.
    • Migrate root category before migrating subcategories.
    • Migrate attributes before migrating attribute sets or products.
  3. Keep migrations atomic (i.e. push, pull and transfer items one by one) whenever possible.

The long version of dependencies list. Please read it carefully, most items have dependencies that must be migrated first.

  1. Website / Store Group / Store View – no known dependencies. Please note, that these are migrated as a set – a Store View is always migrated with the Website it belongs to.
  2. Customer Group – depends on Customer Tax Class.
  3. Product Tax Class – no dependencies.
  4. Customer Tax Class – no dependencies.
  5. Sales Tax Rate – no dependencies.
  6. Sales Tax Rule – depends on Customer Tax Class, Product Tax Class and Sales Tax Rate.
  7. System Design – depends on Store View and the custom design you are going to apply.
  8. Promotion Rule Catalog (or Catalog Price Rules) – depends on Customer Group, Website and (in EE) Banner. Since Rule conditions allow references to them, a Rule may also depend on Attribute Set and Catalog Category.
  9. Promotion Rule Checkout (or Shopping Cart Price Rules) – same as Catalog Rule, with more optional dependencies possible (Customer Segment for example).
  10. Newsletter Template – no dependencies.
  11. Email Template – no dependencies.
  12. CMS Widget – as Widget can optionally depend on most of the other entities, the dependency list for each Widget should be taken on case-to-case basis. If possible, always migrate Widgets last.
  13. CMS Poll – depends on Website/Store. Additionally, MageFlow currently considers Poll’s answers to be a transactional data and thus ignored on migration. Every time MFX saves a Poll, a new set of answers is created.
  14. CMS Banner – depends on Customer Segment and optionally Promotion Rules.
    • If Banner is moved first and Rules that depend on that Banner later, dependency is created by MFX.
    • If Rules are moved first and Banner later, MFX also creates the dependency.
    • As the Banner-Rule connection is optional, then if the dependencies are not found or correctly identified while migrating, migration shall still be successful, with just the Banner-Rule dependency ignored.
  15. System Order Status – no dependencies.
  16. Sales Terms and Conditions – depends on Website/Store/View.
  17. Catalog Search Terms – depends on Store.
  18. System Configuration – if it has a scope, it depends on that scope.
  19. CMS Block – depends on Website/Store/View.
  20. CMS Page – depends on Website/Store/View. In EE, Page also depends on Node and, to some extent, User. MFX tries to find Page Revision’s owner while migrating, but as that can not always be possible, unknown User is automatically substituted with the logged in or a default admin User.
    NB! Please keep in mind, that the process of creating a new Page in Magento EE backend takes more than one Save, so also more than one change item is created. MFX has to treat each of those saves as a different version of the Page because as the versioning process goes, these are fully legitimate different versions. For migrating, use only the latest change item, it contains all the same data as the previous ones.
  21. Catalog Attribute – depends on Website/Store/View as it has separate labels for each Store. If that dependency is not met, the migration is still carried on.
  22. Catalog Attribute Set – depends on Attributes.
  23. System User – depends on a System Role. Since Role with ACL info is embedded to User data, migrating User should work also without migrating the Role first, as the Role is created during migration.
  24. System Role – no dependencies.
  25. Catalog Product – depends on Attribute Set and Product Tax Class and, if specified Website/Store/View and Category.
    NB! Different types on Product can also depend on other Products, Custom designs and more, please check the possible dependencies for each case. If Product depends on sub-Products, those are identified by mf_guid and dependencies are created, even if they are migrated before creating “master” Product.
  26. Configurable Product. NB! If Product has differently specified data for specific Stores, always check those stores in the Product settings Websites tab – MFX only searches different data for those stores that are enabled from there. For example – if Product has different metadata for different Stores, make sure that those Stores are checked too.

In some very rare cases migration can fail because dependencies are not met or mapped correctly. This can occur when dependencies are updated in the source but the change item of the dependent entity has already been created. To fix inconsistencies in dependencies:

  1. Delete the change item(s) from source Magento push grid;
  2. Save the data again (just edit and save, change item is created automatically);
  3. Migrate again.