Magento Development: Adobe Commerce, Performance and Upgrades

Magento development is rarely about launching a simple shop. Businesses choose Magento, now sold as Adobe Commerce alongside the free Magento Open Source, when they have large catalogs, several storefronts, complex pricing, B2B buyers or deep ERP integrations. The goal is a store that stays fast under load, upgrades without drama, and lets the business change what it sells without waiting on developers for every adjustment.

Good looks like a lean set of well-built extensions, a full page cache that actually gets hits, indexers and cron that run quietly, security patches applied on schedule, and an honest view of the total cost of ownership. It also looks like a straight answer when Magento is more platform than you need.

Adobe Commerce or Magento Open Source

Both editions share the same core. Magento Open Source is free and self-hosted. Adobe Commerce is licensed and adds features aimed at larger merchants: a B2B suite with company accounts, shared catalogs, quotes and requisition lists; content staging with scheduled previews; customer segmentation; and Adobe’s cloud hosting and support options.

If you need B2B workflows out of the box or want a vendor-backed support channel, Adobe Commerce can earn its license. If not, Open Source with carefully chosen extensions covers a great deal, and the license budget is often better spent on performance and integration work. Some merchants also consider Mage-OS, a community-maintained distribution built on Magento Open Source.

How we approach Magento development

Our work covers new store builds, custom modules, checkout and conversion improvements, theme work, integrations with ERP, PIM, payment, shipping and marketplace systems, replatforming onto Magento, and rescue of stores that have become slow or unstable. Each project runs through the same stages:

1. Discovery. Our business analysts capture catalog structure, pricing rules, store views, integrations and the order flow before anything is configured.
2. Planning. The work is broken down into deliverables, so scope, cost and timeline share one picture.
3. Build. Features ship iteratively in priority order, with your feedback folded in at every demo.
4. Integration. ERP, stock and fulfillment connections are built with retries, logging and reconciliation, because that is where stores usually break.
5. Testing and acceptance. Our QA testers cover functional, checkout and load testing, followed by user acceptance with your team.
6. Launch. A rehearsed deployment in which code compilation and static content generation happen in a build step rather than on the live server, with redirects, structured data and search settings checked so rankings survive the move.

Extensions: fewer, better, reviewed

Many Magento performance and upgrade problems trace back to extensions. Each one can add plugins, observers, layout changes and database tables, and a store carrying dozens of them becomes slow and fragile to upgrade. Our rules:

• Configuration and core features first, a well-maintained extension second, custom code third.
• Every third-party extension is code-reviewed before installation. Class preferences that replace core behavior, around plugins where a before or after plugin would do, and unindexed queries are red flags.
• Custom modules follow Magento’s conventions: service contracts, dependency injection, declarative schema and data patches, and no edits to vendor code.
• Code passes the Magento coding standard and static analysis in CI, with unit and integration tests for business logic.

Performance that holds under load

A production Magento store is a multi-service system: PHP-FPM, MySQL or MariaDB, Redis for cache and sessions, OpenSearch for catalog search, Varnish for full page caching, reliable cron, and often RabbitMQ for asynchronous work. Most speed problems come from how these pieces are configured and used:

• Full page cache misses. A single block marked uncacheable in layout XML makes the entire page uncacheable. Customer-specific content should load as private content instead.
• Indexers running on save. Indexers should run on schedule, so admin edits and imports do not stall the storefront.
• Silent cron failures. When cron stops, indexes go stale and emails queue up. We monitor it like any other critical service.
• Front-end weight. The default Luma theme carries a heavy RequireJS and Knockout stack. For many stores, Hyvä, a leaner theme built on Tailwind CSS and Alpine.js, is the biggest single front-end improvement available. A headless storefront over GraphQL is another route when you need a fully custom experience and can own its complexity.
• Database load. Slow extension queries, quote and log tables that are never cleaned, and flat catalog tables, which Adobe no longer recommends.
• Checkout drag. Payment widgets, address lookups and tracking scripts all load on the page that matters most. We measure each one, because a slow checkout loses orders that a fast catalog has already won.

We profile before we tune, and we load test search, category pages and checkout before launch rather than learning on a sale day.

Upgrades and security

Adobe publishes regular patch releases and security bulletins, and each release line has a published end-of-support date. For a store that takes payments, staying within support is not optional. We treat upgrades as routine maintenance:

• A staging environment that mirrors production, with anonymized data
• Composer-based upgrades, with every extension checked for compatibility first, since extensions rather than core are what usually block an upgrade
• PHP, database and search engine versions moved in step with platform requirements
• A full regression run across catalog, cart, checkout, payments and admin before release

On security, admin two-factor authentication stays on, the admin URL is not guessable, admin access is restricted by IP where practical, and checkout pages keep a strict Content Security Policy against card-skimming scripts. Adobe’s free Security Scan Tool watches the storefront between our reviews. Stores still on Magento 1, which reached end of life years ago, need a replatform rather than an upgrade: the data can be migrated, but themes and extensions have to be rebuilt.

Total cost of ownership, and when to choose something lighter

The Adobe Commerce license, if you choose it, is only part of the cost. Budget honestly for:

• Hosting sized for a multi-service stack, not a shared server
• Specialist developers, who are scarcer than general PHP developers
• Extension licenses and renewals
• Upgrades and security patches, every year the store runs
• Monitoring, backups and incident response

Magento is the right platform when complexity is the business: large or highly configurable catalogs, several brands or countries from one installation, B2B pricing and accounts, deep integrations, or a need to own the code and data completely. It is the wrong one for a small catalog with a simple checkout and no in-house technical team. There, a hosted platform costs less and demands less attention, and for a modest self-hosted store, OpenCart can be enough. If most of your customers buy on their phones, a dedicated m-commerce app built on Magento’s APIs is worth considering alongside the store.

How an engagement works

New builds and replatforming projects run with a dedicated team: a business analyst, a designer for storefront work, Magento engineers and QA testers. Storefront work includes accessibility checks on navigation, product pages and checkout, because keyboard and screen reader users buy too.

For existing stores, we start with a technical audit of extensions, performance, security and upgrade readiness, followed by a prioritized plan. Ongoing maintenance covers patches, upgrades and improvements, with regular written reports so you always know what changed and why. When a store changes platform or URL structure, redirects and search signals get the same care as the data, and our SEO services can own that part of the launch.

Frequently asked questions

Is Magento still a good choice?

For complex catalogs, multi-store setups, B2B selling and heavy integration, yes. For small, simple stores, it is usually more platform than you need.

Should we move to Hyvä?

If front-end performance is a problem and your extensions are compatible or can be made so, it is often worth it. It does mean rebuilding the theme, so we assess compatibility first.

How often should a Magento store be upgraded?

Apply security patches as they are released, and keep the store on a supported release line. Small, regular upgrades cost far less than a jump across several releases.

Can you take over a store built by another agency?

Yes. We start with an audit of the code, extensions, hosting and deployment process, stabilize what is risky, and then continue with your roadmap.

Can Magento integrate with our ERP?

Yes, through its REST and GraphQL APIs and message queues. We design integrations with retries, logging and reconciliation, so stock and order data stay consistent.

If you are planning a Magento build, stuck on an upgrade, or wondering whether Magento is still the right platform for you, tell us about your store. We will give you a clear assessment and a sensible next step.