Magento Development: Adobe Commerce, Performance and Upgrades

Magento development is rarely about launching a simple shop. Businesses pick Magento (sold today as Adobe Commerce, next to the free Magento Open Source) when they have large catalogs, several storefronts, complex pricing, B2B buyers or deep ERP integrations. What they need is a store that stays fast under load and upgrades without drama, where the business can change what it sells without waiting on a developer for every adjustment.

A healthy Magento store runs on a lean set of well-built extensions, with a full page cache that actually gets hits. Indexers and cron run quietly, and security patches go in on schedule. You also need a realistic view of the total cost of ownership, and if Magento turns out to be more platform than you need, someone should say so plainly.

Adobe Commerce or Magento Open Source

The two 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, plus content staging with scheduled previews, customer segmentation, and Adobe’s cloud hosting and support options.

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

How we approach Magento development

We build new stores, write custom modules, improve checkout and conversion, and do theme work. We also connect Magento to ERP, PIM, payment, shipping and marketplace systems, move stores onto Magento from other platforms, and rescue stores that have become slow or unstable. Whatever the project, it goes through the same stages.

It starts with discovery, where our business analysts capture the catalog structure, pricing rules, store views, integrations and order flow before anything is configured. Planning then breaks the work into deliverables, so scope, cost and timeline share one picture. Features are built iteratively in priority order, and your feedback goes in at every demo.

Integrations get particular care, because that’s where stores usually break: ERP, stock and fulfillment connections are built with retries, logging and reconciliation. Our QA testers cover functional, checkout and load testing, and user acceptance with your team follows. Launch is a rehearsed deployment. Code compilation and static content generation happen in a build step rather than on the live server, and we check redirects, structured data and search settings so rankings survive the move.

Extensions: fewer, better, reviewed

A lot of Magento performance and upgrade problems trace back to extensions. Each one can bring plugins, observers, layout changes and database tables, and a store carrying dozens of them gets slow and fragile to upgrade. The rules we follow:

• Configuration and core features first, a well-maintained extension second, custom code third.
• Every third-party extension gets a code review before it’s installed. 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. Nobody edits vendor code.
• Code has to pass the Magento coding standard and static analysis in CI, and business logic gets unit and integration tests.

Performance that holds under load

A production Magento store is a system of several services: PHP-FPM, MySQL or MariaDB, Redis for cache and sessions, OpenSearch for catalog search, Varnish for full page caching, cron that has to run reliably, and often RabbitMQ for asynchronous work. Most speed problems come from how those pieces are configured and used. Common causes:

• One block marked uncacheable in layout XML is enough to keep the whole page out of the full page cache. Customer-specific content should load as private content instead.
• Indexers set to update on save, when they should run on schedule so admin edits and imports don’t stall the storefront.
• Cron failing silently. When it stops, indexes go stale and emails pile up, so we monitor cron like any other critical service.
• 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 from slow extension queries, quote and log tables that never get cleaned, and flat catalog tables, which Adobe no longer recommends.
• Payment widgets, address lookups and tracking scripts all loading on checkout, the page where slowness costs orders most directly. We measure each of them.

We profile before we tune, and we load test search, category pages and checkout before launch instead of finding the limits on a sale day.

Upgrades and security

Adobe publishes regular patch releases and security bulletins, and every release line has a published end-of-support date. A store that takes payments has to stay within support. We treat upgrades as routine maintenance, which in practice means:

• A staging environment that mirrors production, with anonymized data
• Composer-based upgrades, with every extension checked for compatibility first, since it’s usually an extension rather than core that blocks 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

For security, admin two-factor authentication stays on and the admin URL isn’t guessable. Where practical, admin access is restricted by IP. Checkout pages keep a strict Content Security Policy against card-skimming scripts, and 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. A realistic budget also covers:

• 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 fits when the complexity is in the business itself: large or highly configurable catalogs, several brands or countries run from one installation, B2B pricing and accounts, deep integrations, or a need to own the code and data completely. It’s the wrong choice for a small catalog with a simple checkout and no in-house technical team. A hosted platform costs less there and needs less attention, and for a modest self-hosted store, OpenCart can be enough. If most of your customers buy on their phones, consider a dedicated m-commerce app built on Magento’s APIs alongside the store.

How an engagement works

New builds and replatforming projects get a dedicated team: a business analyst, a designer for the storefront, Magento engineers and QA testers. Storefront work includes accessibility checks on navigation, product pages and checkout, because people who shop with a keyboard or a screen reader are customers too.

With an existing store, we start with a technical audit of extensions, performance, security and upgrade readiness, and follow it with a prioritized plan. Ongoing maintenance covers patches, upgrades and improvements, and regular written reports explain what changed and why. When a store changes platform or URL structure, redirects and search signals get the same care as the data. Our SEO services team can own that part of the launch.

Frequently asked questions

Is Magento still a good choice?

Yes, for complex catalogs, multi-store setups, B2B selling and heavy integration work. For a small, simple store it’s usually more platform than you need.

Should we move to Hyvä?

Often, yes, if front-end performance is a problem and your extensions are compatible or can be made so. It does mean rebuilding the theme, so we check compatibility first.

How often should a Magento store be upgraded?

Apply security patches as they come out, and keep the store on a supported release line. Small, regular upgrades cost far less than jumping several releases at once.

Can you take over a store built by another agency?

Yes. We audit the code, extensions, hosting and deployment process, stabilize whatever is risky, and then carry on with your roadmap.

Can Magento integrate with our ERP?

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

Send us your Magento version and the list of installed extensions if your store is stuck on an old release line or you’re no longer sure Magento is the right platform, and we’ll start the assessment from there.