Every Magento 1 store has a folder full of custom modules. Some were written by the original launch agency, some were added by in-house developers over the years, some were one-off favors that nobody fully remembers. When the migration to Adobe Commerce arrives, all of them have to be evaluated. The default instinct is to migrate everything because each module presumably solved a business problem at some point. The disciplined approach is to audit each module against current business reality and decide whether it survives, and the discipline pays back enormously in lower migration cost and a cleaner future codebase.
This piece walks through a practical custom module audit framework for Magento 1 to Adobe Commerce migrations. It is written for engineering leaders, technical architects, and the agency teams running these migrations. The framework comes out of Bemeir’s Magento 1 migration practice, where the audit step has consistently determined whether the project lands on time and on budget.
The Three Categories
Every custom module ends up in one of three buckets:
- Lift: the module is well-written, still serves an active business need, and works on Adobe Commerce with minor adjustments. Lift it forward.
- Rewrite: the business need still matters but the existing module is either platform-incompatible, badly architected, or solving a problem in a way Adobe Commerce now solves natively.
- Kill: the business need has disappeared, the functionality has been replaced by something else, or the module is silently broken and nobody noticed.
The audit’s job is to put every custom module into one of these three buckets, with explicit reasoning. The buckets drive the migration scope, and the reasoning becomes the project documentation.
The Inventory: What Modules Exist
The first step is a complete inventory of custom modules. On Magento 1 this means walking the `app/code/local` directory, the `app/code/community` directory (for any modules that were modified or are misclassified), and any directories under `vendor` that contain locally-modified packages.
For each module, capture:
- Module name and namespace
- Original author or vendor (if known)
- Date of last modification
- Brief description of what the module does (from the README, the developer’s memory, or by reading the code)
- Files modified, including any core overrides
- Database tables created or modified
- Dependencies on other modules
- Frontend assets (templates, layouts, JavaScript, CSS)
The output is a spreadsheet with one row per custom module. For most mid-market Magento 1 stores, this list runs to 30-80 modules, sometimes more. Don’t be alarmed by the number. The point of the audit is to thin it.
Decision Criterion One: Is the Business Need Still Real?
Walk through each module with a business owner, usually the head of eCommerce or a product manager who knows what features customers and merchandisers actually use. For each module, ask: does anyone still need this?
The answers will surprise you. Modules built to support a promotional campaign that ended in 2019 are still installed. Modules supporting a B2B feature that was sunsetted are still running. Modules for a custom integration with a vendor that no longer exists are still in production.
Modules whose business need has disappeared are kill candidates. The migration is the opportunity to retire them.
Decision Criterion Two: Does Adobe Commerce Solve This Natively Now?
Adobe Commerce in 2026 includes capabilities that Magento 1 did not. Many custom modules were built to fill gaps that have since been filled by the platform itself. Examples:
- Custom B2B features that Adobe Commerce B2B now supports natively
- Custom search modules that OpenSearch handles
- Custom multi-source inventory that MSI replaces
- Custom checkout customizations that Adobe Commerce’s checkout configuration now exposes
- Custom GraphQL endpoints that the standard GraphQL coverage now includes
For each module, check whether the equivalent functionality exists in Adobe Commerce out of the box. If it does, the module is a rewrite candidate, the business need persists but the implementation should be replaced with the platform-native equivalent.
Bemeir’s Adobe Commerce practice tracks these capability migrations explicitly during audits, because the number of custom modules that can be retired in favor of native functionality has grown substantially with each Adobe Commerce release.
Decision Criterion Three: Quality of the Existing Implementation
For modules that need to migrate (either lift or rewrite), the next question is whether the existing implementation is worth carrying forward. Walk through the code and assess:
- Does it follow Magento 1 conventions, or does it have unusual patterns that will not translate?
- Does it modify core code directly, or does it use the rewrite/observer pattern?
- Does it have tests?
- Are dependencies declared cleanly?
- Is the database schema declarative or imperative?
- Is the code readable to a developer who has not seen it before?
Modules that score well on these dimensions are lift candidates. Modules that score poorly should be rewritten rather than ported, because porting bad code to a new platform produces bad code on the new platform.
| Module characteristic | Recommendation | Reasoning |
|---|---|---|
| Active business need, clean code | Lift | Migration cost is low, value preserved |
| Active business need, messy code | Rewrite | Migration is the right time to fix it |
| Native Adobe Commerce equivalent | Replace with native | Reduce custom code surface |
| Active need, complex integration | Rewrite with modern patterns | Adobe Commerce supports better patterns |
| Inactive business need | Kill | Don’t migrate dead code |
| Promo-specific or campaign-specific | Kill | Recreate if needed later |
| Vendor-specific, vendor still exists | Lift or check for vendor-supplied M2 version | Often the vendor has ported it |
| Vendor-specific, vendor gone | Rewrite or replace | No support path forward |
Decision Criterion Four: Cost to Migrate vs Cost to Rebuild
For modules that are close calls between lift and rewrite, the deciding factor is usually cost. Estimate the migration cost for each path:
- Lift cost: hours to port the module from Magento 1 patterns to Adobe Commerce 2.4+ conventions, plus testing
- Rewrite cost: hours to design and build the equivalent functionality from scratch on Adobe Commerce
- Replace cost: hours to configure or extend the Adobe Commerce native equivalent
In many cases the rewrite cost is comparable to the lift cost because the Magento 1 code is small enough that rebuilding it is straightforward. In those cases, rewrite, the rebuilt module will be cleaner and easier to maintain. In other cases the lift cost is much lower, especially for larger modules with well-defined behavior, and the lift is the right call.
Decision Criterion Five: Dependencies and Coupling
Some modules depend on others. The audit needs to surface these dependencies so that decisions about one module don’t surprise another. Build the dependency graph: which modules call which, which share database tables, which override the same core classes.
Coupled modules need joint decisions. Killing module A while keeping module B that depends on A is a recipe for a broken store. Use the dependency graph to ensure decisions are consistent.
The Vendor Question
Modules supplied by third-party vendors (Aheadworks, Mageworx, Amasty, MGS, Mageplaza, and many others) often have Adobe Commerce versions available. Check directly with the vendor for each. The vendor-supplied M2 version may have different licensing, different feature scope, or different pricing, but it is almost always cheaper than rebuilding from scratch.
For vendors who have not produced an M2 version, the practical decision is between rewriting in-house and finding a replacement vendor. Replacement is often cheaper if the functionality is generic. Rewriting is often necessary if the customization is specific to your business.
Adobe Commerce Marketplace is the searchable index for current vendor offerings, and major vendor websites maintain compatibility matrices for Adobe Commerce versions.
The Documentation Output
The audit produces a written document, a per-module decision record. For each module in the inventory, the document captures:
- Final disposition: lift, rewrite, replace, kill
- Reasoning behind the disposition
- Estimated effort if lift or rewrite
- Replacement option if replace
- Sunset plan if kill (data migration, customer communication, etc.)
- Owner of the decision and the date it was made
This document becomes part of the migration project’s source of truth. It also becomes a reference for the future, because the next engineer to ask “why did we get rid of module X” will appreciate the answer being written down.
Bemeir’s Magento 1 migration practice treats this document as a deliverable in the discovery phase, and the discipline of writing it has consistently shortened migrations by helping the team avoid mid-project debates about scope. The same discipline applies on broader Adobe Commerce engagements and on Hyvä migrations where third-party module compatibility decisions follow the same pattern.
What the Audit Reveals
Almost every Magento 1 codebase that goes through this audit comes out with 30-50% fewer custom modules in the post-migration codebase than the pre-migration codebase. Some of the kills are obvious (the promo module from 2019 that nobody removed). Some are surprising (a vendor module that the team thought was critical but turns out to duplicate functionality the platform now provides). Either way, the migration becomes substantially cheaper because the team is not paying to port code that did not need to survive.
The audit also has a longer-term effect. The discipline of asking “is this still worth maintaining” doesn’t have to stop at the migration. The same audit, run annually on the Adobe Commerce codebase, keeps custom code surface small and the long-term maintenance cost manageable. The migration is a forcing function. The discipline it teaches is the durable value.
For more on what the post-migration codebase should look like, the Adobe Commerce technical architecture documentation is a good reference for modern patterns, and Magento Open Source’s GitHub repository is the canonical reference for current platform conventions.
