Migration to Magento (Adobe Commerce): A Risk Playbook

Most legacy eCommerce migration projects do not fail in development. They fail in discovery – before a single line of code is written – when the team treats the legacy platform as a known system and underestimates how much of the business actually lives inside its source code, observers, cronjobs, and undocumented integrations. By the time the build phase reveals the gap, the timeline and the budget are already gone.

This is a risk playbook for the discovery phase of a legacy eCommerce migration to Magento (Adobe Commerce). It walks through what your discovery must catch, where source-code archaeology pays for itself, what mid-market projects actually cost in 2026, how the 2.4.4 end-of-support deadline and Adobe Commerce as a Cloud Service (ACCS) change the calculus this year, and the risk-mitigation checklist that separates a smooth go-live from a six-month firefight. For the executive-level step-by-step on scope, phases, and project planning, the executive playbook companion covers the build side once discovery is locked.

Overview

• Magento migration risk concentrates in discovery, not development. Hidden business logic in legacy custom modules, observers, and middleware is the single largest cause of mid-build surprises.
• Mid-market replatform to Magento runs $120,000 to $400,000 all-in for 2026, with theme rebuild ($40K–$100K) and 8–25 custom modules driving most of the spend (Bemeir).
• The April 2026 end of extended support for Adobe Commerce 2.4.4 and the August 2026 end-of-life for 2.4.5 and 2.4.6 set a real urgency floor for legacy stores planning to remain on supported software (Adobe Experience League).

Why discovery is where Magento migrations break

A migration project’s first official document is a discovery brief built from the project owner’s mental model of the platform. That mental model is almost always incomplete – not because the owner is wrong, but because the owner inherited a platform that has been customized for years by developers who are no longer around. The original brief is a best-guess scope estimate that grows the moment a developer opens the legacy codebase.

In Magento and Adobe Commerce migration projects, that gap shows up in five reliable ways:

• Custom modules built years ago that quietly drive a critical workflow (price-rule overrides, partial-shipment logic, channel-specific pricing). The project owner forgot they existed.
• Observers and plugins that mutate core behavior at runtime, with no visibility from the admin UI.
• Cronjobs that synchronize the catalog, inventory, or orders against an ERP or middleware. If the source platform has no documentation, these are invisible until they fail in the new environment.
• Controller modifications and entry points patched into the legacy core – overrides that bypass standard request handling.
• Middleware integrations (often older .NET or PHP layers) that behave as black boxes and only expose their contract through input/output observation.

Forrester frames this clearly in its replatforming guidance: replatforming is strategy work, not a tech swap, and technology constraints are a leading cause of stalled eCommerce performance among scaling businesses (Forrester). When the discovery phase treats the legacy as a documented system, the strategy work skips the most expensive question: what does the platform actually do today that the business cannot lose tomorrow.

What your discovery phase must catch

A defensible discovery phase produces an inventory of the legacy platform that is detailed enough to estimate the migration accurately. Eight categories of evidence cover most of the risk surface. Skip one and a mid-build surprise gets very likely.

1. Data model and entity sprawl

Catalog the product, customer, and order entity attributes – including the custom EAV attributes added over time. Find the attributes that are referenced by code but no longer surface in the admin UI: they often hold ERP keys, sync flags, or legacy migration breadcrumbs. Map every attribute to a target field in Magento, and flag the ones that have no home until a custom attribute is built.

2. Hidden business logic

Read the source code. That does not mean reading every file. It means tracking observers, plugins (interceptors), and event subscribers, controller modifications and rewrites, cronjobs and scheduled tasks, and any third-party module that overrides core. Make an explicit list of what each does and whether the business still depends on it. Review the list with the project owner – this is where business logic that has not been spoken about in years tends to surface.

3. Custom checkout and cart rules

Checkout is the highest-risk surface for any migration. Catalog every delivery method, payment method, tax rule, and cart-price rule. Find the custom logic layered on top: B2B price overrides, channel-specific delivery calculators, partial-payment workflows, deposit logic, store-credit balances. Validate that the target Magento configuration can express the same rules without code, or budget the customizations explicitly.

4. Integrations and middleware

Document every external system the legacy platform talks to: ERP, PIM, OMS, CRM, search, reviews, delivery carriers, payment gateways, tax engines, marketing automation. For each, capture the contract – request shape, response shape, authentication, sync frequency, failure mode. If the integration uses a middleware (a .NET layer between ERP and storefront is common), treat the middleware as a separate audit target with its own input/output observation work.

5. Extensions and theme

List every installed third-party extension and confirm which have Magento (Adobe Commerce) 2.4.x equivalents. Several modules common on Magento 1 and older Adobe Commerce versions are not maintained for current Magento. Plan replacements and rebuilds explicitly. Theme is its own bucket – a Luma rebuild lands $40K–$80K, a Hyvä rebuild lands $50K–$100K for mid-market scope (Bemeir). Hyvä Themes is now the default frontend choice for new builds, and the Hyvä migration result on a real Magento project produced 111% YoY sales growth post-launch.

6. Performance baseline

Capture the legacy platform’s real performance: median and P95 server response, Core Web Vitals, Time to First Byte under load, cart-to-checkout drop rate. Without a baseline, the migration team cannot defend their post-launch numbers against “the old site felt faster”. A baseline also identifies the bottlenecks worth fixing in the new build, instead of porting them forward.

7. SEO equity

Map URL structure, canonical rules, redirects already in place, structured data, sitemap behavior, and the top 200 organic landing pages by traffic and revenue. SEO equity is the most fragile thing in a migration – losing it costs more than any extension rebuild. Plan a 1:1 redirect map and a holdback strategy for any URL change that is not strictly necessary.

8. Payment, tax, and shipping rules

These three rule engines often hide the longest tail of legacy customization. Find every override – tax rule per region, shipping rule per SKU class, payment-method conditional logic. The default Magento configuration covers most of it, but rarely all. Document the gap before estimating, not after.

Source-code archaeology: what reading legacy code actually catches

When documentation is missing or unreliable, the only honest discovery method is to read the source. Adobe’s own migration guidance for moving from Adobe Commerce on-premise to Adobe Commerce as a Cloud Service describes two paths – replicated and incremental – and explicitly recommends the incremental path for large merchants with many customizations, where data, customizations, and integrations migrate in stages (Adobe Experience League). The incremental path only works if discovery has already mapped the customizations. Otherwise the staging is guesswork.

Source-code archaeology in practice covers four moves:

• Track the entry points. Controllers, API endpoints, observers, plugins, cronjobs, command-line scripts. These are the only places business logic can enter or leave the legacy platform. Inventory them all.
• Follow the hooks. Where the legacy platform extends or overrides core behavior, document what it does in plain language. “Observer X fires on customer_save and updates field Y in the ERP” is the level of detail that defends an estimate.
• Read what is referenced but not visible. Database columns that have no admin UI exposure. API endpoints not documented in the OpenAPI/Swagger spec. Hooks tied to deprecated extensions. The legacy platform’s swagger and admin UI together miss 30% to 60% of the real surface area in typical mid-market projects.
• Validate by input/output. Where a middleware or third-party black box cannot be opened, observe its requests and responses in production traffic over a representative period. This is slower than reading code, but unavoidable for closed systems.

A concrete example from a recent scandiweb project: on an OXID-to-Magento migration with archaic ERP and outdated .NET middleware, the legacy Swagger documentation was auto-generated, incomplete, and misleading in places – required fields were marked optional, deprecated endpoints were still listed, and undocumented endpoints handled critical workflows. Source-code archaeology surfaced a “delete” value passed in price fields that meant different things in different contexts: remove a discount, unassign a variant, delete the parent, or do nothing. Without that discovery, those rules would have collapsed on the day of the launch. With it, the migration documented the rules explicitly before any code moved.

What is mid-market Magento migration actually costing in 2026

Mid-market merchants moving from Magento 1, older Adobe Commerce, or an off-Magento legacy to current Magento (Adobe Commerce) are spending $120,000 to $400,000 all-in in 2026 (Bemeir). The components break down roughly as follows:

• Theme rebuild: $40K–$80K on Luma, $50K–$100K on Hyvä. Hyvä is the higher-cost option but pays back in performance and developer velocity over the platform lifetime.
• Custom modules: typical mid-market sites carry 8–25 custom modules that must be rebuilt rather than migrated. Modules are the single largest cost driver after the theme. This is exactly the surface area source-code archaeology catches first.
• Customer data migration: $10,000 to $25,000 per Emerline’s 2026 benchmarks (Emerline).
• Order history migration: $15,000 to $40,000 depending on volume and complexity.
• Integrations: ERP, PIM, OMS, CRM, payment, delivery – each integration adds five to thirty engineering days depending on complexity.

These ranges assume a defensible discovery phase. Skipping discovery moves a 20% contingency budget to 50% or higher, and shifts the project from fixed-scope to time-and-materials mid-build – the position no executive wants to defend to a board.

Gartner’s broader picture: by 2026, businesses on legacy infrastructure are spending up to 40% more on tech maintenance than businesses on modern platforms (Gartner via Accio). The maintenance premium on the existing legacy stack is often the strongest cost-of-inaction argument when the migration budget feels steep.

How the 2026 Adobe roadmap changes the migration timing question

Three platform shifts make the 2026 timing different from the 2024 conversation.

Adobe Commerce 2.4.8 is the current release. Released in 2025, it adds PHP 8.4 and MariaDB 11.4 support, 500+ quality fixes, and GraphQL improvements for Edge Delivery storefront. Its support window runs through April 2028 (Adobe Experience League). New migrations should target 2.4.8 as the baseline – migrating to an earlier version creates a second upgrade project inside twelve months.

Software lifecycle deadlines are concrete. Adobe Commerce 2.4.4 reached end of extended support on April 14, 2026. Versions 2.4.5 and 2.4.6 reach end of support on August 11, 2026 (Adobe Experience League). Merchants on these versions are out of supported software in 2026 and lose access to security patches – a hard urgency anchor for any “do we replatform now or later” conversation.

Adobe Commerce as a Cloud Service (ACCS) launched in June 2025. ACCS is Adobe’s fully managed multi-tenant SaaS Magento – headless, automatically updated, zero DevOps overhead. It changes the long-running assumption that Adobe Commerce means owning the infrastructure (Adobe Experience League). For a legacy migration in 2026, the target is no longer just “Adobe Commerce on PaaS” – it is also “ACCS, with the implicit choice between staying on-prem control and moving to a managed cloud service”.

The choice between Adobe Commerce and Magento Open Source has also shifted in 2026 – the Adobe Commerce vs Open Source comparison covers the licensing, feature, and support trade-offs for merchants who have not locked the edition yet. For broader context on Magento’s market position, the Magento market share data is a useful frame for the migration business case.

Migration tooling: Bulk Data Migration Tool and Delta Mode

Adobe is building new migration tooling alongside ACCS. The Bulk Data Migration Tool moves catalog, customer, and order data from on-premise Adobe Commerce to ACCS components, and a Delta Mode is arriving in 2026 to support incremental sync between PaaS and the new Cloud Service (Adobe Experience League). Delta Mode lets a merchant run on-premise and ACCS in parallel during a phased migration – reducing cutover risk for large catalogs.

The important caveat for the discovery question: the new tooling reduces the data-migration work, but does not eliminate the customization-mapping work. Custom modules, observers, cronjobs, middleware integrations, and overridden rules still need to be discovered, rebuilt, and tested. The tooling handles the data – source-code archaeology handles the logic. Both are required for a defensible 2026 migration plan.

What a defensible discovery process actually catches

Two named scandiweb projects make the discovery-first approach concrete.

Zvaigzne legacy migration – a regional publishing brand moved from a deeply customized legacy eCommerce platform to Magento with a Hyvä frontend. Discovery exposed legacy custom workflows that were not in the original brief, plus integrations with the publishing back-office that needed custom Magento modules to preserve. The migration launched with no business-critical regression because the integrations were mapped before any code began.

Hyvä migration result – a mid-market Magento merchant migrated to Magento 2 with a Hyvä frontend rebuild. The project produced 111% YoY sales growth in the year following launch, driven by the storefront performance gains and a clean rebuild of the cart, checkout, and product pages. The discovery phase identified the legacy theme and module sprawl that had been blocking performance work for years – the migration was the moment to address it, not paper over it.

A third reference point – Sports Group Denmark’s 10x D2C revenue increase – came from a multi-brand, multi-region Magento transformation where discovery had to map several legacy stores, B2B/D2C rules, and a deep PIM integration before the rebuild started. The complexity made the discovery work non-optional. The result is the multi-brand commerce architecture that is now running across the group.

These projects share one pattern: a long-enough discovery phase to find the hidden business logic and a strict gate before development begins. The pattern is not glamorous, but it is what separates a 90-day post-launch optimization sprint from a 9-month firefight. The standard reference for that optimization sprint – the post-migration challenges playbook – covers what to expect once go-live is reached.

Is now the right time to replatform off a legacy platform?

For merchants on Magento 1, Magento 2.4.4, 2.4.5, or 2.4.6, or any non-Magento legacy with declining commercial support: yes, 2026 is the time. Three forces line up.

Software support windows close in 2026. April for 2.4.4, August for 2.4.5 and 2.4.6. Running on unsupported versions in production is a security and compliance posture that does not survive an audit (Adobe Experience League).

Legacy maintenance premium is 40% higher. Gartner’s 2026 framing puts the legacy-infrastructure maintenance cost at up to 40% above modern-platform equivalents (Accio). The savings curve crosses the migration cost faster than most merchants estimate.

ACCS resets the build-versus-buy decision. Adobe’s managed cloud service shifts the long-term operational cost down for merchants who would prefer to stop owning infrastructure. The migration target in 2026 is wider, and the right choice depends on where the business wants its team’s time to go.

The merchants for whom 2026 is not the right time: stores that are about to be acquired, sold, or merged into another commerce stack, stores currently running on supported 2.4.7 or 2.4.8 with no major customization debt and a clean integration map, and stores in the middle of a separate, larger strategic change where adding a replatform would be the third major initiative in flight. For the rest, the math works.

What’s the single biggest hidden risk in a legacy-to-Magento migration?

The biggest hidden risk is undiscovered custom business logic embedded in observers, plugins, or custom modules that the original developer added without documenting and the project owner has forgotten about. This logic surfaces during user acceptance testing – when a business user runs a workflow that the new platform does not support – and forces an emergency rebuild three weeks before launch. Source-code archaeology in the discovery phase is the only reliable mitigation.

How long does a legacy-to-Magento migration take?

A mid-market legacy-to-Magento migration with a defensible discovery phase runs 4 to 9 months end-to-end, depending on catalog size, integration count, and theme scope. Enterprise migrations with multi-store, multi-region, or B2B/D2C complexity run 9 to 18 months. The discovery phase itself typically lasts 4 to 10 weeks – longer for projects with no usable documentation. Compressing discovery is the most common cause of schedule overrun later, because the time saved upstream comes back as rework downstream at three to five times the cost.

FAQ

What is a Magento (Adobe Commerce) discovery phase, and why does it matter?

The discovery phase is the formal pre-development work that maps the legacy eCommerce platform’s data model, custom logic, integrations, and business rules before any code is written for the new Magento environment. It matters because the legacy platform almost always carries undocumented business logic that the project owner has forgotten about. Discovery is the only point in the project where finding that logic is cheap. Once development starts, every missed item is a change request.

How do you migrate to Magento when the legacy documentation is missing or unreliable?

When documentation is missing, source-code archaeology is the only reliable method. The migration team reads the legacy codebase to track observers, plugins, cronjobs, controllers, and custom modules, documents what each does, reviews the inventory with the business, and turns it into a structured discovery deliverable. For black-box middleware that cannot be read, the team observes input/output in production traffic over a representative period. This work is slower than relying on documentation, but it produces a defensible scope.

Should we move to Adobe Commerce as a Cloud Service or stay on Adobe Commerce on-premise?

It depends on operational preference and customization profile. ACCS is the right choice for merchants who want to stop owning infrastructure, accept Adobe’s automatic update cadence, and run a relatively standard catalog and checkout. On-premise Adobe Commerce remains the right choice for merchants with heavy customization, regulatory constraints that require self-hosting, or operational teams already optimized to run the stack. The migration tooling supports both targets in 2026.

What does a Magento migration cost in 2026?

Mid-market migrations to current Magento (Adobe Commerce) run $120,000 to $400,000 all-in. The breakdown: theme rebuild $40K–$100K, custom-module rebuilds (typically 8–25 modules) drive the largest variance, customer data migration $10K–$25K, order history $15K–$40K, integrations five to thirty engineering days each. Enterprise multi-store migrations cost above that range. The numbers assume a defensible discovery phase – skipping discovery typically adds 30% to 50% in contingency and rework.

When does Adobe Commerce 2.4.4 reach end of support?

Extended support for Adobe Commerce 2.4.4 ended April 14, 2026. Adobe Commerce 2.4.5 and 2.4.6 reach end of support on August 11, 2026. Merchants on these versions are running unsupported software in 2026 and should plan their migration timing against those dates.

Does the new Bulk Data Migration Tool replace the discovery phase?

No. The Bulk Data Migration Tool and the 2026 Delta Mode move catalog, customer, and order data between on-premise Adobe Commerce and Adobe Commerce as a Cloud Service. The tooling reduces the data-migration engineering work but does not discover or rebuild custom business logic, integrations, or overridden rules. Discovery and source-code archaeology remain mandatory.

What is the difference between this article and the broader Magento 2 migration guide?

This article focuses on the discovery phase – what to audit, what to read in the source code, and where the hidden risks live before development begins. The broader executive playbook companion covers the build-side step-by-step: project phases, team structure, decision frameworks, and post-migration optimization. The two are designed to be read together – discovery first, then the playbook for the build.

Planning a legacy eCommerce migration to Magento (Adobe Commerce) and not yet sure what discovery should cover for your stack? scandiweb’s migration team runs the discovery phase as a structured audit – source-code archaeology, integration mapping, custom-module inventory, and a defensible scope before any code is written. Scope your migration with our team and we will walk through what your platform actually carries before the budget conversation starts.

Share on: