Magento 2 – what it is and what it is for

Magento 2 is an e‑commerce platform for building a store around a specific company's processes. It handles sales mechanics, the product catalogue, customers, pricing, promotions, orders, content and communication with outside systems.

The software on its own is a starting point. A working store only exists once the catalogue, the purchase journey, integrations, the front end, infrastructure and the rules for ongoing maintenance have all been designed.

Magento can be responsible for:

• presenting the offer and taking the customer through checkout,
• pricing, promotions, cart and order logic,
• customer accounts and permissions,
• data exchange with ERP, PIM, WMS, CRM and outside services.

A standard install already carries what selling needs: products, categories, pricing, customers, cart, orders, promotions and content can all be managed out of the box.

The company still has to decide how those mechanics work inside its own business model. Pricing may depend on a customer group. Availability may come from several warehouses. Products may be described in a PIM, and orders passed on to an ERP or a WMS.

Only the sum of those decisions produces a system that is safe to launch.

A monthly SaaS subscription and the cost of a Magento store describe different models of responsibility. A SaaS platform ships a finished product with a defined scope of change. Magento hands over more control of the system, at the cost of designing, building and maintaining its architecture.

Two things are not part of the Open Source standard and should not be counted into it: the B2B extension with company accounts and individual catalogues is part of Adobe Commerce, and some of the Adobe marketing tooling and services works only in the commercial version. The scope of both lines is compared further down this article.

Magento's architecture lets you change the catalogue, pricing, promotions, checkout, customer accounts and communication with outside systems. The scope of what can change is wider than in many closed platforms.

But every change becomes part of the store. It has to be tested, documented, secured, maintained and accounted for at every future update.

“Can this be built?” is usually the wrong question — it rarely tells you much. The decision should come from what the process is worth, the cost of the alternative, and what it does to maintenance afterwards.

A mature Magento project shows in how many deliberate decisions were made — not in how many custom features it has.

Two stores on the same version of Magento can need completely different amounts of work.

One may run on standard mechanics, up-to-date modules and documented integrations. The other may carry modifications built by several teams over the years, dependencies on unsupported libraries, and synchronisations nobody is watching.

The cost of the next feature then depends on the quality of the foundation. A simple change can require cleaning up code first, or reconstructing knowledge of how data actually flows.

Magento can usually handle the process a business needs. The cost of building on it more often comes from how that process was implemented before.

B2C

A store selling directly to an individual customer: an open catalogue, one price visible to everyone and a standard purchase path.

B2B

Selling to companies, with processes such as individual prices, catalogues, company accounts and business integrations. It needs user roles, limits and order approvals.a B2B build on Magento 2

D2C

Selling run directly by a manufacturer or a brand to the end customer, alongside or instead of the distribution channel.a D2C build on Magento 2

Magento gives a company more freedom to design its own system, at the cost of a budget for analysis, development, hosting, updates and maintenance.

A SaaS platform can be the more sensible choice when the catalogue is simple, checkout is standard, integrations are few and the priority is getting selling online quickly. The same goes for organisations that have nobody currently responsible for growing the e‑commerce product.

High revenue, a catalogue running into the thousands, a dated storefront, or expansion planned for someday do not, on their own, justify choosing Magento.

The most expensive project is often the one where basic business decisions only reach the development team once the build is already underway.

Magento 2

The name in common use for the current generation of Magento technology. It is not the name of a product you buy — both lines below are Magento 2.

Magento Open Source

The open-source version of the platform, whose code can be developed and adapted to a project's own needs. No licence fee.

Adobe Commerce

Adobe's commercial platform, developed in the same technology ecosystem and equipped with additional capabilities meant for larger uses. It is not a synonym for Magento Open Source: Adobe publishes separate release information for each line.

Magento Open Source ships open code and the core e‑commerce mechanics. Adobe Commerce builds on the same foundation with commercial features and Adobe's own services. It's worth checking the current scope of each product before deciding, since the offering and platform versions keep changing (Adobe's documentation (opens in a new tab)). The decision shouldn't stop at comparing licence prices — what matters is how much implementation and ongoing maintenance of the needed processes will cost under each option.

The edition with no standard licence fee can turn out more expensive if the company has to build and maintain extensive processes of its own for years. Adobe Commerce can be hard to justify if most of what it offers goes unused.

ERP

Prices, stock, orders and documents. Most often the ERP is the source of truth and the store is the recipient.

PIM

Product data and digital assets for every sales channel. Where the catalogue is scattered, the source is sometimes a platform of its own — Pimcore, for instance.

WMS

Picking, shipping and stock broken down by warehouse.

CRM

Customer data, contact history and the sales processes on the commercial team's side.

Marketplaces

Publishing the offer and receiving orders from selling platforms.

Payment systems

Gateways, instalments, deferred payments and settlement — through the operators' modules.

Logistics systems

Carriers, pick-up points, labels and shipment tracking.

Marketing automation

Events from customer behaviour, segments and outbound communication.

Every integration needs a scope of data, a direction of exchange, a frequency, a process owner and a way of handling errors. Without those it can be neither quoted honestly nor maintained.

Software

Magento Open Source has no licence fee. Adobe Commerce is a commercial product with an annual fee Adobe sets case by case.

The build

Analysis, UX/UI design, configuring the platform, and developing whatever the standard does not cover. The largest item in most projects.

Front end

Designing and building the layer the customer sees. It can be built on Hyvä, which shortens the work and improves performance against the default theme.

Integrations

Connections to ERP, PIM, WMS, CRM, payments and logistics. Quoted separately, because each depends on the other side's API.

Migration

Where the project replaces an existing store: moving the catalogue, the accounts and the order history, and protecting visibility in search.

Hosting

Magento needs infrastructure prepared for it — it does not run sensibly on shared hosting.

Maintenance and growth

Upgrades, security patches, monitoring and further development after launch.

The scope and the terms of both paths are set out under Magento 2 services and Shopify services.

Aurora Creation runs a working demo of Magento Open Source with sample data. You can test both the storefront and the admin panel and check the platform's basic features yourself.

The Magento admin panel can manage products, pricing, customers, orders and content. That doesn't mean all of that data should originate in the store.

In a typical architecture, an ERP might own pricing and commercial documents, a PIM product information, a WMS warehouse fulfilment, and a CRM the sales team's own work. Magento draws on the data it needs during a purchase and hands the order on for fulfilment.

The exact split depends on a company's own processes. If price can be edited in both the ERP and Magento, one of them has to be the source of truth. If stock comes from several warehouses, a reservation rule is needed. If product data changes in both a PIM and the store's own panel, the direction of sync has to be decided.

An integration is an agreement about who owns which data.

1. 01

   Who owns the data?

   For products, pricing, stock, customers, orders and fulfilment status, a source system has to be named for each. Skipping this decision is how several versions of the same information end up existing at once.

2. 02

   Which processes actually set the company apart?

   Some processes are a genuine source of advantage. Others only exist because of limits in older software. A new platform doesn't have to reproduce every operation that came before it — automating a process nobody needs just makes work that adds no value happen faster.

3. 03

   What actually needs custom code?

   If a standard mechanism or a proven module already covers most of the requirement, weigh the cost of the missing scope against the years-long cost of maintaining a custom build. A module shouldn't be chosen on price alone either — quality, updates, compatibility and its effect on the rest of the system all matter.

4. 04

   How will changes be tested and shipped?

   A project needs a test environment, a defined release process, a scope for QA, and a way of responding to bugs. Testing done once, before the first launch, does nothing to protect every update and feature that follows.

5. 05

   Who owns the store after launch?

   The company needs to know who handles monitoring, infrastructure, backups, security updates, bugs and further growth. Putting that off only lets the risk of every following change build up.

E‑commerce size can be described by revenue, traffic, number of products, orders, markets, integrations or employees. None of those on its own settles the choice of platform.

Extra flexibility earns its cost when the processes it serves are a lasting feature of the business model, not a phase — and will keep being developed for years.

Magento is built for companies whose sales processes have outgrown what simpler systems can hold.

Frustration with the current store is a reason to analyse it — it isn't, on its own, a reason to choose Magento.

The root of a problem can be the technology, how it was implemented, the quality of the data, the integration architecture, or how work is organised inside the company. A migration solves the limits of a platform. It doesn't replace the decisions about pricing, logistics, product data and who on the team owns what.

It can create the conditions to put those areas in order — provided they're accounted for in the analysis and the architecture of the new solution.