Not long ago, if a merchant wanted to, e.g., “for customers to log in with Google”, that sentence would have turned into a ticket and a search through extension listings, followed by a purchase based on screenshots and an afternoon of developer time spent on Composer and configuration. With Ari (the first agent for Magento), the answer comes back in the same chat conversation, explaining the extension, showing its listing, and installing it on a copy of your store right now so you can see it working.

Introducing – Ari extension marketplace, now open to every store connected to Ari.

Ari is the AI agent for Magento built by scandiweb. Merchants connect their store and ask for changes in chat, Ari builds each change on a copy of the store and tests it in a real browser, and a person releases it. A large share of those requests turn out to be “add feature X,” and very often a well-maintained extension for X already exists. The marketplace puts that extension in front of the merchant at the moment they ask for it, and Ari takes care of the install and the setup.

What is the Ari extension marketplace?

The Ari extension marketplace is a catalog of ready-made Magento extensions that Ari installs and configures for you, with a one-click trial on a preview copy of your store before you buy anything.

The first listings come from Amasty, MagePal, Magefan, Mageplaza, WeltPixel, and Yireo. Together they cover the jobs most stores look for early on, including SMTP email delivery, Google Tag Manager, WebP images, social login, one-step checkout, improved layered navigation, and a store blog. Each listing shows what every version of the extension includes and what it costs, and many of these offer a free version.

Magefan, a Magento extension vendor with more than a decade of modules behind it, is among the first partners on the marketplace.

Ari can also install Magento extensions that are not listed yet. You ask for one in the chat, and Ari installs it on the copy of your store the same way. Ari works with more than 1,000 Magento extensions, custom modules included, and new marketplace listings are added every day.

How installing an extension with Ari works

Starting from the marketplace

1. You browse the catalog, open a listing to compare what each version of the extension includes, and click Try out.
2. Before anything happens, Ari explains the trial in four short steps.
3. Ari installs the free version, and any paid version is bought from the provider.
4. The install happens in a new conversation that takes a few minutes, and you can keep chatting there while Ari works.
5. Ari then shows you around, with buttons that open the extension’s settings and pages. Your live store does not change until you release that conversation like any other change.

Starting from the chat

Most merchants will meet the marketplace this way – by asking for a specific feature in plain language, for example, “I want customers to log in with Google.” Ari replies that an extension already does this, links to its listing, and offers to either install the extension or build the feature custom. If you pick the extension, the install follows the same steps as above.

Custom code is the better answer for some requests, but an extension with years of maintenance behind it is often cheaper to own over the life of the store, and Ari offers both at the moment you are deciding.

What Ari does during install and setup

Ari installs the extension through Composer after checking it against your theme and the modules your store already has. It tests your store before showing you the result, and a progress card in the chat shows the work as it happens, including the files changed and the commands executed.

When the install is done, Ari explains what already works on your store and points you to the feature worth turning on first. It walks you through configuration using the vendor’s own documentation, and when a setting needs your input, Ari opens the right admin page directly from the chat.

Every change goes in as a migration or data patch inside a pull request, and Ari never writes directly to your database. That keeps the work reviewable like any other code change, and nothing reaches your live store until a person releases it.

Trying an extension before you buy it

The trial is the part we expect merchants to use most. A product page full of screenshots tells you very little about how an extension will behave on your own theme with your own catalog. With Ari, you see the free version working on a copy of your store within minutes.

The trial stays on the preview copy, and you can keep working in your other conversations while Ari installs it. If the extension turns out not to fit, you simply do not release it, and your live store stays exactly as it was.

Some extensions have no free version, such as Mageplaza One Step Checkout and Improved Layered Navigation. For those, Ari looks at what the extension does and how it connects to Magento, then checks it against your store’s backend, so you know whether it fits before you buy the license.

Paid extensions and licenses

Ari installs the free version, and you buy a paid version from the vendor, at the vendor’s price and on the vendor’s terms. Where the vendor supports it, you connect your account with them inside Ari. Ari then sees which extensions you already own and installs them for you, so you never have to handle composer credentials yourself. WeltPixel accounts can be connected today, with more providers on the way.

Where account connection is not available yet, Ari sends you to the vendor’s purchase page and installs the extension with the license you get there.

Who supports what

The vendor keeps supporting its extension the way it does today, which covers bugs in the extension and license questions. Ari and the Ari team look after the installation and the configuration, along with any conflicts with the rest of your store and anything on the Magento side. Merchants on the Ari + human plan also have Ari engineers in their chat.

What the Ari marketplace offers extension providers

When a merchant asks for something your extension does, Ari suggests it in the chat, and the merchant can see it working on their own store a few minutes later:

• Listing is free, with no fee and no commission.
• Merchants buy from you at your price and on your terms. Purchase links open from Ari, so you see the referral on your side.
• You choose which of your extensions are listed and which are available for trial.
• When several extensions match a request, Ari suggests them and the merchant decides (early partners get the recommendation spot in their category).
• If you provide an MCP server or skills, for example, AI tools for form building or data migration, Ari uses them directly when working on a merchant’s store.
• Bundles and revenue-share arrangements, such as all of your extensions for a fixed monthly fee, can be agreed during onboarding.
• New partners are announced to Ari merchants and in the Ari newsletter, social media, and featured on withari.ai.

Onboarding starts with an export of your extension information, sent together with your logo and trial installation access. A technical call with the Ari team then confirms the details. After that, we list your extensions and test the install together on a demo store before announcing the partnership. Providers can apply on the Ari partners page.

What comes next for Ari

Ari is THE place where Magento work gets requested and done, and the marketplace is just one part of it. Ari also works as an MCP connector inside ChatGPT and Claude, so the same agent is available from the AI assistants many teams already use.

On October 28 at 3 PM GMT, Ari creator, Alfreds Genkins, and co-founder, Glebs Vrevsky, will show Ari building a change live in a free webinar and answer questions from merchants, developers, agencies, and extension providers.

Frequently asked questions

Is the Ari extension marketplace free to use?

Browsing the marketplace and trying extensions on your preview store are part of Ari, and Ari plans start from €99 per month. Each extension is priced by its vendor, and many of the launch listings are free.

Does trying an extension change my live store?

No. The trial installs the extension on a preview copy of your store only. Your live store changes only when a person on your side releases the work, and the vendor’s code reaches your server only after you buy the license.

Can Ari install Magento extensions I already own?

Yes. When you connect your account with a supported vendor inside Ari, Ari sees the extensions you own and installs them without you handling Composer credentials. WeltPixel supports this today, and more vendors are being added.

What happens if no extension does what I need?

Ari offers to build the feature custom. It builds the change on a copy of your store, tests it in a real browser, and hands it back for a person to review and release.

How do Magento extension providers join the marketplace?

Providers apply on the Ari partners page and send an export of their extension information, their logo, and trial installation access. Listing is free, and merchants buy licenses directly from the provider.

Has a feature request been sitting in your backlog for months? Connect your store to Ari and ask for it in chat. If an extension already does the job, Ari will put it on a preview copy of your store so you can see it working before you buy.

The post Introducing: Ari Extension Marketplace for Magento appeared first on scandiweb.

On October 6, we introduced Expedio and showed Magento running 2x faster on a real merchant’s store. We’re happy to announce Expedio is now open-source. The core is now free for any Magento 2 store, and you can install it today. To see where it fits next to other modules, read our comparison of Magento speed optimization extensions.

This article covers what Expedio does, what we measured, what you get for free, and the ways to get it on your store, including letting scandiweb’s Ari, the first Agent for Magento, set it up for you.

Why speed is a reason merchants leave Magento

Shopify has made speed a central part of its pitch to Magento merchants. For an established store, leaving is a big project, given that integrations with warehouses, payment providers, customer accounts, and everything else has to be rebuilt, and features developed over years may need to be built again.

We created Expedio to give those merchants another option – keep the store you have and make it faster.

What Expedio does

Every Magento page is built on the server before a shopper sees anything. Modern themes such as Hyvä have made the browser side fast. The server side is where Magento still loses time, and it gets worse on busy days, when more shoppers mean more pages to build at once.

Expedio works on that server side, underneath your theme. It changes how Magento builds each page, using Liquid, the open-source template language Shopify’s themes are built on. Templates keep the same markup, so your design, admin, catalog and data stay as they are.

You don’t have to switch everything at once. You move your store onto Expedio one page type at a time, and every page you haven’t moved yet keeps running on Magento as before.

Expedio supports Magento Open Source, Adobe Commerce, and Adobe Commerce Cloud, and works with any Magento hosting. It doesn’t support Magento 1.

What’s in the free release

Expedio Open Source is free for anyone running Magento 2. You register, download it, and set it up on your own store. It includes

• The Expedio core
• Documentation and step-by-step setup guides
• Migration skills for moving your pages over

Your team handles the install, adapts your theme, tests on staging, and launches. The free release comes without committed support. If you want version updates, compatibility fixes, and product support, choose the Expedio Supported package. Get the free core here.

The easiest way to set it up? Ask Ari

Ari, the first agent for Magento, can now install Expedio for you. You don’t need a developer to start, and nothing changes on your live store until your team approves it. Connect your store to Ari and ask it to set up Expedio through chat. See how Ari installs Expedio.

Get Expedio for your store

Ready to make your Magento store at least twice as fast? Get Expedio for your store! The core is free for any Magento merchant – install it yourself, let Ari set it up, or have scandiweb implement it across your whole store.

The post Expedio Is Now Open-Source: Make Your Magento Store 2x Faster appeared first on scandiweb.

We have loudly claimed that Magento is no longer slow. scandiweb made Magento 2x+ faster. Today, October 6, we’re introducing the solution to back it up: Expedio.

Update, October 12, 2026: Expedio is now open-source. The core is free for any Magento 2 store, and Ari, the first agent for Magento, can install it for you. Read the announcement →.

We decided to fix the part everyone else had given up on.

Antons Sapriko, Executive Chairman of scandiweb

Where Magento is slow

A page reaches a shopper in two steps. First, the server builds the page and starts sending it: that wait is the time to first byte. Our guide to reducing server response time explains what TTFB measures and how to bring it down. Then the shopper’s browser turns it into something they can see and use.

Modern Magento themes such as Hyvä have largely solved the second step. The first step is where Magento is still slow, and that’s the step Expedio takes on.

What Expedio does

Expedio speeds up Magento’s backend, the part that builds each page before a shopper sees it. It replaces the way the server builds the pages it serves, while the store, its design, and its data stay exactly as they are.

Hyvä pushed Magento’s frontend to the max, and Expedio is doing the same for its backend. A store can run both, and together they make the fastest Magento setup available today.

Expedio works with Magento 2, including Magento Open Source, Adobe Commerce, and Adobe Commerce Cloud, on Hyvä, Luma, and custom themes. It’s rolled out page type by page type, and checkout keeps running exactly as it does today, so payment and shipping integrations stay untouched.

What changes for your store

For your team, nothing changes. The admin, catalog, prices, checkout, orders, and storefront design all stay as they are. The store simply is 2x+ faster.

We measure your store’s key pages before we start, adapt Expedio to your store, and test it on a staging copy, so your live store stays as it is until you approve the switch.

Magento should be fast on its own, not because a cache happened to hold the page. Every page in milliseconds, for every visitor, every time.

Aleksandrs Mokans, Solutions Architect at scandiweb and the engineer behind Expedio

Results

We tested Expedio on one real merchant’s Magento store, with around 1,000 categories and 20,000 products. Two copies of the same store ran side by side on one server: one as it runs today, one on Expedio, with no full-page cache on either.

• 2x+ faster response time on every page type at peak traffic, up to 25.9x on the home page
• 6.4x faster median response time across the eight page types tested
• 3x more traffic on the same server
• 3.2x faster with all caches empty
• 655 → 30 database queries on a full category page.

One thing worth noting: the test ran on ReadyMage, scandiweb’s Magento hosting, where stock Magento already answers in 70 to 472 ms without a page cache. That’s faster than most Magento stores, so every improvement above comes on top of a strong baseline.

See it for yourself

Our live demo runs the same store twice, on the same data and hardware. Click anything on one side and the other follows, with the timings measured live – try the live demo!

Learn what it takes to get Expedio for your store! Expedio is available to all Magento merchants, and it works with any Magento hosting. The core is free and open-source. Get Expedio for your store today.

The post Meet Expedio: How We Made Magento 2x Faster appeared first on scandiweb.

Update: the solution is now live as Expedio. Its page has the benchmark from a real merchant’s store and a live demo.

Last week, we announced that Magento is no longer slow – we’ve made it 2x faster. 

scandiweb’s tech team made Magento 2x faster than it used to be, on the same store and with the same design, and now it runs faster than Shopify. On October 6, we’ll show it live.

The 2x-faster claim is easiest to believe when you see it on a store you actually know – so we’re choosing 10 Magento stores and applying it to them.

Nominate your store!

You can now nominate a Magento store you run or work on. We’ll choose 10 stores from the nominations and make them 2x faster, so the proof comes from real stores.

Why nominate a store

• It’s free – we’re doing this to show what it can do on real stores
• You see it on your own store, with your catalog, extensions, and customers
• Nothing will get rebuilt, so your team doesn’t have to plan a project around it
• You get your own before and after visualization of Magento performance.

If you’ve been thinking about leaving Magento for speed, this is a way to find out first. Many merchants look at Shopify because they’ve been told Magento can’t be fast. Seeing your own store run 2x faster might impact that decision.

After nominating a store, you also join the list to see the reveal firsthand on October 6. If your store is picked, we’ll get in touch with you directly.

Nominate your store here: scandiweb.com/solutions/magento/expedio

The post Nominate Your Magento store: We’re Making 10 of Them 2x Faster appeared first on scandiweb.

Ask anyone in eCommerce about Magento, and you get the answer you got ten years ago. Powerful and slow. Shopify is the fast one, and if speed is what you need, you leave.

We have spent a long time on that last part.

On a store a merchant runs today, with the same design and the same Magento behind it, we made it 2x faster. That store is now faster than Shopify. Nothing was rebuilt and nobody re-platformed.

We are not going to explain how here.

This industry has been promised a faster Magento before, and each time the promise arrived as an article first and a rebuild second. You would be right to question our claim as well.

But we are doing it the other way round. On October 6, we will run the test live, on a real store, so you can see it for yourself.

Update: the solution is out. It’s called Expedio, and its page has the benchmark and a live demo.

The post We Made Magento 2x Faster. See It on October 6 appeared first on scandiweb.

Thanks all. We greatly appreciate the proactive response.

On Saturday, September 5, 2026, security firm Sansec disclosed StyleSmuggler, an unpatched vulnerability affecting every current version of Magento Open Source and Adobe Commerce, including the latest 2.4.9 release. That’s well over 100,000 stores worldwide. It allowed an unauthenticated attacker, with no login and no user interaction, to run code on a store’s server, access its data, and install a persistent backdoor. For several days, no official Adobe fix existed. 

Update (September 8, 2026): Adobe has released an official fix for StyleSmuggler (CVE-2026-75650) in Security Bulletin APSB26-146, delivered as the VULN-39341 hotfix. We’re applying it across client stores now, along with the credential rotation Adobe requires alongside it (more on that below). Our guide to Adobe’s official fix for the StyleSmuggler vulnerability covers which versions it fits and how to apply it. Are you on an older Magento version? Get the patch for your version here: StyleSmuggler fix for older Magento versions (2.2.0 to 2.4.3).

Update (September 18, 2026): Adobe has extended the hotfix to Magento Open Source 2.4.4 and 2.4.5, with separate packages for specific patch releases. The official fix now starts at 2.4.4 on both editions. For 2.2.0 through 2.4.3-p3, use our backport.

This article is an account of how our team responded in the window before that patch when the vulnerability was under active attack, and what any Magento or Adobe Commerce merchant can take from it. For the PHP flaw that followed in October, see how we handled PHP2Shell.

Key takeaways

• StyleSmuggler (CVE-2026-75650) affected every current version of Magento Open Source and Adobe Commerce, including 2.4.9.
• Adobe’s official fix arrived on September 7, 2026 in Security Bulletin APSB26-146, delivered as the VULN-39341 hotfix.
• Patching is not enough on its own. Adobe requires rotating the encryption key and every credential it protects, at the source.
• Being fully patched before September 5 was no protection. The first confirmed victim ran 2.4.6 with Adobe’s July and August updates installed.

What happened

The disclosure coincided with an active, coordinated wave of attacks, timed for the weekend, when many teams are offline and response times are slowest. Across the stores our team reviewed, we found active exploitation attempts. 

Being up to date was no protection. Sansec reproduced the full attack on clean installations of 2.4.7, 2.4.8, and 2.4.9, and the first confirmed victim was running 2.4.6 with Adobe’s July and August 2026 security updates already installed. With no official fix, we needed to come up with a rapid solution to protect stores that are being actively targeted.

Why our response was faster: protection at the infrastructure level

Because we run our own managed hosting, ReadyMage, we could move at the infrastructure level and protect every hosted store at once, before any official fix or guidance existed.

First, we deployed web application firewall (WAF) rules across our ReadyMage infrastructure to block the known attack path, before Adobe issued its own protective guidance. Every store on ReadyMage was shielded at the network layer while the rest of the ecosystem still waited.

Second, working in cooperation with Sansec, we began a mass rollout of Sansec Shield across client stores, applied and verified per project. We ran the rollout at scale, so protection reached the whole portfolio in a matter of hours.

As a result, ReadyMage customers were protected throughout the attack window.

Every scandiweb Magento and Adobe Commerce client heard from us on the day the flaw became public. Here’s how some of them responded:

What we did for each store

Alongside the infrastructure-level protection, our team mobilized outside working hours and worked through client stores individually. For each project, we did the following:

1. Review of server and application logs to establish whether the store had already been targeted
2. A full backup before any changes were made
3. Deployment and configuration of a protective shield tuned to this specific attack, applied per store, since this protection works at the project level
4. Direct verification – our team ran the exploit against the store before and after deploying the shield, confirming it could no longer be executed
5. Manual testing of the main shopping journeys to confirm the protective changes didn’t disrupt the store
6. Automated scanning at short intervals, with results reviewed manually by our team
7. A period of post-deployment monitoring to confirm stability and that the shield was actively blocking the attack.

For every store, our team executed the live exploit twice – once to see it work, and once after deployment to see it fail. The verification step is the one that’s easiest to skip under pressure and the one that matters most.

Which versions the official patch covers

Adobe’s hotfix (VULN-39341) covers 2.4.4 through 2.4.9 for Adobe Commerce, including B2B and Cloud. For Magento Open Source, it covers 2.4.4 through 2.4.9. There is no official fix for Magento Open Source below 2.4.4.

Our StyleSmuggler patch guide covers the full version matrix, how to apply the hotfix step by step, and the fix we rebuilt for the 41 older versions Adobe left out.

If you run Magento Open Source on 2.4.3-p3 or earlier, no official patch is coming, and doing nothing leaves you exposed. If that’s you, get a free security check or talk to our team about protection and an upgrade path.

Rotate your credentials after patching

Adobe is explicit that applying the hotfix does not, on its own, fully secure a store: credential rotation is required. Because the vulnerability could expose your store’s encryption key, and that key protects integration tokens, payment gateway credentials, and system automation tokens, you must rotate every credential it may have touched, at the source.

After patching, that means rotating admin passwords, REST/SOAP/GraphQL integration tokens, OAuth client secrets, payment gateway API credentials (at the provider), database credentials, SSH and deploy keys, and third-party extension API keys. Rotating the encryption key alone does not invalidate credentials that were already captured, so any that were exposed stay usable until rotated at their source.

Our team can handle the full rotation for you, patch applied, every credential rotated at the source, and integrations tested afterward to confirm nothing broke. Talk to our Magento team if you’d like us to take care of it.

What merchants should do now

If you run a store on Magento or Adobe Commerce:

• Apply Adobe’s official hotfix (VULN-39341) as a priority. Adobe Commerce and Magento Open Source is covered on 2.4.4 through 2.4.9. Versions below have no official fix and need targeted protection or an upgrade.
• After patching, you must rotate your encryption key and all associated credentials at the source: admin, integrations, payment gateways, database, and deploy keys. Adobe treats this as mandatory: the patch closes the hole, but rotation removes access an attacker may already have gained.
• This vulnerability compromised even fully patched stores, so check for signs of earlier exploitation. Known indicators include unexpected “Payment Transaction Failed Reminder” emails, unfamiliar background processes, new scheduled tasks, and unknown files in the report and temp folders.
• Remember that patching does not undo a break-in, so a compromise check still matters even after you patch.
• After any change, test your core shopping journeys, including cart and checkout, to confirm nothing broke.
• Keep monitoring. More issues like this are likely to surface, and staying protected is ongoing.

How to check whether your store was already compromised

Sansec’s research post lists further process- and path-level indicators, and these are still evolving. The absence of any single indicator is not proof that a store is clean. If your store was reachable between September 4 and the day you patched, a scan is worth running even if nothing on this list matches.

What happens next

Adobe’s official hotfix is now available, and we’re applying it across client stores, then reviewing, testing, and confirming each one. Automated scanning and manual review continue alongside it. We’ll update this post if the situation develops further.

Frequently asked questions

Is my Magento store affected by StyleSmuggler?

Every current version of Magento Open Source and Adobe Commerce was affected, including 2.4.9. Being fully patched before September 5, 2026 was no protection: the first confirmed victim ran 2.4.6 with Adobe’s July and August updates installed. If your store was online between September 4 and the day you applied Adobe’s hotfix, treat it as potentially exposed until it has been scanned.

Does Adobe’s patch cover my version?

Adobe Commerce, including B2B and Cloud, is covered on 2.4.4 through 2.4.9. Magento Open Source is covered on 2.4.4 through 2.4.9 only. There is no official fix for Magento Open Source 2.4.3 or earlier, or for Adobe Commerce below 2.4.4.

Is applying the hotfix enough on its own?

No. Adobe requires credential rotation alongside the patch. The vulnerability could expose your store’s encryption key, and that key protects integration tokens, payment gateway credentials, and automation tokens. The patch closes the vulnerability, but credentials captured beforehand stay usable until they are rotated at the source.

Which credentials need rotating after StyleSmuggler?

Admin panel passwords, REST, SOAP and GraphQL integration tokens, OAuth client secrets, payment gateway API credentials at the provider, database credentials, SSH and deploy keys, and third-party extension API keys. Rotating the Magento encryption key alone does not invalidate credentials that were already captured.

How do I check whether my store was already compromised?

Review server and application logs covering the disclosure window, and look for unexpected “Payment Transaction Failed Reminder” emails, unfamiliar background processes, new scheduled tasks, and unknown files in the report and temp folders. Patching does not remove an attacker who is already inside, so this check matters even after you patch.

What if I run Magento Open Source 2.4.3-p3 or earlier?

No official fix is coming for those versions, and doing nothing leaves the store exposed to an attack that is being actively exploited. Those stores need protection applied at the infrastructure or application level plus an upgrade path. scandiweb rebuilt Adobe’s fix for 41 older versions, from Magento 2.2.0 through 2.4.3-p3.

If you’re not sure whether your store was exposed before it was protected, or whether it’s fully patched now, we offer a free security check that needs no access to your store. Our Magento engineers review what’s visible externally and email you recommended next steps. Get a free security check or talk to our Magento team now!

For ongoing protection beyond this incident, ReadyMage, our managed Magento and Adobe Commerce hosting, includes malware protection, a firewall, and DDoS defense as standard.

The post Magento and Adobe Commerce Under Attack: scandiweb’s Rapid Response to StyleSmuggler appeared first on scandiweb.

Adobe Commerce as a Cloud Service (ACCS) is Adobe’s software-as-a-service edition of Adobe Commerce, generally available since June 2025. Adobe owns the application, hosts it, and updates it continuously, which means nobody on your team plans an upgrade again. In exchange, PHP is not supported inside the application, custom logic is rebuilt outside it, and the storefront is rebuilt on Edge Delivery Services.

Two questions usually follow. Are you being forced onto it, and what does it cost to go? No, and more than most merchants expect. Adobe has published no end-of-life date for the platform you are on, and for a heavily customized store, getting to ACCS is closer to a rebuild than a migration.

In this article, we’ll cover what ACCS is, where it fits among Adobe’s commerce editions, what Adobe’s contract actually entitles you to, what does not carry across from your current build, and the conditions that make it a good or bad fit. As an Adobe Gold Solutions Partner with 894+ Adobe certifications and hands-on time in an ACCS sandbox, every number below comes from a trusted partner and Adobe’s own published documentation.

What is Adobe Commerce as a Cloud Service?

Adobe Commerce as a Cloud Service is multi-tenant, and that is the detail deciding how it behaves once you are on it. Your store shares one application with every other ACCS customer, so Adobe sets the release schedule. You get 30 days to evaluate each update in a sandbox before it reaches production, and Adobe guarantees backward compatibility for customizations that follow its API-first extensibility model. What you no longer do is choose when to upgrade.

Here’s an important clarification, because the naming may cause confusion – “Adobe Commerce on Cloud” and “Adobe Commerce as a Cloud Service” are different products. The first is the platform-as-a-service edition that most Adobe Commerce merchants run today, where Adobe manages the infrastructure and your team owns the codebase. The second is the new SaaS edition, where Adobe owns both.

If your developers can deploy PHP into your store, you are on the PaaS edition. On ACCS they cannot, because the application is shared across every tenant and Adobe updates it on its own schedule. Teams who still call the platform Magento will also see this product discussed as Magento SaaS, which refers to the same thing under the older name.

Where it fits among Adobe’s four commerce editions

The difference is ownership of the application. On Adobe Commerce on Cloud, the PaaS edition, the codebase belongs to the merchant, who schedules upgrades, applies patches, and sizes infrastructure. On Adobe Commerce as a Cloud Service, the application belongs to Adobe, which patches and upgrades it continuously across all tenants. That removes the upgrade cycle and removes in-application PHP customization at the same time, which is why most migrations become a rebuild.

Adobe now sells four ways to run commerce, and merchants are frequently shown one of them without being told the other three exist.

For more information on Adobe’s platforms, see our Adobe Commerce vs Magento Open Source comparison. 

How the platform is built

Adobe Commerce as a Cloud Service is headless by default. The commerce engine is Adobe’s, reached over APIs, and the storefront is a separate build on Edge Delivery Services, no longer a theme inside the application. Customization happens out of process, through Adobe Developer App Builder for custom logic and API Mesh for combining data sources. Nothing a merchant writes deploys into the commerce application itself.

Inside that engine are four services, and they are a large part of what you are buying. Live Search handles AI-powered search, Product Recommendations generates suggestions from shopper behavior, Catalog Service serves product data to the storefront at speed, and Payment Services covers payment methods including interest-free installments. On the PaaS edition several of these are separate add-ons. Here, they are part of the platform. 

Around them are three architectural pieces that decide what you can build, and they are the source of nearly every practical consequence in the rest of this guide:

Edge Delivery Services is where your storefront is. It is Adobe’s delivery platform, built for page speed and for letting content teams publish changes without a developer in the loop.

Adobe Developer App Builder is where custom logic is. Instead of writing a PHP module that changes how the application behaves, you build a separate application that reacts to events the commerce engine emits and calls back into it over APIs. We wrote about App Builder in production before it became the only extensibility route on SaaS, and the summary is that it does out-of-process work well and is not an integration platform in disguise.

API Mesh connects your storefront to your data sources, combining calls to the commerce engine, your ERP, your PIM, and anything else into a single graph the frontend can query.

On Adobe Commerce B2B, we connected Macron’s storefront to SAP ERP and a Pimcore PIM, and the integration work produced a 132.5% improvement in conversion rate on direct traffic alongside 40% faster order creation. Integration built that way is part of a build that survives a migration to ACCS, because it already communicates over APIs and never depended on PHP inside the application.

The constraint that matters early is that out-of-process extensibility only reaches the points Adobe has chosen to expose. On the PaaS edition, a developer can hook almost any method in the application. On ACCS, webhooks and events come from a predefined list, and Adobe adds to that list release by release.

What Adobe’s contract entitles you to

Adobe’s product description for Adobe Commerce as a Cloud Service sets binding contractual ceilings. A subscription covers up to 250,000 SKUs, up to 100 catalog variations, and a catalog ingestion rate of 1,000 updates per minute and 100,000 per day. Storage is capped at 1 terabyte for the Edge Delivery Services storefront. Exceeding SKU count, catalog variations, or ingestion rate obliges the merchant to license additional capacity.

These numbers are published in Adobe’s legal product description, and they are the part of ACCS least discussed in public. They belong in the conversation before a migration is scoped.

The catalog ingestion ceiling of 1,000 updates per minute is generous for a stable catalog and tight for a retailer repricing thousands of lines at the start of a sale. And two power users on Product Visuals is a real constraint for a content team that expected asset management to come as standard and finds it rationed.

What these numbers do not tell you is how they behave against your specific catalog and release cadence, which is the difference between a limit and a problem. Run that comparison before the commercial conversation starts.

What does not carry over

Configuration does not migrate to Adobe Commerce as a Cloud Service. Adobe states that store settings, payment methods, shipping rules, and tax configuration are recreated by hand in the ACCS Admin, and the Bulk Data Migration Tool covers first-party data only. PHP extensions do not carry over, because the application does not accept them. Luma and Hyvä storefronts have no upgrade path, so every migration includes a storefront rebuild.

This section is the one most likely to change a timeline, so here is the detail behind each item:

Your configuration is retyped. Store settings, payment method configuration, shipping rules, and tax setup are recreated manually in the new admin. For a single-store merchant, this is tedious. For a merchant with dozens of store views across multiple countries, it is a workstream with its own testing plan.

Your extensions need individual verdicts. Because no PHP loads into the application, every extension in your current stack falls into one of four outcomes: it is now native functionality, a vendor has rebuilt it as an App Builder application, it needs a custom rebuild, or it has no path and the capability is dropped. The available catalog of App Builder extensions remains small, which means more of your stack lands in the third and fourth categories than most merchants expect.

Your storefront is rebuilt. Luma has no path onto ACCS, and neither does Hyvä. Merchants who invested recently in Hyvä storefronts are being asked to write that investment off, which for many is the single fact that settles the decision.

Your URL structure needs deliberate protection. ACCS has no URL rewrite tooling, and a full storefront rebuild means new URL structures, new hreflang handling, and new structured data. Organic traffic does not have to be lost in a replatform, but preserving it depends on redirect mapping that starts at the beginning of the project.

Where ACCS saves you money

The subscription genuinely does consolidate spending. Platform licensing, hosting, infrastructure sizing, and upgrade labor collapse into a single line, and for a team that has been absorbing upgrade projects every year, removing that cycle has real value. 

Where the business case needs care is the one-time investment to get there. Reaching ACCS from a customized store means rebuilding the storefront on Edge Delivery Services, re-architecting customization out of process into App Builder, re-making every integration, and recreating configuration by hand. For a complex build, that cost commonly exceeds several years of upgrade spending, so the strongest cases are built on what changes after go-live. Our breakdown of what an ACCS migration costs splits the effort across five workstreams and gives ranges by store profile.

That is also the more durable reason to move. ACCS suits merchants who want to stop spending engineering time on the platform itself so they can spend it on merchandising, content, and integrations instead. It is an argument about how your team operates.

What this means for Adobe Commerce on Cloud

Adobe has published no end-of-life date for Adobe Commerce on Cloud. Version 2.4.9 reached general availability in May 2026 with standard support running to 31 May 2029, so the PaaS edition continues to receive new releases. Individual versions do reach end of support on Adobe’s published lifecycle schedule, and from 1 June 2027 Adobe will stop maintaining Cloud environments on unsupported versions. The deadline attaches to versions, and the platform itself carries no end date.

The version schedule runs in three tiers. Standard support runs three years from general availability and includes quality fixes, security patches and on-call support. Extended support adds a further year of quality and security patches at no cost for 2.4.6 and 2.4.7. Security-only support, offered as a one-time exception for 2.4.4 through 2.4.6, provides isolated security fixes with no quality fixes at all.

Adobe states that from 1 June 2027 it “will no longer maintain Cloud environments running unsupported Commerce versions,” and that the action it may take includes “suspending traffic to the affected infrastructure. As a result, your eCommerce storefront will go offline.”

Merchants on 2.4.6 and 2.4.7 have until mid-2028 before enforcement reaches them, which is enough time to decide properly. Merchants still on 2.4.4 or 2.4.5 have until June 2027, and for them the pressing question is an upgrade, and a replatform can wait. 

How to choose between Adobe Commerce as a Cloud Service and Adobe Commerce on Cloud

The honest answer today is that Adobe Commerce as a Cloud Service fits standardized catalogs and integration-led customization, while Adobe Commerce on Cloud remains the right home for stores whose commercial logic lives inside the application. The decision is related to your customization. If it is written as PHP inside Adobe Commerce, moving it out of process is a rebuild, and a rebuild needs a reason beyond ending upgrades.

Choose Adobe Commerce as a Cloud Service if

• Your catalog stays under 250,000 SKUs and updates at a predictable rate
• Your customization is integration work that already communicates over APIs
• You are on a stock or lightly themed storefront you are ready to rebuild
• Ending the upgrade cycle matters more to you than keeping in-application PHP
• Your content team wants to publish page changes without a developer.

Choose Adobe Commerce on Cloud if

• Your checkout, pricing, or promotion logic is written as in-application PHP modules
• Your catalog exceeds 250,000 SKUs or changes faster than 1,000 updates per minute
• You need a customization that the out-of-the-box extension points do not cover
• Cost reduction is the main reason you are considering the change.

Frequently asked questions about Adobe Commerce as a Cloud Service

What is Adobe Commerce as a Cloud Service?

Adobe Commerce as a Cloud Service is Adobe’s multi-tenant SaaS edition of Adobe Commerce, generally available since June 2025. Adobe owns and hosts the application and upgrades it continuously, so merchants no longer plan version upgrades or apply patches. In exchange, PHP is not supported inside the application, customization happens out of process through App Builder, and the storefront is rebuilt on Edge Delivery Services.

What is the difference between Adobe Commerce SaaS and PaaS?

The difference is who owns the application. On Adobe Commerce on Cloud, the PaaS edition, the codebase is yours, and your team schedules upgrades, applies patches, and sizes infrastructure. On Adobe Commerce as a Cloud Service, the application is Adobe’s, and Adobe upgrades it for every tenant continuously. The trade-off is that in-application PHP customization is no longer available to you.

What are the SKU limits on Adobe Commerce as a Cloud Service?

Adobe’s product description entitles a subscription to up to 250,000 SKUs. It also caps catalog variations at 100 and catalog ingestion at 1,000 updates per minute and 100,000 per day. These are contractual ceilings, not soft guidance. Exceeding SKU count, catalog variations, or ingestion rate obliges you to license additional capacity.

Will my Magento extensions work on Adobe Commerce as a Cloud Service?

Not directly. Adobe Commerce as a Cloud Service does not support PHP inside the application, so extensions written as in-application PHP modules have no home there. Vendors are rebuilding selected extensions as App Builder applications, but the available catalog remains small. Every extension in your current stack needs an individual verdict of native, rebuildable, or dropped.

Is Adobe discontinuing Adobe Commerce on Cloud?

No. Adobe has published no end-of-life date for Adobe Commerce on Cloud. Version 2.4.9 reached general availability in May 2026 with standard support running to 31 May 2029. Individual versions do reach end of support on Adobe’s lifecycle schedule, and from 1 June 2027 Adobe will stop maintaining Cloud environments running unsupported versions, but that deadline attaches to versions, and the platform itself carries no end date.

What is Edge Delivery Services and why does Adobe Commerce as a Cloud Service require it?

Edge Delivery Services is Adobe’s storefront delivery platform, built for speed and for content editing without developer involvement. ACCS is headless, so the commerce engine serves data over APIs and the storefront is a separate build. Luma themes do not carry across, which makes the storefront rebuild a project in its own right inside any migration.

Can I keep my Hyvä storefront on Adobe Commerce as a Cloud Service?

No. Hyvä is a frontend for Adobe Commerce PaaS and has no upgrade path onto Adobe Commerce as a Cloud Service, whose storefront is built on Edge Delivery Services. Merchants who invested in Hyvä recently face writing that investment off. For many, that single fact makes staying on PaaS through the current support window the better commercial decision.

Does Adobe Commerce as a Cloud Service cost less than PaaS?

Not reliably, and cost reduction is the weakest reason to consider it. The subscription consolidates platform, hosting, and upgrade costs, but reaching Adobe Commerce as a Cloud Service from a customized Adobe Commerce build means rebuilding the storefront, re-architecting customization out of process, and re-plumbing integrations. For complex stores that one-time cost commonly exceeds several years of upgrade spend.

When does my Adobe Commerce version lose support?

Adobe publishes three tiers. For 2.4.6, standard support ended 11 August 2026, extended support ends 31 August 2027, and security-only support ends 31 May 2028. For 2.4.7, standard support ends 31 May 2027 and extended support ends 31 May 2028. From 1 June 2027 Adobe stops maintaining Cloud environments on unsupported versions and may suspend traffic to them.

Deciding whether Adobe Commerce as a Cloud Service fits

Adobe Commerce as a Cloud Service is a real product with a clear buyer, and that buyer is more specific than the marketing around it suggests. It suits merchants whose catalog stays inside Adobe’s published ceilings, whose customization is already in integrations outside the application, and who are ready to treat the storefront as something to rebuild rather than carry across.

For merchants whose pricing rules, checkout behavior or promotion logic are written as PHP modules, the honest position is that ACCS asks for a rebuild and does not yet offer enough in return to justify one on cost alone. The version schedule gives most of those merchants until 2028 to decide, which is time enough to answer the question properly.

The three numbers to check before anything else are your SKU count, your peak catalog update rate, and what your current storefront cost to build. Those decide the answer more often than any feature comparison does.

Working out whether Adobe Commerce as a Cloud Service fits your catalog, your customization, and your storefront is a conversation worth having with an experienced Adobe partner. Book a free consultation with an Adobe-certified architect, and we will get back to you within 48h.

The post Adobe Commerce as a Cloud Service: What It Is and Who It Fits appeared first on scandiweb.

Ask an AI assistant how Magento’s CMS works and you will get a decent answer. Getting it to make the change in your own store has been the tricky part, until now.

Assistants have read the Magento documentation. None of them has seen your store. They do not know your store views, your category tree, or which block renders on the storefront, so the advice stays general and you do the edit yourself.

scandiweb has open-sourced a module that solves this. The MCP server for Magento 2 gives Claude, ChatGPT, and any other compatible assistant live access to your store content, with Magento’s admin roles deciding what each one may do. It is on GitHub under the Open Software License 3.0.

Read more: Agentic Commerce Explained: How ChatGPT Is Changing Online Shopping

What the module does

It publishes your store as a set of tools an assistant can call. One endpoint, POST /mcp, uses the Model Context Protocol, the standard Claude, ChatGPT, Copilot, and Cursor already use to reach outside systems.

The repository contains two modules. Scandiweb_Mcp is the server: the endpoint, sign-in, permission checks, and a slot for adding tools of your own. Scandiweb_McpContent is optional and contains the six content tools below. Install the server on its own and an assistant can connect but has no tools to call.

What it can change in your store

The six tools cover what a marketing or merchandising team edits most. Each tool describes itself when the client connects, so the assistant works out how to call it without instructions from you.

Category and product images can be sent as base64, including data: URIs. An assistant that has just generated an image can put it on a category without a download and re-upload in between.

The repository includes a worked example: one request for a Black Friday landing page, researched and written, then added to the main navigation after “Sale”. Claude built the CMS block, built the page, and inserted the menu node.

Can an assistant just use the Magento REST API?

It can, and for simple reads that is fine. The problem is that REST was built for developers who already know the answers to questions an assistant cannot answer.

Content is the clearest case. A REST call that updates a CMS page reports success. On a Hyvä storefront, if that page has liveview switched on, it wrote to a field shoppers never see, and the response gives no indication. The cmspage tool flags the override, and hyvacms writes the layer that renders.

The same problem applies to store views. Here store_id is an array of assignments, where [0] means all of them, so the assistant is told which markets it is about to change. Through generic REST that scoping is unreliable, and an edit meant for one market becomes an edit to every market.

Snowdog menus are a simpler case: REST can read them but cannot write them. The snowdogmenu tool creates, moves, and deletes nodes, then clears the cache.

Each case comes down to the same thing. A typed tool includes the store’s context in the call. A raw endpoint makes the model infer it.

Magento’s admin roles decide what an assistant can do

Granting an assistant access happens on a screen your team has used for years. Every tool appears in the admin role tree at System → User Roles → Role Resources → MCP Server → MCP Tools. Tick the tools a role may use. A call from an assistant signed in as that role goes through only when the tick is there.

Content writes are checked twice, once against the tool and once against the native resource, so editing a page still needs Magento_Cms::save. Deletes that cascade need an explicit confirm=true.

Both sign-in methods produce an ordinary Magento admin token, expiring on the schedule already set at Stores → Configuration → Services → OAuth, which is four hours by default.

A role with cmspage and cmsblock ticked is therefore a safe thing to hand a content team. That role has no access to pricing or stock, and a tool it does not include never appears in the assistant’s tool list.

“The question merchants asked was never about the model. It was what happens the first time an assistant gets something wrong. Magento answered that years ago with admin roles, so we wired the tools into those rather than writing our own.”

Glebs Vrevsky, Co-Founder & Executive Board, scandiweb

How to install and connect the Magento MCP server

You need Magento 2.4.4 or later, PHP 8.1 to 8.4, and a public HTTPS address, because MCP clients do not accept plain HTTP.

Copy the Scandiweb folder into app/code/, enable both modules, then run setup:upgrade and cache:flush. To check the endpoint is alive, post to /mcp with no credentials. A 401 with a WWW-Authenticate header is the answer you want.

Then tick the tools onto a role and connect a client. Claude Code takes a bearer token. The Claude and ChatGPT apps use OAuth: add a custom connector, paste the /mcp URL, and leave client ID and secret blank, because dynamic registration fills them in.

Per-client steps and troubleshooting are in the server README.

Adding a tool of your own is one PHP class and one di.xml entry, and its permission appears in the role tree automatically. That is the route for anything particular to your business, such as an ERP lookup or a custom entity.

Read more: How to Build Your Own MCP Server

Agent for Magento vs the Magento MCP server: which do you need?

Use the MCP server for content, and Agent for Magento for code. This module edits what already exists in your store: pages, blocks, categories, products, and menus. It does not touch code, and you bring your own assistant to drive it.

Development work is a separate product. Agent for Magento has its own agent built in. You describe a change in plain language, by text or by voice, it asks the clarifying questions a developer would, then does the work on a staging environment. Nothing reaches production until you approve it. It covers version upgrades, extension installs, security patches, layout and theme changes, and ERP or CRM integrations, and it reads your real theme and installed modules instead of generic Magento patterns. Most tasks finish in under five minutes.

Some work stays with people. Replatforming, complex B2B logic, and architectural decisions are not agent jobs, and scandiweb engineers take those on when a task runs past what the agent can finish.

Frequently asked questions about the Magento MCP server

What is a Magento MCP server?

A module that publishes a Magento 2 store as tools an AI assistant can call over the Model Context Protocol. scandiweb’s version adds a /mcp endpoint and checks every call against Magento’s admin roles.

What does it cost?

Nothing. It is open source under the Open Software License 3.0, with no paid tier and no license key.

Which assistants can connect?

Any MCP-compatible client. Claude Code, Claude Desktop, claude.ai, and ChatGPT have documented steps. Claude Code signs in with a bearer token, the apps use OAuth.

Can an assistant damage the store?

It can reach whatever the role you connected it with can reach, and nothing beyond. Narrow the role and you narrow the blast radius. Cascading deletes need explicit confirmation. Use a dedicated least-privilege admin user rather than a super admin, keep token lifetimes short, and set Allowed IP Addresses when you know the client’s egress IP.

Does it run on Adobe Commerce?

Yes. It uses Magento core APIs and targets 2.4.4 and later, which covers Magento Open Source and Adobe Commerce alike.

Is Hyvä or Snowdog required?

No. Those two tools switch on only when the platform is installed. The CMS, category, and product tools run on Magento core.

Which tools would you actually let an assistant touch on your store? That is worth settling before you connect anything. The module is free, so try it on a staging store first, and if you want an expert opinion on how to scope it, let’s talk.

The post Magento MCP Server: Connect Claude or ChatGPT Directly to Your Store appeared first on scandiweb.

How many people in your company spend their day retyping documents into a system too risky or expensive to replace?

Even though most digital commerce work stops at the storefront or platform, many problems begin deeper inside the business, where orders, invoices, and shipment documents are still entered manually.

To help automate repetitive work inside legacy business systems, scandiweb has taken a strategic stake in LegacyBridge, an AI agent that clears the manual data entry. It reads an incoming document and enters the data in the system, leaving only the uncertain cases for a person to check.

The hidden operational problem behind modern commerce

Digital commerce budgets have gone almost entirely to what customers see – the catalog, checkout, app, personalization layer, etc. Behind all of it, the systems that actually commit an order or pay a supplier have usually been left exactly as they were. They still work, and the risk involved in changing them is far higher than on the customer-facing side.

So the work moves to people:

• Purchase orders arrive as email attachments and are typed into an ERP
• Delivery notes go into a warehouse system
• Supplier invoices are entered into finance
• Returns and warranty paperwork get typed into a back-office application that only a few people know how to operate.

When a purchase order takes two days to reach the ERP because the person who enters them was on vacation, that delay reaches the customer as a stock inaccuracy or a support ticket.

What LegacyBridge changes

LegacyBridge is an AI agent for business systems that have no practical integration path. It reads an incoming document and enters the information through the screens the business already uses, the way a trained employee would. Nothing is installed on the core system, and the old application code does not change; only the cases the agent is unsure about reach a person.

For companies working with us, this opens a new capability, a practical way to automate repetitive document-to-system work without replacing your core ERP or changing legacy code, scoped by the team that already knows your architecture.

Why scandiweb is expanding into the operational layer

For over two decades, scandiweb has taken on almost anything in our clients’ digital stack (storefronts, platforms, performance, data, integrations), most of it well below what customers see. That work still matters, and it is still most of what we do. But what’s changed is where the ceiling is.

On project after project, the limit on what a better storefront can deliver has turned out to be behind it. A checkout can be tuned to the millisecond and the customer still waits two days for confirmation, because the order has to be added to ERP by hand. Optimizing the one half of that sequence is only part of it, and many of our clients have reached it. It’s where a process stops being handled by software and starts being done by hand. 

Our scope is commerce as a whole now, including the operational systems that never appear on a storefront. We’re now able to work on another layer deeper.

Together with LegacyBridge, we are bringing AI automation into the hidden operational layers, letting us help a client’s business, and across more of it, than we could before.

How LegacyBridge works

Four things happen, and none of them require a change to the system being automated.

The document arrives

A purchase order, invoice, delivery note, or claim enters a queue by email, SFTP, or an API push. Each one becomes a single unit of work with its own record.

→ The agent reads it

Vision and language models pull out the fields that matter and return structured values, each with a confidence score attached (the confidence score is the part that makes the rest of this safe).

→ The agent enters the data

It signs in over your network, walks the menu path to the correct entry screen, and enters the data field by field. It reads what is actually on the screen, so a screen that has been changed or a menu that has been reordered does not break it the way older automation breaks.

→ Everything is logged

Each action is written to the audit trail as it happens, and the record cannot be changed later without leaving a trace.

Work the agent is confident about proceeds automatically. When a field cannot be read cleanly, a value falls below the threshold, or a screen does not match what was expected, the document is flagged for a person, and the agent continues with the next item in the queue. Human oversight of automated decisions, documented and demonstrable, is exactly what frameworks like the EU AI Act expect.

Three workflows worth looking at first

Purchase orders arriving by email or PDF

B2B customers send orders as attachments, and someone in customer service types them into the ERP. This is the highest-value candidate in most organizations because the delay directly affects a paying customer, and because order entry errors are expensive in both directions.

Automating it narrows the gap between a customer sending an order and that order being real in your system.

Shipment and delivery documents

Delivery notes, dispatch confirmations, and carrier paperwork get entered into a transport or warehouse system, often by a team working from a shared inbox.

The operational win is speed of information. Stock and shipment status become current, which is what makes accurate delivery promises possible on the storefront.

Supplier invoices

Accounts payable teams enter invoices into a finance system from PDFs that arrive in dozens of formats. There is high volume, and the cost of a late payment is usually high.

Confidence-based handling fits this well, because the exceptions that need a human are the ones finance already wants to look at.

Why you don’t need to replace the core system first

The instinct when confronted with an aging ERP is to plan its replacement. Sometimes that is right, and scandiweb has run enough enterprise platform decisions to say when it is. But often it is not the first move.

These systems have been running for decades, carry years of custom business logic that exists nowhere else in written form, and connect to operations in ways no current employee has fully mapped. Replacement programs are long and expensive even when they go well.

The alternative – you can leave the system exactly where it is and still remove most of the manual typing around it. If a replacement does eventually happen, the document processing you automated stays useful, because the queue, extraction, and business rules are independent of whichever system receives the data.

When a direct integration is still the better answer

If a clean API exists and the vendor supports it, build the integration. LegacyBridge is for the cases where the API does not exist, or it exists but is not licensed to you, or the vendor wants a six-figure sum and nine months to expose the one endpoint you need, or the system is so old that touching its integration layer is its own risk assessment.

How to tell whether a workflow qualifies

See if any of your recurring workflows meet these conditions:

1. It is a recurring document stream (the same kind of document, arriving continuously)
2. Teams type it in manually today, and it is not yet automated in any way
3. The volume and time spent are meaningful
4. No clean, practical API path exists (or one exists on paper and has been unavailable to you for years).

scandiweb has spent 20+ years on storefronts, platforms, data, and integrations. That work has a natural boundary, and the boundary has always been the point where a process stops being handled by software and starts being done by hand.

Our strategic acquisition of LegacyBridge means the same AI agent development discipline we apply to customer-facing work now reaches the operational processes feeding commerce, where the delays that reach your customers begin.

Identify one recurring, high-volume process your team still handles manually. Tell your account manager which one it is, or book a short feasibility review, and we will scope a focused two-week pilot on that workflow.

Frequently asked questions

Does anything get installed on our ERP?

No. The agent works through the same interface a person uses, signing in over your network. The application code of the core system does not change, and there is no module to deploy or maintain inside it.

How is this different from robotic process automation?

Traditional RPA records and replays click paths against fixed screen positions, which breaks whenever a screen changes. The agent reads the content of the screen and works out where it is, so ordinary changes to menus and layouts do not stop it. There is also nothing to install on desktops or agent virtual machines.

What happens when the agent is not sure?

The document is flagged for human review and the agent continues with the next one. Every uncertainty becomes an audit entry rather than a silent error, and you decide where the confidence threshold is set.

Do we need to replace our ERP first?

No, and that is the point. The approach exists precisely for systems that cannot be safely or affordably replaced right now.

What does this mean for clients already working with scandiweb?

It is a capability you can ask your existing team about. The people who know your order flow and integrations would scope the assessment, and the work runs under the same delivery and governance standards as everything else we do for you.

The post scandiweb Completes Strategic Acquisition of LegacyBridge appeared first on scandiweb.

Every business at a larger scale has an ERP, a CRM, an eCommerce system, accounting software, a warehouse system. And each one handles its core domain well. But something always falls between them, ending up in a spreadsheet, a manual process, a wishlist, someone’s email, very old software nobody wants to touch, or in a backlog item that never gets prioritized, you name it. 

OperaLayer is the layer that closes this gap.

Next, I’ll explain what OperaLayer, our operational layer, is, how it differs from iPaaS and a data warehouse, how it gets built without replacing anything you run, and how to tell whether it is the right move for your business.

The gap every business already has

Each of the core platforms already handles its own domain well – the ERP runs the books, the CRM holds the customers, the eCommerce platform runs the storefront, while the warehouse system tracks stock. The gap is the work that falls between them.

It is easy to recognize once you look for it. The same shape of problem shows up in every department:

• Month-end close takes days because someone reconciles numbers between the ERP and the data warehouse by hand
• The same customer has three different IDs across the CRM, the eCommerce platform, and support, and nobody owns the fix
• A process the team runs every Monday has been on the automation backlog for two years
• Regional pricing is in a spreadsheet that one person maintains, and nothing changes price when they are on holiday
• Buyers match supplier invoices to purchase orders by hand because every supplier sends a different PDF format
• The dashboard the board asked for requires data from five systems, so building it has been “next quarter” for three quarters in a row.

Why the gap is structural

The gap is not there because a system is broken, but because of how the systems are organized. The data already exists, spread across the platforms you have paid for. Same with processes, your team runs them every week. The systems work, each doing the job it was designed to do. What is missing is anything built to connect them around the specific thing your business needs right now.

That is why the usual fixes do not hold. Even a clean set of system integrations keeps the data flowing without deciding who owns the weekly process that runs on top of it. The structural gap does not shrink on its own, and it does not belong to any one vendor, which is exactly why it keeps ending up on someone’s plate instead of in a system.

What OperaLayer is

OperaLayer by scandiweb is an operational layer – a thin software layer that runs across the systems you already use, consolidates their data into one model, and hosts focused apps that close specific gaps between them. It connects to your ERP, CRM, eCommerce platform, and warehouse system, reads from them, and replaces none of them. 

Worth a quick clarification, because the word “layer” gets crowded. This is not an AI or API orchestration layer in the developer sense, which coordinates models or microservices. It is a business operations layer. It is also not a rip-and-replace platform, but adds the missing capability on top of what you run.

An operational layer has three main capabilities:

Visibility

Visibility is the operational view you cannot build today because the data behind it is spread across three systems with three different definitions. It is the single customer view that finally reconciles the same person across the CRM, the eCommerce platform, and support, or the executive dashboard, where every number is defined once instead of five slightly different ways. It is also the department-level drill-down nobody can produce right now, because the data it needs never lands in one place.

Prediction

Prediction is the forward-looking signal your team already produces by hand on a Friday afternoon, surfaced early enough to actually act on. That covers demand and inventory forecasts, churn and revenue risk, and the kind of margin or anomaly alert that stays quiet until something genuinely looks wrong, then routes itself to the person who can deal with it.

Automation

Automation takes the decision that repeats every week and currently needs a person just to run it, and runs it for them. Think reorder and replenishment drafts, cross-system matching and sync, or approval routing. People stay in the loop wherever judgment is needed, and step out of the parts that were only ever manual because no system owned them.

How an operational layer differs from iPaaS, a data warehouse, or another platform

These categories get confused often, and the difference is practical. An operational layer is where the operational app actually is, built on top of connected data, while the other tools each solve a narrower piece.

• iPaaS and middleware move data between systems and get System A talking to System B, but they do not give a planner a ranked queue to act on.
• A data warehouse or BI tool stores and reports on the data, tells you what happened, but it does not run the weekly decision or the cross-system workflow.
• Another platform replaces a system you already have, which means migration, retraining, and a new set of edge cases to manage.

An operational layer uses the middleware and the warehouse where they help, then adds the view, the prediction, or the automated decision on top, without replacing anything underneath.

How it gets built without replacing anything

The delivery model is what makes an operational layer not extend into a multi-year program. It is a single module, built on a short, fixed timeline.

We deliver a working prototype in week one, on real data and the real workflow, so your team can see the right thing being built before it is fully built. Next, iterate with the people who will use it. The production build connects to your existing systems with governance, access, and an audit trail from the start. The module is live in four weeks, with training and post-launch support included. Nothing gets migrated, and your team does not learn a new platform.

The first module sets up the foundation: the systems connected, the data model unified, the first views and the first prediction. Every module after that is faster and cheaper, because the foundation is already paid for. You add capabilities in the order your business actually needs them, not in the order a transformation roadmap dictates.

What OperaLayer looks like in practice

Case 1: Business Central handled the books, but not 50+ supplier brands

A Baltic sports and apparel retailer with more than €100 million in revenue ran its books in Microsoft Business Central. Business Central did not handle 50-plus supplier brands, seasonal commitments, and invoice variance flags, and none of that deserved a full ERP customization. The operational layer gave buyers live supplier purchasing intelligence, with €34 million of one season’s purchasing tracked across every brand and 52 invoice discrepancies caught before goods reached shelves.

Case 2: Magento handled the storefront, but not 50-state pricing

A US specialty retailer selling direct to consumers across 50 states ran its storefront on Magento 2. Magento was never going to handle state-by-state pricing logic with multiple margin types, and a spreadsheet was never going to scale to it. The operational layer took pricing live across all 50 states and recalculated eight margin types per state, eliminating the manual formulas at the source.

Case 3: Navision handled the orders, but not the 100 PDF invoice formats

A B2B electrical and industrial supplier with around 100 vendors ran orders through Microsoft Dynamics NAV. Navision did not handle 100 different PDF invoice formats and line-by-line purchase order matching. The operational layer reached an 87% auto-match rate and surfaced only the exceptions for a human to review, instead of two people matching invoices by hand every morning.

When an operational layer is the right move

Consider an operational layer if:

• Work keeps falling between your systems into spreadsheets, email, and manual routines
• You do not want to replace systems that otherwise do their job well
• You need a view, a prediction, or an automation that no single platform you own can produce
• You have already tried “another report” or “another platform” and the gap is still there
• You want to prove value on one real problem before committing to anything larger.

Frequently asked questions about the operational layer

What is an operational layer?

An operational layer is a thin software layer that runs across the systems a business already uses, unifies their data, and hosts focused apps that close specific gaps between them. It connects to systems like the ERP, CRM, eCommerce platform, and warehouse system, and replaces none of them. Its job is visibility, prediction, and automation that no single platform produces on its own.

How is an operational layer different from iPaaS or middleware?

iPaaS and middleware are the pipes that move data between systems. An operational layer uses those pipes, then adds the operational app on top: the unified view, the forecast, or the automated decision a team acts on. Middleware gets System A talking to System B. An operational layer turns that connected data into a workflow someone actually uses.

Does an operational layer replace my ERP or CRM?

No. An operational layer is additive. It reads from your existing systems and leaves them in place, so there is no migration and no retraining on a new platform. The ERP keeps running the books and the CRM keeps holding the customers. The layer only adds the capability that currently falls between them.

What is OperaLayer?

OperaLayer is scandiweb’s operational layer. It connects to the systems a business already runs, unifies their data, and hosts focused apps that close specific gaps, built on a roughly four-week rhythm per module without replacing any existing system. The supply-chain and pricing tools scandiweb has shipped are individual modules built on it.

How long does it take to build an operational layer?

A single module follows a short, fixed rhythm: a working prototype in week one and a live, production module in about four weeks, including training and handover. The first module also stands up the shared foundation. Every module after that is faster, because the systems are already connected and the data model already exists.

Is an operational layer only for large enterprises?

No. The gap it closes shows up at any size where a business runs several systems that do not talk to each other about a specific process. Because the work is delivered one focused module at a time rather than as a single large program, a mid-sized business can start with one gap and add more only when each one earns its place.

The gap does not close on its own

The systems you have already do their jobs. The work that falls between them does not belong to any of them, so it keeps costing time and margin until something is built to hold it. OperaLayer is that something: additive, fast to prove, and created around the specific gaps your business has.

We have spent twenty years building the layer between platforms. If the work falling between your systems is starting to add up, that is exactly the kind of gap we close. Let’s chat and, in four weeks, you will have one module running on your real data, closing one specific gap that currently costs your team time every week.

The post Introducing OperaLayer: Close the Gap Between Your Business Systems appeared first on scandiweb.