1. Migrate your code from magento 1 to Magento 2
Simon Frost

2. About me
Simon Frost
Senior Backend Magento Developer at Vortex Commerce
Magento Certified Developer Plus
Zend Certified Engineer
Working with PHP for about 10 years
Working with Magento for about 5 years

3. Introduction Theory Practice What can be migrated? What can't?
What shouldn't?
Practice
Tools
Process
A worked example

4. Theory
What you should take into account before migrating

5. What are the big code changes in M2?
Different directory structure
Namespaces
Dependency Injection
Domain-specific config XML files
Handle-specific layout XML files

6. What can be migrated automatically?
Directory structure
Config XML
Layout XML
PHP Code

7. What can't be migrated automatically?
Themes
Resource scripts
CSS conversion from plain CSS to LESS/SASS
JS conversion from Prototype to jQuery
Custom business logic (depends)
Module dependencies. These need to be done separately.
Unit tests
3rd Party Libraries - these should be added to M2 composer.json manually
Layout XML in the admin

8. What shouldn't you migrate?
Migrating is a lot of work, even if some of it is automated.
Don't bother migrating an extension if you can answer yes to any of the following questions:
Does it duplicate existing M2 functionality?
Is there an M2 extension already available that does the same thing?
Does the client no longer use the extension?

9. Practice
A comparison of the tools available

10. Migrating using automated tools
These tools simply automate repetitive tasks, i.e. Splitting the M1 config.xml file into multiple M2 config XML files
Depending on the age and purpose of the extension, it may be better to start from scratch than try to migrate it (hold that thought)
It would be very helpful to know about the part of M2 your M1 extension works with (i.e. Payment gateways, shipping methods, etc) so you can tell how accurate the migration was after it has been migrated
Convert your extension using each one, then compare, contrast and merge all changes (including any manual changes you've made) into one finished product
Not a complete solution - some remedial work will need to be done.

11. The Tools (1/2) Developed by ex-M1 core developer
Code Migration Toolkit (Magento)
ConvertM1M2 (Unirgy)
Standalone CLI tool, aimed at developers to automate routine code changes using static analysis
M1 code goes in, M2 code comes out
Only covers custom extensions. Themes, data and database schema are not migrated.
Remaining work: Converting custom business logic, testing, troubleshooting
Last updated: Less than a month ago
Developed by ex-M1 core developer
Convert multiple extensions at once
Includes code validation of migrated classes
Difficult to configure
Remaining work: Converting custom business logic, testing, troubleshooting
Last updated: 9 months ago

12. The Tools (2/2) Start from scratch
Pestle (Alan Storm)
Start from scratch
Not a migration tool, but an M2 code generation tool
Helpful for plugging the gaps that other code migration tools may miss
Last updated: Less than a month ago
Maybe a better option if you don't get good results from automated tools
Use an M2 module generator (e.g. Pestle, n98-magerun2)
Use your M1 extension for reference

13. Process
Steps to follow to get the most out of the migration process

14. Process (1/2) Preparation Conversion
Get your M1 extension into the best shape possible
Remove anything which depends on M1 features which are not present in M2
Remove M1-specific bug fixes or obsolete customisations
Remove anything which duplicates M2 functionality
Run the tool(s)

15. Process (2/2) Afterwards Testing Manual inspection (diff) of code.
Check to see what wasn't migrated.
Manually convert anything remaining.
Bonus points: If there is a design pattern which occurs across your extension which the tool doesn't convert, fork the tool and modify it to update that, rather than manually updating it wherever it occurs
Run M2 unit tests. Make sure they all pass.
Install the migrated extension into vanilla M2 instance.
Write M2 unit tests for your migrated extension!
Run M2 unit tests again.

16. Using the Magento Code Migration Toolkit
A step-by-step guide to using Magento's official offering

17. Using the Magento Code Migration Toolkit
Usage notes
Installation
You'll need a vanilla install of both M1 and M2
You'll need your extension installed in the M1 instance
If your extension has dependencies on other extensions or libraries, they must be installed in the M1 instance as well, even if they are not to be migrated
Changes are cumulative, so each of the tools must be run in the specified order
Requires min. PHP 5.5x
Clone it: migration
Install with composer:
composer install
Does not support modman, or custom directory structure

18. 1. Preparation
<source> - Directory that contains custom Magento 1.x code that is intended to be migrated. The code must follow the Magento 1.x directory structure. Magento 1.x core files must not be included.
<destination> - Empty directory for the toolkit to write the generated Magento 2 code into
<m1> - Directory that contains:
Vanilla Magento 1.x codebase, and
Custom Magento 1.x code same as in <source> directory, and
Dependencies of the custom Magento 1.x code, if any, that are not part of <source> directory as not intended to be migrated at the moment
<m2> - Directory that contains the vanilla Magento 2.x codebase
Before running the migration, the following directories need to be prepared
The above directories are not required to be positioned relatively to each other, they can be anywhere in the file system. 
Note that the Magento instances living in the directories <m1> and <m2> may not necessarily be installed. Being a static analysis tool, the toolkit does not execute the Magento source code.

19. 2. Prepare Mappings Command:
php <tool>/bin/utils.php generateClassMapping <m1> <m2>
Uses mappings to migrate module names, class names, table names and view files to M2 equivalents
E.g. Mage_Catalog (in M1) is mapped to Magento_Catalog (in M2)
Pre-generated mappings are included for 1.9x, mappings for other versions can be created on demand
Generating mappings can greatly increase the accuracy of migration

20. 3. Migrate directories Command:
php <tool>/bin/migrate.php migrateModuleStructure \             <source> <destination>
Removes code pools
Aggregates extension files into one directory
Before
After

21. 4. Migrate Layout xml Command:
php <tool>/bin/migrate.php convertLayout <destination>
Splits layout files into handle-specific XML files and reformats XML to M2 syntax
Before
After

22. 5. Migrate config xml Command:
php <tool>/bin/migrate.php convertConfig <destination>
Splits config XML files into domain-specific XML files
Before
After

23. 6. Migrate php code Command:
php <tool>/bin/migrate.php convertPhpCode <destination> \        <m1> <m2>
Refactors controllers by actions
Updates PHP namespaces
Adds class dependencies to constructor using DI
Updates class name aliases in factory methods
Replaces calls to static methods (i.e. Mage::)

24. Before
After

25. ...and finally – an alternative
Refactor your extension so it supports M1 and M2 simultaneously (but that's for another time ;)

26. Thank you! Any questions?

27. SOURCES TOOLS AND DOCUMENTATION PRESENTATIONS
Magento: Code Migration Toolkit
migration
Unirgy: ConvertM1M2
Alan Storm: Pestle
Magento DevDocs: Migrate from Magento 1 to Magento 2
howdoi/migrate/migrate.html
Imagine Developer Deep Dive: Magento 1.x to Magento 2 Code Migration Tool
dQvkk&feature=youtu.be
Meet Magento Serbia - Porting Magento 1.x extensions to Magento 2
UQsaI
Meet Magento Utrecht: Migrating from Magento 1 to Magento 2
-from-magento-1-to-magento-2