A Magento 1 to Magento 2 migration is large enough that the discipline of working from a structured checklist materially affects the outcome. Migrations that proceed without a complete checklist tend to discover missing items during implementation, where the cost of addressing them is multiples higher than the cost of catching them during discovery. This article walks through the migration checklist we use on M1 to M2 engagements, organized by the four major work streams: data, themes, extensions, and integrations.
The checklist is not exhaustive – every storefront has specific items not covered here – but it covers the categories that produce the most cost and risk variance across migrations. Retailers using this as a reference should expect to extend it with storefront-specific items rather than treating it as a complete list.
Data Migration Checklist
The data migration is one of the most underestimated phases of an M1 to M2 project. The standard data has Adobe’s Data Migration Tool available, but the standard data is only a portion of what most production storefronts have accumulated. The checklist below covers the standard data, the commonly-missed customizations, and the validation work that confirms the migration was successful.
The customer data items include customer accounts (including legacy accounts with non-standard email formats), customer addresses (including shipping addresses to non-standard countries), customer groups (including B2B-specific groups), customer attributes (including custom attributes), customer reward points if applicable, and customer wishlists. The validation should check both record counts and spot-check data integrity (a sample of accounts logged in successfully on M2, with addresses and order history visible).
The order data items include order records, order items, order status history, invoices, shipments, credit memos, and order communication history (transactional emails sent for each order). The validation should check that historical orders are accessible to customers on M2 and that operational workflows (reorder, returns, customer service lookups) function against migrated orders.
The catalog data items include products (including all attribute values), categories (including category structure and product associations), pricing rules (including catalog rules and shopping cart rules), and inventory data. The validation should check product display on the M2 storefront against M1 reference, with spot-checks across product types (simple, configurable, bundle, grouped) and across categories.
The content data items include CMS pages, CMS blocks, widgets, URL rewrites (this one is critical for SEO continuity), and store-level configuration. The validation should check URL preservation against the M1 site to maintain link equity and prevent search ranking disruption.
The configuration data items include payment methods, shipping methods, tax rules, store views and websites configuration, attribute sets, and system configuration. The validation should check that the M2 storefront can complete a test order using each payment and shipping method that was active on M1.
Theme Migration Checklist
The theme migration is the most architecturally distinct phase because M1 and M2 themes work fundamentally differently. M1 themes use a layout XML and PHTML pattern with RequireJS. M2 themes use a different layout XML pattern (incompatible at the syntax level), updated PHTML, KnockoutJS for many interactive components, and a different CSS architecture (LESS in M2 native, with Hyvä introducing TailwindCSS as an alternative). The theme is effectively rebuilt rather than migrated.
The theme structural items include the layout XML rewrite from M1’s pattern to M2’s, the PHTML template rewrite (similar PHP but different framework helpers and data passing), the CSS rebuild (LESS or Tailwind depending on theme choice), the JavaScript rewrite (RequireJS modules to M2’s RequireJS structure or Hyvä’s Alpine.js patterns), and the responsive behavior validation (M2’s default responsive patterns differ from M1’s).
The theme functional items include the homepage layout reconstruction, the product list page (PLP) layout, the product detail page (PDP) layout including configurable product selectors, the cart and checkout templates, the customer account templates, and the static page templates. Each of these should be functionally validated against M1’s reference behavior with spot-checks on representative products and customer scenarios.
The decision that affects timeline and cost most is whether to use Magento 2 native theme, Hyvä, or a headless approach. Native M2 theme is the lowest-cost option but produces lower performance baseline. Hyvä is moderately more expensive but produces substantially better CWV scores. Headless is the highest-cost option and only fits retailers with specific content management and personalization requirements. The decision should be made deliberately during discovery rather than defaulting to native M2.
Extension Migration Checklist
The extension migration produces some of the largest variance across M1 to M2 projects. Most extensions installed on M1 storefronts in 2020 have M2 equivalents in 2026, but the equivalents may have different feature sets, different configuration patterns, different data structures, and different vendor relationships. The migration is not always one-to-one.
The extension audit produces five outputs. The first is the complete list of M1 extensions actively in use on the storefront, gathered from the codebase and from runtime profiling (not just from documentation, which is often incomplete). The second is the M2 equivalent or replacement for each extension, with documented vendor and version. The third is the configuration migration plan for each extension (some extensions allow direct configuration export/import; many require manual reconfiguration). The fourth is the data migration plan for each extension (some extensions have data that has to migrate alongside the standard data). The fifth is the QA plan for each extension on M2 to confirm functional parity.
The common patterns that produce extension migration cost include extensions where the M2 version has a different feature set than the M1 version (requiring either rebuilding the M1 features as customizations or accepting the M2 feature set as a downgrade), extensions where the M2 version is from a different vendor (requiring data migration between vendors), extensions where no M2 equivalent exists (requiring custom development or removal), and extensions where the M2 version is substantially more expensive than the M1 version (affecting ongoing operating cost).
The cleanup opportunity during extension migration is to prune the accumulated extension set. M1 storefronts often have thirty to fifty extensions installed, of which many are not actually used, are duplicates of native functionality, or were installed for campaigns long since concluded. The M2 migration is the natural occasion to clean this up, with the migrated storefront running fewer but better-chosen extensions.
| Migration Workstream | Key Items | Common Pitfalls | Validation Approach |
|---|---|---|---|
| Customer data | Accounts, addresses, attributes, segments | Custom attributes, B2B groups missed | Sample login tests, order history checks |
| Order data | Orders, invoices, shipments, communications | Historical orders inaccessible | Operational workflow tests |
| Catalog data | Products, categories, pricing rules | Custom attributes, complex pricing | Storefront parity checks per product type |
| Content & SEO | CMS, URL rewrites, redirects | URL preservation for SEO | Sitemap diff, redirect validation |
| Theme | Layout, PHTML, CSS, JS | Architectural rebuild not migration | Functional + visual parity tests |
| Extensions | M1 → M2 mapping, config, data | Feature gaps, vendor changes | Per-extension QA plan |
| Integrations | Payment, ERP, CRM, shipping, search | API library updates required | End-to-end transaction tests |
Integration Migration Checklist
The integration migration is where the operational continuity risk lives. Integrations connect the storefront to the broader business operations – ERP, CRM, payment processors, shipping carriers, tax calculation, search providers, marketing automation, analytics, customer service, fulfillment. Each integration has to work on M2, and the migration of each carries specific risks.
The integration audit produces five outputs per integration. The first is the integration’s purpose and the operational workflows it supports. The second is the current M1 implementation pattern (extension, custom code, API integration). The third is the M2 implementation approach (vendor’s M2 connector, custom rewrite, API-level migration). The fourth is the data migration plan (which integration-related data needs to move alongside the standard migration). The fifth is the cutover plan (how to switch the integration from M1 to M2 with minimal operational disruption).
The payment integrations are the highest-risk because they affect revenue directly. The migration plan should include parallel testing where possible (test transactions on M2 while M1 continues to handle production), gradual cutover for risk reduction, and explicit rollback criteria. The PCI compliance implications of the cutover should be documented.
The ERP integrations are the highest-complexity because they involve bidirectional data flow and business-critical workflows. Order data flows from M2 to ERP, inventory flows from ERP to M2, customer data may flow in either direction, and various reference data (products, pricing, taxes) may sync. The migration plan should include detailed mapping of every data flow, validation tests for each direction, and clear ownership of the integration’s operation post-migration.
The shipping and tax integrations are typically the easiest because vendors have invested in M2-native connectors that are well-supported. The migration usually involves replacing the M1 connector with the M2 connector and reconfiguring rather than substantial development.
Pre-Launch Validation Checklist
Beyond the workstream-specific checklists, the pre-launch validation should include items that cut across workstreams. The PCI scan should be passed on the M2 environment. The performance baseline should be measured and compared to M1 (with appropriate context for the architectural changes). The SEO audit should confirm URL preservation, sitemap correctness, robots.txt configuration, and structured data implementation. The accessibility audit should confirm WCAG compliance for the M2 site. The security audit should confirm that the M2 site has appropriate baseline security configuration.
The UAT should be conducted by representative business users (not just the technical team) using realistic scenarios – completing orders end-to-end, managing customer service workflows, executing typical merchandising tasks, reviewing reporting and analytics. The UAT should include enough representative scenarios to catch issues that the technical QA might miss.
The cutover plan should specify the exact sequence of activities on launch day, the rollback criteria and procedure, the communication plan for customers and internal stakeholders, the monitoring focus areas during the first 48 hours, and the on-call rotation for the first week. Launches that lack a detailed cutover plan tend to produce incidents that the technical team cannot respond to efficiently because the operational ownership is unclear.
Post-Launch Stabilization Checklist
The post-launch stabilization phase typically runs six to twelve weeks and addresses issues that surface from real customer usage. The checklist for this phase includes monitoring for production issues that did not surface in QA, addressing performance issues that real-world traffic exposes, fine-tuning integration behavior under production load, addressing operational workflow issues that the business team encounters, and updating documentation based on what was learned during the launch.
The stabilization phase should have explicit scope and budget rather than being treated as “we’ll figure it out post-launch.” The pattern that works is to budget for stabilization as a defined phase with clear endpoints – a specific date by which production issues are resolved, a specific date by which the integration behavior is stable, and a specific transition to ongoing maintenance mode.
Bemeir’s Magento 1 to Magento 2 migration practice executes this checklist as part of the standard engagement structure rather than as optional discipline. The pattern has produced more on-time launches and fewer post-launch incidents than the alternative of executing migration without the structured checklist. For retailers whose business has evolved into territory where Shopify Plus might fit better, Bemeir’s Shopify Plus practice supports the alternative platform decision during discovery rather than mechanically proceeding with M1 to M2.
For deeper reference on the migration checklist patterns, the Adobe Commerce Data Migration Tool documentation is the authoritative reference for data migration, the Adobe Commerce DevDocs provide the platform reference for M2 itself, Hyvä Themes documentation provides the alternative theme reference, and the PCI Security Standards Council documentation provides the compliance reference that applies to payment integration migration specifically.
