Migrate From Adobe Commerce to Shopify Without Losing What Works
Most of the risk in an Adobe Commerce to Shopify migration sits in areas that a platform demonstration does not cover: the product data model, pricing rules, integrations, and the URLs carrying existing search traffic.
When to Migrate to Shopify
Migrating pays off in particular circumstances rather than universally. These four are the conditions under which the move most often justifies itself.
Platform Upkeep Is Consuming the Engineering Budget
Hosting, patching, security releases and upgrade projects absorb capacity that could go into trading. On Shopify that work sits with the platform, and upgrade projects stop consuming multiple months.
Cost of Ownership Is Hard to Forecast
Licence, hosting, monitoring and periodic upgrade work make the annual number difficult to predict or defend. Platform fees, transaction costs and app subscriptions are easier to budget a year out.
The Build Depends on Too Few People
A heavily customised Adobe Commerce build is often understood by a small number of engineers, which is an operational risk as much as a cost one. Shopify has a considerably larger pool of developers and agencies to draw on.
The Trading Team Is Blocked on Deployments
Campaign pages, promotions and merchandising changes need a developer and a release. Moving to Shopify puts most of those changes in the hands of merchandisers, which is often the biggest day-to-day difference after launch.
What Has to Be Rebuilt
Product and order records move with tooling. The timeline is set by the areas where the two platforms model commerce differently, which is also where migrations most often go over budget. These six get scoped before any build work starts.
Configurable Products and Attribute Sets
Adobe Commerce attribute sets and configurable products do not map one to one onto Shopify's options and variants. Large size and colour matrices, bundled products and made-to-order items each need a deliberate decision about how they are represented, and variant limits sometimes force a change in how a range is structured.
Customer Groups and B2B Pricing
Customer group pricing, tiered pricing and tax class behaviour are rebuilt rather than transferred. Depending on how your pricing works, that means Shopify's B2B features, market-level catalogues, or custom logic. Choosing between those three late in the project means rebuilding the catalogue structure that depends on them.
Cart Rules and Promotions
Adobe Commerce cart price rules can express stacking and exclusion logic that requires redesign on Shopify. Every active rule is inventoried, assessed for whether it is still in use, and rebuilt where it is. Where promotions are central to trading, the Deducto promotions engine covers cases the native tooling does not.
CMS Pages, Blocks and Widgets
Static blocks and widgets distributed through an Adobe Commerce theme become theme sections and metaobjects. The objective is a trading team that can edit campaign content without developer involvement, which is frequently among the reasons for migrating.
Store Views and Multi-Region
Websites, stores and store views have no direct Shopify equivalent. Multi-region retailers choose between markets on a single store and separate stores, and the choice affects catalogue management, pricing, currency and domain structure for years afterwards.
Extensions and Custom Modules
Every extension ends up as one of four things: a native Shopify feature, a public app, a custom app, or retired. Checking what is installed against what is still in use usually cuts the list down a long way.
Protecting Organic TrafficPreserving Search Performance Through Cutover
Organic traffic is the asset most often damaged in a replatform. Losses usually show up a few weeks after launch, when they are expensive to unwind, so this work gets done before cutover.
Complete redirect mapping
Every indexed URL is inventoried from your logs, sitemap and Search Console data, then mapped to its destination. Product, category, CMS and paginated URLs each need their own treatment, and Shopify's fixed path structure means some patterns cannot be preserved as-is.
Layered navigation and faceted URLs
Adobe Commerce layered navigation often generates thousands of indexed filter URLs, and some of them attract real traffic. Those get identified and given either a destination or a consolidation target, and the equivalent filtering is rebuilt on Shopify. Related reading: site search and filtering UX.
Post-launch monitoring
Crawl errors, index coverage and rankings are monitored daily through the weeks following cutover, while issues remain inexpensive to correct. A migration is also an opportunity to improve Core Web Vitals rather than regress them.
How a Fontis Migration Runs
Most migration failures come down to decisions made too late, or a cutover that was never rehearsed. This sequence is built to avoid both.
- 1
Discovery and Data Audit
A full review of the existing build: catalogue structure and attribute sets, active cart rules, installed extensions against what is actually used, integration points, and the URLs currently earning organic traffic. The output is a written scope with the difficult parts identified rather than deferred.
- 2
Mapping and Decisions
Before build work starts, every decision is settled: how each entity is represented on Shopify, what happens to each extension, how pricing and promotions are rebuilt, and where existing integrations reconnect. The mapping document then governs the build and keeps the scope from drifting.
- 3
Build and Rehearsal Migrations
The store is built and the data migration runs repeatedly against a full copy of production data rather than a sample. Each run surfaces records that do not fit the mapping, and the mapping gets corrected. By cutover the process has been rehearsed enough times to be predictable.
- 4
Cutover
A rehearsed sequence: a defined content freeze, a final data sync, redirects deployed with the DNS change, and a rollback procedure tested under conditions matching the live event. Timing is set against the trading calendar to stay clear of peak periods.
- 5
Post-Launch Stabilisation
Integration edge cases, promotion behaviour and SEO issues usually surface in the weeks after launch. Fontis stays engaged through that period and hands over documentation an internal team can maintain the build from.
Why FontisEcommerce Migration Specialists
Adobe Commerce, since the beginning
Understanding what is inside a customised Adobe Commerce build is most of the skill in migrating one. Fontis engineers have published platform internals work continuously since its early years, covering indexing, collections, layout, checkout and the admin, and released open source extensions used by other developers, including the Australia extension, payment modules, and the AusPost API library.
Shopify, as a partner and integrator
Fontis is an official Shopify Partner building and integrating stores on the platform, tracking Checkout Extensibility and Shopify Functions as they ship. The integration practice connects Shopify to the systems a migration depends on: ERP, POS, warehouse management and order management.
Adobe Commerce to Shopify Migration Questions
The questions ecommerce and IT leaders ask us when they are scoping a replatform.
Is migrating always the right decision?
No, and the exceptions are usually identifiable up front. Pricing built on contract rates or per-account quantity breaks, fulfilment rules that encode years of operational knowledge, and ERP integrations reading the database directly rather than a documented API all turn a migration into a substantial rebuild. A store that is patched, performing and not holding the trading team up is also a weaker candidate, and performance or conversion work on the existing build may return more over the same period. Scoping establishes which of these apply before any commitment is made.
How long does an Adobe Commerce to Shopify migration take?
It depends almost entirely on how customised your Adobe Commerce build is, not on how many products you have. A store using mostly standard functionality can move in a couple of months. A heavily customised build with complex pricing, several integrations and a large body of custom modules runs considerably longer, because each of those has to be rebuilt and tested rather than transferred. We give you a range at the end of discovery, once we know which of those apply to you, rather than a number before we have looked.
Will we lose our search rankings?
Some fluctuation in the weeks after cutover is normal even when the work is done properly. Lasting losses are usually caused by incomplete redirect mapping, thin category content on the new store, or filter URLs that were earning traffic and were dropped without a destination. We inventory indexed URLs before the build starts and treat redirects as a deliverable rather than a launch-week task, which is what keeps the fluctuation temporary.
What happens to customer accounts and order history?
Customer records and order history migrate. Passwords do not, because they are stored as hashes that cannot be transferred between platforms, so customers set a new password on their first visit. That moment needs planning as a communications exercise rather than a technical one, particularly if a large share of your revenue comes from returning logged-in customers. Loyalty balances and store credit depend on where they are held and need to be handled case by case.
Can we keep our custom Adobe Commerce functionality?
Some of it, rebuilt differently. We audit every extension and customisation against whether it is actually used, and each one ends up as a native Shopify feature, a public app, a custom app, or retired. In practice a meaningful portion of what is installed on a long-running Adobe Commerce store is no longer used by anyone, and the audit is often the point where the project scope becomes manageable.
What happens to our ERP and POS integrations?
They are rebuilt against Shopify's APIs. How much work that is depends on how your current integration was built: one that talks to a documented Adobe Commerce API is a smaller job than one reading database tables directly or depending on module behaviour. This is core Fontis work, so it is scoped alongside the migration rather than handed to a third party. See our ERP integration and POS integration services.
Will Shopify cost us less than Adobe Commerce?
Hosting, patching and upgrade projects largely go away. Platform fees, transaction costs and app subscriptions replace them as ongoing line items. Retailers who were spending heavily on upgrade cycles and infrastructure usually come out ahead; those whose build is stable and whose requirements need several paid apps sometimes do not. We model both sides on your actual numbers during discovery so the business case is not built on an assumption.
Get StartedBegin With a Technical Scoping Conversation
An initial scoping conversation covers the existing Adobe Commerce build, its integrations and the trading calendar, and identifies which parts will be difficult, including anything that would make a migration a poor investment.
Fontis has been engineering ecommerce systems for over 20 years, on Adobe Commerce since its early days and on Shopify as a Shopify Partner. We are independently owned, so the recommendation you get is not shaped by a platform relationship.
If you are working towards a launch date that avoids your peak trading period, the scoping work needs to start well before the build does.