---
title: "Magento 2 / Mage-OS / Adobe Commerce"
description: "Enterprise commerce for complex catalogs, B2B, and multi-store, on Mage-OS and Adobe Commerce."
language: "en"
canonical: "https://zapolu.com/services/magento/"
---

# Magento 2 / Mage-OS / Adobe Commerce

Magento powers some of the largest e-commerce operations on the web,
and it has earned a reputation for operational complexity along the
way. Run well, it is still the most capable open platform for complex
catalogs and B2B. Run badly, it produces 12-second product pages and
hosting costs nobody can explain. Most of our Magento engagements
start with a shop in the second state.

We work with both live branches of the platform:

- **[Mage-OS](https://mage-os.org)**: the community-led fork that decouples
  the platform's future from Adobe's roadmap and releases faster. New
  open-source builds go here rather than to stock Magento Open Source;
  most of the community's release activity has moved to the fork.
- **[Adobe Commerce](https://business.adobe.com/products/magento/magento-commerce.html)**:
  the licensed cloud edition with the B2B suite, page builder, and
  enterprise SLAs.

The work is led by an architect holding **Adobe Certified Master –
Adobe Commerce Architect**, the highest certification Adobe issues
for Commerce, plus a Hyvä developer certification on the storefront
side. Both are verifiable on
[LinkedIn](https://www.linkedin.com/in/lubos-zapotocny-48bba0124/).

## When Magento is the right choice

- Complex catalogs with many product types, configurable options, and pricing rules
- B2B requirements: company accounts, quote workflows, tiered pricing, purchase approvals
- Multi-store and multi-brand setups under one admin
- An existing investment in Adobe Commerce extensions and integrations

If none of these apply, [Shopify](/services/shopify/) is usually the
cheaper answer, and we will say so on the first call.

## Problems we are asked to resolve

- Product pages that take three seconds although Varnish and Redis are
  "already configured"
- Checkout that fails under campaign load while the servers sit at 10%
  utilization
- Forty installed extensions, half abandoned by their vendors, two of
  them conflicting over the same observer
- Indexers and crons in a state where the storefront shows stock the
  warehouse doesn't have
- An upgrade postponed so long that every security patch has become a
  project of its own

## Problems we have fixed

From stores we've worked on over the years, anonymized:

- Customer registration failed over a weekend because one extension's
  table had exhausted all 4.29 billion auto-increment IDs while
  holding half a million rows. A BIGINT hotfix restored signups within
  the hour; a schema override made the fix survive upgrades.
- Cash-on-delivery orders began requiring card payment after an
  upgrade: the schema migration had rebuilt a table and shifted the
  row IDs a legacy module used as hardcoded constants. Found by
  comparing the raw tables across environments.
- Salable stock drifted below reality for months. A marketplace
  connector renamed order increments after placing inventory
  reservations, so MSI could never release them. Proven with
  anti-joins on the reservation metadata, fixed with a vendor patch
  and a cleanup cron.
- Addresses stopped matching in the ERP because Magento's CSV-injection
  guard silently prepends a space to any value starting with "+",
  which includes phone numbers. Traced into framework internals,
  fixed with a composer patch.
- Media uploads worked on staging and failed on production. A
  hypothesis-elimination pass pinned it to a single stale
  configuration row, and a self-healing data patch made sure it can't
  come back.

## What we do

- **Performance audits and storefront rebuilds.** Our default
  recommendation is [Hyvä](https://hyva.io): it replaces the legacy
  frontend stack entirely and typically brings Lighthouse scores into
  the 90s. PWA Studio or fully headless where the case calls for it.
- **Custom modules and [integrations](/services/integrations/)** for
  ERP, PIM, fulfillment, payments, and marketplaces, built idempotent
  and observable, because the integration layer is where Magento shops
  break most often.
- **Version upgrades**, including overdue Magento 1 to 2 migrations,
  Mage-OS migrations, and reducing the risk of major-version upgrades
  with a full extension audit before anything is touched.
- **Long-term operational support:** security patches, monitoring,
  cache tuning, and the on-call engineer for the day the database lock
  table fills up. It runs as a monthly retainer, with
  [DevOps & infrastructure](/services/devops/) underneath.

## How an engagement usually starts

For a live shop, the [performance audit](/services/performance-audit/)
is the natural entry: a fixed price, real measurements, and a
prioritized fix list your own team can execute. For a shop still
on Magento 1 or several major versions behind, we start with a
migration assessment instead: what carries over, what gets rewritten,
and what the cutover plan looks like. Either way, you know the scope
and the price in writing before anything is billed.