1

I have a website on Magento 1.9.0.1 on one Linux server with PHP 5.6 and I need to upgrade it to the latest version and install it on another Linux server with PHP 7.2. So, I'm very confused about my next steps. I know that I can't upgrade PHP to the latest version on the first server as Magento 1.9 doesn't support that.

So, do I need to upgrade it first to Magento 2.0 (I've read somewhere that it does support 5.6) or I can't upgrade it straight to the latest version? I also have some confusion about transferring the data. Do I need to create a separate copy of the original database or I can just repoint it? I appreciate any help

Improve this question

1 Answer 1

Reset to default
2

There is no real upgrade path from 1.x to 2.x.

"Upgrading" is limited to migrating data from a 1.x instance to a 2.x instance. The migration tool runs within the 2.x instance and reads data from a 1.x database specified in the migration config files.

In your case this would mean building out the latest Magento 2 version on a server running the latest supported PHP version. Then you would configure the migration tool to pull data from your 1.9.0.1 database and write the updated version to the 2.x database.

Note that out-of-box the migration only handles native tables and (as of the 2.3.2 version) may need "help" with things like the model references in the eav_attribute table.

Improve this answer
8
  • Do you mean that migration with work only with MySQL native tables? Can you explain the last paragraph?
    – in43sh
    Commented Feb 10, 2020 at 6:20
  • 1
    By default, the migration tool only maps native tables (and columns). If you need to map additional tables created by extensions, or map columns added to native tables, the migration tool must be extended. E.g. it is common for columns to be added to the sales tables. The migration tool would need to be extended to map these columns to the equivalent M2 tables.
    – jiheison
    Commented Feb 10, 2020 at 6:36
  • 1
    Regarding eav_attribute, certain attributes with programmatically derived selectable values are bound to "models" by a string value that corresponds to a PHP class. The format of these references is different in M2, so any non-native class will not be mapped correctly. Also, broken model references (wrong format or pointing to a non-existent class) will cause problems when loading products, etc. So, it is important to review these attributes and anticipate which need to either be re-implemented in M2 or removed.
    – jiheison
    Commented Feb 10, 2020 at 6:47
  • 1
    Exactly. The migration only includes tables created by core modules.
    – jiheison
    Commented Feb 10, 2020 at 17:53
  • 1
    I'm pretty sure that the only requirement is that the migration tool can use the configured DB credentials to read from the M1 database (and write if you want to use the delta mode at some point). The migration tool can connect to the M1 DB over a network so there is no need to have M1 and M2 running on the same server.
    – jiheison
    Commented Feb 10, 2020 at 18:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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