The question that derails most Magento 1 migration conversations is “how much will the theme cost to rebuild?” The honest answer is that nobody can give you a defensible number until they have inventoried what the existing theme actually does. Most agencies skip the inventory and quote from intuition. The number they produce is wrong, sometimes by a factor of two or three, and the project blows through budget mid-build when the unbudgeted customizations surface.
The inventory exists to prevent that outcome. It is a structured exercise that takes one or two senior engineers about two weeks to complete on a typical mid-market Magento 1 storefront, and it produces a budget that holds up to scrutiny. The output is also useful beyond the cost question: it tells you what to keep, what to retire, and what to redesign rather than reproduce.
Bemeir’s Magento migration practice has run this inventory dozens of times across the long tail of Magento 1 stores that are finally moving to Adobe Commerce. The framework below is what we use, and the cost ranges are what the numbers actually come out to.
What “rebuild” means in 2026
The first thing to clarify is what you are actually rebuilding. There are three paths.
The first is reproducing the existing Luma-style theme on Adobe Commerce, ported feature for feature. This is the cheapest path and the worst long-term choice. You are spending the migration budget to preserve a theme that is six to eight years old, was designed against device profiles that no longer dominate, and ships the same JavaScript footprint that hurt your Core Web Vitals on Magento 1.
The second is migrating to Hyvä on Adobe Commerce, which uses Alpine and Tailwind and abandons most of the inherited theme architecture. This is more work upfront but delivers a much faster store and is the path the majority of mid-market migrations choose in 2026.
The third is migrating to a headless storefront, where Adobe Commerce becomes the API and the frontend is a separate Next.js, Remix, or Hydrogen application. This is the most work and is appropriate for a subset of stores where the team has dedicated frontend engineering and a strong reason to decouple.
The inventory exercise differs slightly by path, but most of the framework is the same. The cost ranges below assume a Hyvä rebuild because that is the path most mid-market clients choose. For a like-for-like Luma rebuild, subtract roughly 20 percent. For headless, add roughly 40 percent.
Step one: inventory the theme components
Walk the storefront page type by page type and list every component. Header, footer, navigation, product card, product listing page, product detail page, configurable swatches, image gallery, cart, mini-cart, checkout steps, account dashboard, order history, wishlist, compare, search results, autocomplete, login, registration, password reset, CMS pages, contact form, newsletter signup, customer reviews, related products, recently viewed, upsell, cross-sell, before-and-after sliders, customizers, gift card flows, B2B-specific blocks, and any unique homepage modules.
This list is longer than most teams remember. A typical mid-market Magento 1 storefront has 40 to 80 distinct theme components when actually counted. Each one needs a row in the inventory.
For each component, capture five attributes. The component name and where it appears. The complexity, scored 1 to 5. The dependencies, meaning other components or modules that interact with it. The business value, scored 1 to 5. The estimated rebuild effort in days. The total is the sum, plus a buffer for surfaces you missed.
The table below is the format. Use a spreadsheet, not a document, so you can sort and filter.
| Component | Where it appears | Complexity (1-5) | Dependencies | Business value (1-5) | Rebuild days |
|---|---|---|---|---|---|
| Mega menu | Header, every page | 4 | Nav cache, taxonomy | 5 | 8 |
| Product gallery | PDP | 3 | Image processor | 5 | 4 |
| Configurable swatch | PDP, listing | 4 | Inventory, variants | 5 | 6 |
| Layered nav | Listing pages | 4 | Search, filters | 5 | 7 |
| One-step checkout | Cart, checkout | 5 | Payment, shipping | 5 | 12 |
| Custom upsell carousel | PDP, cart | 3 | Recommendation engine | 3 | 3 |
| Loyalty badge | Header, PDP | 2 | Loyalty extension | 4 | 2 |
The inventory should fill a screen. Most stores end up with 50 to 70 rows once the exercise is done thoroughly.
Step two: classify customizations
Each component in the inventory falls into one of four classes. Standard, which means the component does what Luma did and the Hyvä equivalent is mostly out-of-the-box. Light customization, which means the component has a few visual or behavioral tweaks but is recognizable. Heavy customization, which means the component has business logic that does not exist in standard Magento. Bespoke, which means the component was written from scratch and has no platform equivalent.
The classification drives the cost. Standard components rebuild for one to three days each. Light customization rebuilds for three to seven days. Heavy customization rebuilds for seven to 20 days. Bespoke components are open-ended and require their own scoping exercise.
The single biggest source of cost surprise on migration projects is misclassifying heavy customization as light. A component that looks visually similar to standard Luma is often hiding business logic that took six months to build and tune. The rebuild is not a styling exercise. It is a business logic exercise, and it costs accordingly.
The Adobe Commerce DevDocs guide to theme structure is a useful reference for what the platform considers standard. Anything that deviates from that pattern is a customization that needs to be accounted for.
Step three: identify the unknowns
Every Magento 1 storefront has surfaces that nobody on the team remembers. The original developer left. The agency that built it dissolved. The custom module that handles the wholesale catalog was bolted on by a third party who is no longer reachable.
Reserve time in the inventory exercise specifically to find the unknowns. Walk the codebase. Audit the admin for installed extensions. Run a database query for any tables that do not match standard Magento schemas. List every cron job and what it does. Identify the API integrations and what each one consumes.
The unknowns are usually 10 to 20 percent of the total work. They look small in the inventory because each one is a single line. They are not small in execution because the lack of documentation means the rebuild requires reverse engineering. Budget 15 percent of the total rebuild effort against the unknowns column and you will be approximately right. Skip the unknowns column and you will be wrong by a noticeable margin.
Step four: cost the rebuild
Once the inventory is complete and classified, costing is mechanical. Multiply rebuild days by your blended day rate for the engineering team that will do the work. Add project management overhead at 15 percent. Add QA at 20 percent. Add design at 15 percent for components that need visual redesign. Add a contingency of 15 to 25 percent for unknowns.
For a typical mid-market Magento 1 to Adobe Commerce Hyvä rebuild, the totals come out somewhere in this range:
| Component class | Typical count | Days each | Total days |
|---|---|---|---|
| Standard | 25 to 35 | 1 to 3 | 35 to 90 |
| Light customization | 15 to 25 | 3 to 7 | 60 to 150 |
| Heavy customization | 5 to 12 | 7 to 20 | 50 to 200 |
| Bespoke | 2 to 5 | 15 to 60 | 40 to 250 |
| Unknown reserve | n/a | n/a | 30 to 80 |
The composite typically lands between 250 and 750 engineering days for the theme rebuild alone, depending on the complexity of the existing storefront. At a blended day rate of 1,200 dollars, that is between 300,000 and 900,000 dollars in engineering, before project management, QA, design, and contingency.
These numbers are deliberately ranges. Stores at the lower end have minimal customization. Stores at the upper end have heavily customized B2B functionality, complex configurable product flows, and bespoke checkout logic. The inventory is what tells you where your specific store lands within the range.
Step five: decide what to retire
The most underused output of the inventory is the retire-or-rebuild decision. Many components in the inventory should not be rebuilt at all. The custom upsell carousel that was bolted on in 2018 to support a campaign that ended in 2019. The loyalty badge that was added for a partner who no longer exists. The compare flow that nobody uses according to your analytics.
For each component, ask three questions before deciding to rebuild it. What is the measurable business value, in revenue or in user engagement, in the last 12 months? Is there a platform-native equivalent on Adobe Commerce or Hyvä that delivers similar value with less custom code? Does retaining the component create technical debt that will slow future development?
Retiring 20 to 30 percent of inventoried components is common on the migrations Bemeir has scoped. The retire decision is faster, cheaper, and produces a cleaner storefront on the new platform. It is also the conversation that founders sometimes find difficult because retiring functionality feels like loss, even when the functionality is unused. The data from the inventory is what makes this conversation tractable. The Google Analytics 4 documentation on event measurement is useful for pulling the usage numbers cleanly.
What the inventory unlocks
The inventory is not just a cost estimation tool. It is the foundational artifact for the migration project. It tells you the scope of the rebuild, the budget that is defensible to the CFO, the project timeline, the staffing model, the retire-or-rebuild decisions, and the risk register for the unknowns.
Bemeir treats the inventory phase as its own paid scoping engagement, typically 15,000 to 35,000 dollars depending on the size of the storefront. That investment shows up in the form of a migration plan that holds. Stores that skip the inventory and start the rebuild against a guess almost always blow through budget by 40 to 80 percent before the project is done.
If you are evaluating the same migration math against Shopify Plus, Shopware, or BigCommerce, the inventory framework translates with platform-specific adjustments. The categories of work, the classification, the unknowns reserve, and the retire-or-rebuild discipline all apply. The numbers shift because the platforms have different starting baselines for what is standard versus customized.
Two weeks of inventory work is the cheapest insurance available against a multi-quarter migration becoming a multi-year nightmare. Start there before you start anything else.
