Expert guidance on migrating from magento 1 to magento 2
•Als PPTX, PDF herunterladen•
0 gefällt mir•227 views
Migrating a Magento site is not just about code and data. Commerce platforms evolve over time and your Magento 1 solution is likely different today compared to the day you launched. Planning a successful migration means understanding what you have and where you are going before you can begin. In this session, architects from the Magento Expert Consulting Group will lay out best practices for defining your migration strategy, and share tips and techniques for code and data migration.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Expert guidance on migrating from magento 1 to magento 2
Ähnlich wie Expert guidance on migrating from magento 1 to magento 2 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Expert guidance on migrating from magento 1 to magento 2
- 2. Expert Guidance on Migrating from Magento 1 to Magento 2
- 3. Gordon Knoppe Business Solutions Architect, ECG James Cowie Technical Architect, ECG
- 4. Expert Consulting Group ECG Charter: To provide expert insight, review, and guidance at every stage of the Magento project lifecycle. • Customer Success: Leverage innovative technologies and superior talent to exceed customer expectations in every way. • Quality and Scale: Drive quality for all implementations, large and small, to ensure success on the Magento platform. • Thought Leadership: Develop and publish best practices to increase quality in the Magento community.
- 5. Expert Consulting Group Preferred Service Technical Account Manager
- 6. Migration Analysis Methodology Current Magento Landscape Codebase & Database System landscape & Systems of record Requirements & Wireframes Test Documentation Existing and Future-state Infrastructure Diagrams Environments Dev Tools & SDLC StrategiesReview and Assess • Custom Modules • Extensions • New Features • Theme • Personal Devices • Integrations • Information Migration • Business Process Changes • Infrastructure • Environments • Testing • Desktop and personal device requirements • Integrity of Magento Core code • Custom Modules • Extensions • Customized Features • Integrations • Database • Theme and Templates • Test Documentation • Infrastructure • Environments
- 7. Migration Analysis Confidence is the feeling you have before you fully understand the situation. - Unknown
- 8. Analysis Phase - Features 1. Requirements 2. Code Audit 3. Theme 4. Testing Process
- 9. Code Audit • Custom development • Third-party extensions • Dependencies between extensions • Un-used modules • JavaScript functionality • Business logic in templates
- 10. Requirements • Obsolete customizations • Magento native features and functionality in use • Desktop vs. mobile, progressive enhancement • Mapping requirements to tests and acceptance
- 11. Theme • Identify theme requirements • Create theme approach • Theme is not migrated by tools
- 12. Testing Process • Start early, understand what you’ve got • End-to-end (integration) testing • Written documentation and gap analysis • Mapping tests to requirements?
- 13. Analysis - Supporting Elements 1. Landscape Diagram / Integrations 2. Data (size, scope, locations) 3. Environments
- 14. Strategy and Vision If you aim at nothing, you will hit it every time. - Zig Ziglar
- 15. New Features • New in Magento 2 – Or maybe just new to you? • Return to native • Demo, demo, demo for your business users!
- 16. Third-party Extensions • Full inventory of installed extensions and versions • Remove, return to native, upgrade • Does it do everything it did in the Magento 1 version?
- 17. Theming and Personal Devices • HTML, CSS, and JavaScript • Build on a responsive foundation • Single theme or global multi-store with unified branding? • Supported devices and responsive break points
- 18. Custom Modules • Code custom built to satisfy your requirements • Remove or migrate • Re-architect (refer to James) – Divide – Merge – Refactor
- 19. Non-code Related Strategies • Integrations • Information Migration • Infrastructure and Environments • Testing Strategy • Business Process Changes
- 20. Data Migration in Action Data is a precious thing and will last longer than the systems themselves. Tim Berners-Lee
- 21. Magento official Data migration tool https://github.com/magento/data-migration-tool
- 22. Best Practices • Remove outdated and redundant data • Close by MySQL instances • Use a replicated Magento 1 database NOT live
- 23. Benchmarks • Database had: – 177k products, – 355k orders, – 214k customers
- 24. Performance results • Settings migration time: ~10 mins • Data migration time: ~9 hours for full migration
- 25. Performance results • Site downtime – Around 5 minutes for re-index. – DNS propagation
- 26. What does it do? • Store Configuration • Products • Customers • Orders • Promotions
- 27. Modes • Store Configuration settings • Data • Delta (changes since the last run)
- 28. Prerequisites • Have Magento 2 Installed • Don’t start the Magento 2 cron jobs • Database Backups
- 29. Install composer config repositories.data-migration-tool git https://github.com/magento/data-migration-tool composer require-dev magento/data-migration-tool:<version>
- 30. Configure your version • CE to CE • CE to EE • EE to EE Pick your migration path:
- 31. Configure your version • 1.6.0.0 • … • 1.9.3.2 Pick the version number of Magento 1 used:
- 32. Configuring the tool – config.xml Copy the file specific to your version. <source> <database host="127.0.0.1" name="magento1" user="root"/> </source> <destination> <database host="127.0.0.1" name="magento2" user="root"/> </destination>
- 33. Configuring the tool – config.xml Copy the file specific to your version. <source> <database host="127.0.0.1" name="magento1" user="root"/> </source> <destination> <database host="127.0.0.1" name="magento2" user="root"/> </destination> Best Practice: Keep these as close as possible.
- 34. Mappings, How it all works • Mapping Files – Changing table names – Changing field names – Ignoring tables or fields – Adapt transferring of data
- 35. Running the tool > php bin/magento migrate migrate:data migrate:delta migrate:settings
- 36. Remember the order • Settings • Data • Deltas
- 37. Common errors • Invalid attributes – Differing data types • Source field not mapped
- 38. Map Files • Maps data between systems • Ignore fields • Field Rules – Move fields from one name to another – Transform fields from one type to another • Rules can apply to: – Source (m1) – Destination (m2)
- 39. Example [ERROR]: Source fields not mapped. Document: sales_flat_order_address. Fields: giftregistry_item_id
- 40. Source field not found • config.xml <map_file>etc/ce-to-ce/1.9.2.3/map.xml.dist</map_file> <map_file>etc/ce-to-ce/1.9.2.3/map.xml</map_file>
- 43. Tables that don’t exist on Magento 2 <source> <document_rules> <ignore> <document>Table Name</document> </ignore>
- 44. Deltas • Only to be ran after initial migration • Changes since last run • Run as often as possible (Multiple times per day) • Start this process early in migration plan
- 45. Custom data structures for modules • Ensure schema exists in both DB’s • Only add mappings if you want to change things. • Will migrate data automatically
- 46. Cleaning up • Check databases for temporary tables • Stop delta process running • Remove tool tables listed in deltalog.xml • Remove code from composer
- 47. Conclusion for Data • Practice, Practice and Practice • Use mappings for everything • Could use “scripts” but data migration can work well • Use Ignore responsibly • Integration with Business plans and process.
- 48. Preparing for code How to bring modules into M2
- 50. Overview of Official Tool • Static file generation • Maps types: – Models / Resource Models / Collections – Controllers – Actions – Blocks – XML • Repeatable process
- 51. What’s changed in module code • Plugins • Interceptors • Dependency Injection • Composer • UI components • API & Service contracts ( Interfaces )
- 52. Plugins • Modify Behavior of public methods and class • Before, Around and After • Reduces observer dependency mess.
- 53. Dependency Injection • Use DI over new instantiation • Constructor Arguments • Removes “God” class and thinking
- 54. Composer • Easily manage module dependencies • Pin versions of packages based on semantic versioning • Think create for reuse • Small helpful packages • Stop inventing the wheel
- 55. UI Components • Empower forms for adminhtml • Used through checkout and frontend as new bindings of logic
- 56. Concluding Code • Use automation for “prototype” • Consider time needed for rewrite – Learning time – Implementing time • Be selective with functionality migrated
- 57. Beyond Code and Data Migrating process. How to deploy
- 58. Deployments • Static assets • Composer dependencies • Code generation • Database coupling*
- 59. Options for deployment • Continuous integration • Build servers
- 60. Any Questions ? Thank-you for your time.
Hinweis der Redaktion
- Welcome and thank you for joining us Today talking about migrating from Magento 1 to Magento 2 both from a methodology perspective as well as with some practical examples and learnings We hope you’ll find this presentation useful and will leave this talk with a sense of what it takes and how you might approach your migration
- We are here representing ECG, both from Europe (well, James is from the UK..) Gordon - I’m based out of our Dublin, Ireland James - UK We’ve both been working pretty much exclusively with Magento 2 these days, since the beta in mid 2015
- First a quick introduction for our team, ECG charter Team of experts spread across the US and Europe working with our partners and their merchants on the most interesting and challenging projects Success, Quality, Scale, Thought leadership One key is that we share our learnings back with the product
- We work at certain points the lifecycle of a typical engagement or throughout the entire project with our preferred service Left to right... Technical Account Manager - Your resource inside Magento, able to connect directly to members of the core team, escalate issues But we’re here today to talk about
- Migration analysis, now you don’t need to read quite all of this as we will be stepping though this as part of this presentation Our approach to preparing for a migration from M1 to M2 LTR: From your current understanding of the landscape, reviewing all of that in the context of these key areas, and having a plan for how to address these strategic focuses of the migration
- In this first section I will step through the key areas involved in getting an understanding of your project. Things have probably changed from when you first planned your M1 site, new features have come online, others have been phased out, what is it really that we are going to need to take with us to Magento 2
- Need to understand what you’ve got before you can start going We think of There’s 4 things first – and are outputs required for the next phase; STRATEGY Will dive into each in detail next
- 60s
- Seems obvious right?
- 30s
- This was one slide per, don’t think we have the time for this now with James
- Magento saw the need for data to be migrated and as such developed the official and open source “Data migration tool”. The tool lives on GitHub and as always if you see any issues or improvements please open a pull request or ticket so that the tooling can improve.
- Environment: Virtual Box VM, CentOS 6, 2.5Gb RAM, CPU 1 core 2.6GHz
- These versions are important and relate to the path found from vendor/magento/data-migration-tool/etc/ and contains all of the specific mappings for the type of migration you are planning.
- (e.g. the same field has decimal datatype in Magento 1 and integer in Magento 2)
- Deltas operate by checking the source database values for what has changed.
- Semantic versioning load security and bug fixes but not major versions.