The single largest source of Magento 1 to Adobe Commerce migration cost is the extension layer. Adobe’s Data Migration Tool handles the catalog and customer migration with reasonable fidelity. What it does not handle, by design, is the dozens of Magento 1 extensions that no longer have direct equivalents on Adobe Commerce. Each extension represents a decision: replace with a different vendor, rebuild from scratch in Adobe Commerce, or live without the functionality. Get the decisions wrong and the migration runs months over schedule and dollars over budget. Get them right and the extension layer becomes the unlock that makes the migration economically reasonable.
This piece walks through the framework Bemeir’s Magento team uses for extension mapping during M1 to Adobe Commerce migrations. The categories below are the ones that consistently determine where the surprise cost lives.
Step 1: Build the complete inventory
Before any decisions, the full inventory of M1 extensions. The sources:
The Magento Connect Manager (or equivalent admin module list). Every extension installed through the admin appears here. Export the list with version numbers.
The composer.json or app/code/community/local directories. Some extensions were installed via SSH or direct upload and do not appear in the Connect Manager. Cross-reference the file system against the admin list to find missed entries.
The list of custom modifications. Many M1 stores have custom modifications that were installed by the original developer and not registered as proper extensions. These often live in `app/code/local/`. Treat them as if they were extensions for purposes of the migration mapping.
The list of theme-level customizations. Some functionality was implemented through theme overrides rather than as standalone extensions. The list of overridden core templates and blocks counts as part of the extension surface.
The output is a single document with every piece of non-core code that affects the store, with file paths and vendor names where available.
Step 2: Categorize each entry
Each entry on the inventory falls into one of five categories. The category determines the action.
Category A: Direct replacement available on Adobe Commerce. The functionality exists in a vendor-maintained Adobe Commerce extension, often from the same vendor. Examples: Klaviyo M1 extension has a Klaviyo Adobe Commerce extension. Avalara M1 has Avalara for Adobe Commerce. These are the easy cases.
Category B: Functionality moved into Adobe Commerce core. Some M1 extension functionality became core in Adobe Commerce. Examples: certain payment method support, basic B2B features (in Adobe Commerce only), category permissions in some configurations. These extensions can be removed; the functionality comes free with the new platform.
Category C: Different vendor, equivalent functionality. The original vendor did not port to Adobe Commerce, but a different vendor offers the same functionality. Examples: many M1-only search extensions can be replaced by Algolia, Klevu, or Adobe Commerce Live Search. Many M1-only review extensions can be replaced by Yotpo, Trustpilot, or Stamped.
Category D: Rebuild from scratch in Adobe Commerce. The functionality is custom or store-specific and no vendor option fits. The rebuild is in-scope for the migration. Examples: custom B2B workflows, custom product configurators, custom integrations with proprietary systems.
Category E: Drop the functionality. The extension was solving a problem that no longer exists, was barely used, or whose value does not justify the rebuild cost. The migration is an opportunity to shed accumulated functionality nobody actually needs.
Step 3: Score each entry on three dimensions
For every extension that is not obviously a Category B (move to core) or Category E (drop), score it on:
Business criticality. How essential is this functionality to operations? Scale: 1 (decorative) to 5 (revenue-critical).
Replacement availability. How readily available is a vendor replacement on Adobe Commerce? Scale: 1 (no replacement exists) to 5 (direct vendor port).
Rebuild complexity. How much work would a custom rebuild require? Scale: 1 (trivial) to 5 (major engineering project).
The combination drives the recommendation:
| Criticality | Replacement available | Rebuild complexity | Recommended action |
|---|---|---|---|
| 5 (critical) | 4-5 | Any | Replace with vendor option |
| 5 (critical) | 1-2 | 1-2 | Rebuild in scope |
| 5 (critical) | 1-2 | 4-5 | Rebuild in scope, but consider scope phasing |
| 3-4 (important) | 4-5 | Any | Replace with vendor option |
| 3-4 (important) | 1-2 | 1-3 | Rebuild in scope |
| 3-4 (important) | 1-2 | 4-5 | Drop or defer to post-launch |
| 1-2 (minor) | Any | Any | Drop unless trivial to replace |
The matrix is not absolute, but it gets most decisions right and surfaces the ones that need merchant judgment.
The categories merchants underestimate
Three extension categories consistently cause migration surprise:
Custom B2B logic. M1 stores with custom B2B workflows (account-specific pricing, custom approval flows, custom catalog visibility rules) almost always have more custom code than the merchant remembers. The migration often surfaces 3-5 custom modules of B2B logic that were never properly inventoried. Adobe Commerce’s B2B feature set replaces some of it for free, but the custom parts still need rebuilding.
Subscription extensions. Several popular M1 subscription extensions have not ported cleanly to Adobe Commerce. The replacement options (Bold, ReCharge for Magento, custom builds) each have different feature trade-offs, and the migration of the existing subscriber base is a non-trivial data migration project on its own.
Custom payment methods and processors. Custom-built payment integrations for non-standard processors often require complete rebuilding because the M1 payment API differs from Adobe Commerce’s. The data migration is simple; the integration code is not.
Shipping rule engines. Stores with complex shipping rules built on M1 shipping extensions sometimes find that the equivalent Adobe Commerce extensions handle 80% of cases but not the long tail. The remaining 20% requires custom logic that did not exist in scope.
Reporting and analytics modules. M1 stores with custom dashboards or reports often face an Adobe Commerce ecosystem where the equivalent options are different (BI tools, Adobe Commerce Reports, third-party analytics). The recreation of “the report Maier looks at every Monday” is rarely on anyone’s migration scope until it is missing.
How to handle Category D (rebuild) economically
Custom rebuilds are the costliest line item in most migrations. Three patterns that contain the cost:
Bundle the rebuilds. If three extensions all touch the checkout, rebuild them as part of a unified checkout customization workstream rather than three separate workstreams. The engineering economics are much better.
Use Adobe Commerce extension patterns properly. A rebuild that uses Adobe Commerce’s plugin/observer/event system correctly is upgrade-safe. A rebuild that hacks the core or modifies vendor directories will create the same long-term cost as the original M1 extension did. Insist on patterns the team can defend.
Phase non-critical rebuilds. Functionality that is important but not launch-critical can move out of the migration scope into the first 90 days post-launch. The migration delivers in scope; the deferred rebuilds ship after, reducing the launch-window risk.
Pre-migration audit deliverable
The end product of the extension mapping is a document with:
- Complete extension inventory with vendor, version, and frontend/backend split
- Category assignment for each (A/B/C/D/E)
- Scoring for each (criticality, replacement availability, rebuild complexity)
- Recommended action with rough effort estimate
- Workstream grouping for Category D rebuilds
- Phasing recommendation: launch-critical vs. defer-able
This document drives the migration scope and pricing. Without it, the agency is pricing in unknown extension surface area, which inflates the quote conservatively. With it, the pricing becomes accurate and the conversations become substantive.
What the audit reveals that surprises merchants
Three patterns appear in roughly half of M1 stores Bemeir migrates:
The merchant has more extensions than they realized. The original inventory said 32; the actual count after audit is 47. The missing 15 were installed by prior developers and forgotten.
A meaningful fraction of installed extensions are not actually doing anything. Either they were enabled for a feature that is no longer used, or they conflict with another extension and have been silently disabled by code. The audit is the opportunity to remove them.
Several “critical” extensions are providing functionality that nobody actually uses. Surveys of store admins reveal that 10-30% of “must-have” functionality has not been touched in months. The migration is the natural moment to confirm this and shed the unused features.
The role of pre-migration cleanup
The cleanest M1 to Adobe Commerce migrations spend two to four weeks on pre-migration cleanup before the migration project starts: remove the unused extensions, document the survivors, get the merchant clear on what is in scope and what is not. The migration project is then meaningfully shorter and cheaper because it operates on a clean inventory.
Bemeir sees consistently better outcomes when this cleanup happens. The merchants who skip it carry the M1-era complexity through to Adobe Commerce, where it costs more to maintain than it ever did on M1. The merchants who do the cleanup land on an Adobe Commerce store that is operationally simpler than the M1 store it replaced, which is the version of the migration that produces good five-year outcomes.
A disciplined extension mapping is the single highest-leverage piece of pre-migration work. It is also the one merchants most consistently underspend on. The cost of getting it right is two to three weeks. The cost of getting it wrong shows up in months of post-launch firefighting on functionality that should have been settled before the migration started.
