Forever New's Magento to Shopify move: what Adobe Commerce teams do

Forever New has completed a global e-commerce migration from Magento to Shopify across four markets, according to Mi-3.com.au. For teams running Adobe Commerce, which grew out of Magento, it is a reminder that replatforming is a live option for multi-market retailers, and that the useful question is not 'should we follow?' but 'what would our own audit say?'

Key takeaways

• One completed migration is a data point. It says little about your catalogue, markets or team until you test your own situation against it.
• Mi-3.com.au. reports four markets. That is the detail worth studying, because multi-market operation is where platform cost and complexity tend to show up.
• Audit before you react: platform cost, release speed, extension and customization debt, and integration load.
• If you do replatform, go market by market with agreed measures and a rollback plan, not one big cutover.
• Use a partner for architecture, data migration and integration risk. Keep the roadmap, the content model decisions and the measurement in-house.

What did Forever New actually do, and what do we not know?

Mi-3.com.au. reports that Forever New has completed its global e-commerce migration from Magento to Shopify across four markets. That is the whole of what the headline and summary give us, and it is worth being exact about it. The reported fact is a finished move, on a global footprint, from one platform to another.

What the headline does not tell you is why. It does not say whether cost, speed, staffing, a merchandising need or an agency relationship drove the decision. It does not say how long the programme took, what it cost, or what happened to conversion or page speed afterwards. If you want those details, read the Mi-3.com.au. report itself and treat anything beyond it as unknown.

That gap matters because the lazy reading of a story like this is 'a retailer left, so the platform must be failing.' Retailers change platforms for many reasons, and several of them have nothing to do with the software's quality. A change of leadership, a merger of regional teams, or a lapsed support contract can each tip a decision that was borderline for years.

Also note the wording: Magento, not Adobe Commerce. The two share a lineage, and many teams still say Magento for what is now Adobe Commerce. Whether the retailer was on the commercial product or the open-source edition is not something the headline settles, and it changes the comparison. Licensing, support and cloud hosting arrangements differ between them.

Why does a four-market migration matter more than a single-store one?

Moving one store is a catalogue, a theme, some integrations and a redirect map. Moving four markets multiplies almost every part of that, and the multiplication is not linear.

Each market tends to bring its own currency, tax treatment, payment methods, shipping carriers, languages or locale rules, and legal copy. Each also tends to bring its own quirks in how the catalogue is priced and merchandised. If those were handled on the old platform through a mixture of configuration, custom modules and manual workarounds, then migrating means someone has to write down what the system actually does, which is often different from what people believe it does.

That is the real value of a multi-market migration to the migrating team: it forces a full inventory. It is also the main cost. Teams that have been on a platform for years usually carry behaviour nobody documented, such as a pricing rule added for a promotion three years ago, or a shipping exception for one region that quietly lives in an extension.

For teams running Adobe Commerce across several storefronts, this suggests a cheaper first move than any migration: do the inventory now. A written list of what each market needs, which of those needs are met by configuration, which by custom code, and which by manual process, is useful whether you stay or go.

Who should act on this, and who can safely ignore it?

Not everyone running Adobe Commerce needs to do anything. Be honest about which group you are in.

You should act if several of these are true:

• You run two or more markets or storefronts and each release or fix takes noticeably longer than it did two years ago.
• Upgrades are being postponed because the custom extension set is fragile or poorly understood.
• Your total cost of ownership, including hosting, licensing, agency retainers and developer time, is being questioned by finance.
• Merchandisers or marketers regularly wait on developers for changes that feel like they should be configuration.
• Your team is small and a large share of its time goes to keeping the platform running rather than improving the shop.

You can mostly ignore it if your stack is current, releases are routine, your extension footprint is small and the people who run the shop day to day are productive in it. A single headline from another retailer is not a reason to open a seven-figure project. If the platform is not the bottleneck, replatforming just moves you to a different set of bottlenecks, plus a year of disruption.

There is a third group worth naming: teams that are unsure. For them, the audit in the next section is the right first step, and it costs a fraction of any migration.

How do we audit our own platform before reacting?

An audit does not need a consultancy. A product owner, a lead developer and someone from finance can do a first pass in a few weeks. Work through these steps in order.

1. List what you pay for. Licence or subscription, hosting, extensions with renewal fees, agency retainers, and the developer hours spent on maintenance versus new work. Use real invoices and timesheets, not estimates.
2. Map your customizations. For each custom module or heavily modified extension, note what it does, who understands it, and whether the vendor's current release makes it unnecessary.
3. Check your upgrade position. How far behind the current supported release are you, and what is blocking the gap from closing? Confirm supported versions and end-of-support dates in Adobe's own documentation rather than relying on memory.
4. Trace the integrations. ERP, order management, PIM, payments, tax, search, email and analytics. Note which are point-to-point and which go through middleware. The Technology Org comparison of ERP systems for Magento and Adobe Commerce brands is a reasonable reminder that the system behind the storefront often matters as much as the storefront.
5. Time a typical change. Pick three recent merchandising or content changes and measure the time from request to live. If the answer is days for something that should take an hour, find out where the time goes.
6. Write down the outcome you want. Lower cost, faster releases, easier merchandising, new markets. A replatform without a stated outcome is a hope, not a plan.

At the end you will have one of two results. Either the pain points are platform-shaped, meaning they would go away on a different platform, or they are process-shaped, meaning they would travel with you. Plenty of teams discover that most of the friction is old upgrade debt and unclear ownership, and that fixing those is cheaper than leaving.

What should a migration plan look like if the audit says go?

If the audit does point to the platform, the structure matters more than the destination. Moving to Shopify is one possible answer; staying on Adobe Commerce and rebuilding more cleanly is another. Either way, the multi-market lesson from this story is to treat each market as its own delivery unit.

A sensible shape is a pilot market first, chosen because it is representative but not your largest. Run it live, measure it against the pre-agreed outcomes, fix what you learn, and only then schedule the next market. Teams that cut every market over on one date discover their biggest problems when they have the least room to fix them.

Here is a rollout checklist you can adapt:

The exit tests are the part teams skip. Write them before the build starts, because after the build nobody wants to be the person who says the pilot did not pass.

Where does an implementation partner help, and where can we do it ourselves?

A partner earns their fee where the risk is concentrated and the skill is scarce. Data migration, integration architecture, search and URL continuity, and performance engineering under load are the usual places. If you have never moved a multi-market catalogue before, someone who has done it several times will spot the failure modes early. A directory of Adobe Commerce implementation partners is a reasonable place to start if you want to compare who has done this kind of work.

You can, and should, keep several things yourself. Deciding what the shop should do for customers, setting the success measures, owning the content model, and deciding which markets go first are business decisions. A partner can advise on them but should not own them. If a vendor is making those calls for you, you are renting a strategy you will not be able to defend later.

When you do brief a partner, be specific about scope, markets, integrations and the exit tests above. A structured Adobe Commerce RFP template helps you cover those points and keeps vendor responses comparable. Ask each bidder who is accountable for redirects, for data reconciliation and for rollback. Vague answers there are the best early warning you will get.

How do we measure whether a platform decision worked?

Pick a small set of measures before anything changes, and capture the baseline while the old platform is still live. Otherwise you will be arguing from memory a year later.

Useful measures fall into four groups:

• Commercial: conversion rate, average order value and revenue per market, tracked against a comparable period.
• Experience: page speed and checkout completion on mobile, since those are where regressions hide.
• Operational: time from change request to live, number of developer hours per release, and incident count.
• Search: indexed pages, organic landing-page traffic and crawl errors, watched closely for several weeks after each market launches.

Compare like with like. A migration timed near a seasonal peak or a promotion will distort every number, so note those events when you record results. And decide up front what counts as failure. If conversion in the pilot market drops and stays down beyond the agreed window, the plan should say what happens next, not leave it to a meeting.

Direction is more useful than precision here. You are asking whether the shop is faster to change, cheaper to run and no worse for customers, not trying to prove a decimal point.

What should we not do in response to this news?

A few mistakes are common enough to name directly.

Don't treat a competitor's or peer's migration as a template for yours. You do not know their catalogue size, their team, their integrations or their reasons beyond what one report says. Copying a destination without copying the circumstances is how teams end up with the same problems on a new platform.

Don't start with vendor demos. Demos show the best path through a product, and they are designed to make the current pain look avoidable. Run your audit first so that you walk into demos with a list of real requirements and a clear idea of what you are trying to fix.

Don't migrate your mess. If a market has three overlapping pricing rules nobody can explain, a replatform is the moment to simplify them, not recreate them. Equally, don't let the migration become the excuse to add every wish-list item. Scope creep is what turns a planned phase into an overrun.

Don't skip the redirect and search work. It is unglamorous and it is where organic traffic is lost. And don't decommission the old stack on launch day; keep it recoverable until the new one has run through at least one full trading cycle.

Finally, don't assume staying is the safe choice. Staying on Adobe Commerce is a perfectly good decision when the audit supports it, but it should be an active decision, with the upgrade and customization debt addressed, not a default. If you are still weighing options, the platform comparison tools can help you frame the trade-offs against your own requirements.

The practical outcome of this story is modest. It does not change what Adobe Commerce can do, and it does not prove anything about your business. What it does is give you a good reason to spend a few weeks writing down what your platform costs you, what it does for you, and whether that trade still makes sense.

Sources

• Mi-3.com.au. — Report that Forever New completed its global e-commerce migration from Magento to Shopify across four markets.
• Technology Org — Comparison of ERP systems for Magento and Adobe Commerce brands, relevant to the integration layer around the storefront.