Choosing a Magento development company.

The standard buyer's framework for choosing a Magento agency is well-covered already. Our companion piece on top Magento ecommerce agencies walks through five archetypes (enterprise systems integrator, dedicated Magento partner, hybrid Magento + Shopify partner, Adobe Commerce specialist, freelancer collective) and seven buyer-side evaluation criteria (Adobe Solution Partner status, named ACE engineers, B2B module experience, headless capability, multi-store architecture, AWS hosting depth, performance track record on 10K-plus SKU catalogs). It's the right starting point if you are building the shortlist.

This piece is the next layer. Once the shortlist is set, the question shifts from "which archetype fits our revenue tier?" to "which of these three shortlisted companies will actually ship clean Magento 2 code?" That question is engineering, not marketing. And the engineering evaluation has its own playbook - one that most merchants do not know to run, because their procurement process is calibrated for buyer-side criteria rather than technical signals.

Five technical evaluation pillars structure this piece. Section 3 covers Magento 2 architecture knowledge, the load-bearing signal that filters genuine engineering competence in 30 seconds of conversation. Section 4 covers the Adobe Commerce versus Magento Open Source split, with technical detail on what each edition actually ships. Section 5 covers performance fundamentals with the specific evidence to demand - Varnish hit rate, Redis configuration, MySQL tuning, ElasticSearch health. Section 6 covers security cadence with CVE response time, regression discipline, and GitHub hygiene as the three measurable signals. Section 7 covers headless capability honestly - Hyva Themes versus PWA Studio versus "we don't do headless." Section 8 covers data migration discipline, which has the same shape whether the work is into Magento, between versions, or out to another platform. Section 9 frames the honest stay-or-migrate question. Section 10 catalogs the red flags in the engineering proposal that signal a development company will not deliver. Then six FAQ answers and the next-step CTA.

One framing note before the technical depth begins. Digital Heroes is a Premier Shopify Plus partner agency. We help merchants migrate from Magento to Shopify Plus. We do not actively build new Magento 2 stores in 2026 - the engineering complexity, the smaller pool of senior PHP talent, and the math on retainer engineering all point our delivery focus to Shopify Plus. The honest framing matters because it shapes what we can ship for you and what we cannot. The engineering evaluation rubric in this article, however, is universal. Use it whether the answer is stay-on-Magento with another agency, migrate to Shopify Plus with us, or rebuild the frontend on Hyva with a Magento specialist while you decide.

License and hosting. Adobe Commerce license fees start around $22,000 annually for entry-level GMV tiers and scale to $125,000-plus based on revenue. The license includes Adobe-managed cloud hosting (Adobe Commerce Cloud, built on AWS with Fastly CDN baked in), Adobe support SLAs, and the enterprise feature set below. Magento Open Source is free as in beer and as in speech - the full source code is on the Magento 2 GitHub repository, you self-host on AWS, MageMojo, Nexcess, or your own infrastructure, and you pay no license fee. Both editions ship the same core PHP codebase, the same Knockout.js admin interfaces, the same MySQL data model, the same EAV catalog, the same indexer architecture, the same PHP compatibility (8.2 minimum as of 2.4.8 in 2026, 8.3 supported, 8.4 in beta).

B2B module depth. Open Source ships B2B basics since 2.4.0 (2020) - company accounts, customer-segment-specific catalogs, requisition lists, NET payment terms. Adobe Commerce extends this with B2B advanced features - quote-to-cart workflows where the buyer requests a quote and the seller approves with discount overrides, multi-step internal approval workflows for purchase orders above threshold, customer-specific catalog visibility rules (a company sees only the SKUs their account is authorized for), and shared catalog inheritance across company hierarchies. The honest take: $5M to $30M B2B brands often run Open Source's B2B basics adequately. $30M-plus B2B brands with multi-tier wholesale flows usually need Adobe Commerce's B2B advanced. A development company should be able to map your specific B2B requirements to which edition's feature set they fit, with examples from their client roster.

Page Builder advanced. Both editions ship Page Builder for visual content editing. Adobe Commerce's Page Builder advanced adds dynamic blocks (content that varies by customer segment), targeted content rules (geo-targeted, behavior-targeted, segment-targeted), and a richer asset management interface. For brands shipping promotional content with personalization rules, the Page Builder advanced feature set is meaningful; for brands using Page Builder as a static content tool, the basic version in Open Source is sufficient.

Customer segmentation. Adobe Commerce ships customer segments with a rule-based segmentation engine - segments built on demographic data, purchase history, browsing behavior, cart contents, and arbitrary EAV attributes. The segments power dynamic pricing, dynamic content, and targeted catalog rules. Open Source has limited customer-group functionality (a fixed set of customer groups with manual assignment) but no rule-based segmentation engine. For brands running personalized merchandising, the segmentation engine is usually the strongest argument for the Adobe Commerce license.

Adobe Sensei AI and recommendations. Adobe Commerce includes Adobe Sensei-powered product recommendations (similar products, frequently bought together, customers also viewed, recently viewed, recommended for you) with a managed recommendation engine running on Adobe's infrastructure. Open Source has no native AI recommendation engine; brands plug in third-party recommendation services (Klevu, Algolia Recommend, Nosto, Bloomreach) at $300 to $3,000 per month depending on traffic tier. The honest math: a $20M brand spending $1,500/month on a third-party recommendation service is paying $18,000 annually, against a $22,000 license-fee delta to Adobe Commerce - the recommendation engine alone does not justify the license, but combined with B2B advanced and customer segments it usually does for brands above $10M GMV.

Varnish full-page cache. Magento ships with built-in support for Varnish as the full-page cache backend. The right configuration uses the Magento-shipped VCL file (located in vendor/magento/module-page-cache/etc/varnish6.vcl) with customizations for the storefront. Ask the development company three sub-questions. One, what's the steady-state Varnish cache hit rate on production traffic? A healthy Magento store at scale runs 70 to 90 percent hit rate; under 50 percent indicates either heavy logged-in traffic (acceptable on B2B) or aggressive cache invalidation (a problem). Two, what's the cache TTL strategy by content type? Catalog category pages 1 to 4 hours typical, product detail pages 1 to 24 hours, CMS pages 24 hours to 7 days. Three, what's the cache invalidation pattern when a product attribute changes? The right answer involves Magento's tag-based invalidation via X-Magento-Tags headers and Varnish's ban command, not a full cache flush.

Redis configuration. Magento uses Redis as the backend for three subsystems - default cache (cache_id_prefix), page cache (when not using Varnish), and session storage. The right configuration uses three separate Redis instances or three separate database numbers on a single Redis instance. Default cache typically sized at 2 to 8 GB depending on catalog complexity, page cache 4 to 16 GB on busy stores, session storage 1 to 4 GB depending on logged-in user volume. Ask the development company about their env.php configuration for the cache backend, the maxmemory-policy setting (allkeys-lru is typical), and the persistence strategy (AOF or RDB, or both). Companies running Magento with file-based cache or default-option Redis are leaving 20 to 40 percent of available performance unused.

MySQL InnoDB tuning. Magento queries the MySQL catalog at every storefront request that misses Varnish. The InnoDB buffer pool is the dominant performance lever - sized at 50 to 75 percent of available system RAM on a dedicated database host, with the buffer pool instances split across CPU cores for concurrency. Three additional levers matter on busy stores. One, the tmp_table_size and max_heap_table_size settings (32 to 64 MB minimum to avoid temporary tables spilling to disk on heavy catalog queries). Two, the binary log retention strategy if running primary-replica replication. Three, the slow-query log threshold (1 second is typical; under 200ms on a healthy store). A development company that has run Magento at scale knows these levers and can describe their typical configurations.

ElasticSearch index health. Magento 2.4 made ElasticSearch the default catalog search backend, replacing the legacy MySQL-based search that scaled poorly above a few thousand SKUs. The right configuration runs ElasticSearch as a dedicated cluster (or managed via Adobe Commerce Cloud's bundled OpenSearch) with one shard per million catalog products, replicated across two nodes minimum for availability. Ask the development company about their index strategy on the catalogsearch_fulltext index, the reindex frequency (typically full reindex weekly with incremental updates on catalog change), and the analyzer configuration for product attributes (custom analyzers per language for multi-region stores). Companies that say "ElasticSearch is configured" without naming the shard count, replica count, and analyzer strategy have not actually tuned the search backend.

The honest performance number. A Hyva-themed Magento 2 store on properly-tuned infrastructure (Varnish full-page cache, Redis backends, InnoDB buffer pool sized correctly, ElasticSearch with proper sharding) lands LCP at the 75th percentile under 2.5 seconds on mobile per Core Web Vitals guidance. INP under 200 milliseconds at the 75th percentile is achievable on Hyva but rare on Luma. CLS under 0.1 is achievable on both with image-dimension discipline. A development company that has shipped this work has the field data to prove it. A company without field-data evidence is selling theory.

Signal 1: CVE response time. Adobe ships Magento security bulletins on a roughly quarterly cadence (the official cadence is "as needed" but the practical pattern is February, May, August, November) with emergency patches in between when critical CVEs land. A competent Magento development company applies the patch to a staging environment within 72 hours of disclosure, runs regression tests for 5 to 7 days, and pushes to production inside two weeks. Slower than three weeks is institutional risk; the average exploit-in-the-wild window after a public Magento CVE disclosure is 14 to 30 days, with botnet-driven mass exploitation typical for unauthenticated RCE classes. Ask the development company for their last three patch deployments by date - the answer should be specific (Feb 11 patched APSB24-XX, applied to staging Feb 12, regression complete Feb 19, prod deployment Feb 21) not vague ("we patch when needed").

Signal 2: regression test discipline. Patching Magento without a regression test suite is institutional Russian roulette - the platform is large enough that small patches occasionally break unrelated subsystems (admin grids, catalog rules, checkout flows). The development company should describe their regression suite by name. The Magento Test Framework (MTF) for functional UI tests, PHPUnit for unit tests on custom modules, Behat for behavior-driven tests on the storefront, and Cypress or Playwright for end-to-end browser tests on critical paths (homepage, product detail, cart, checkout). Coverage targets - 60 percent unit-test coverage on custom modules, 100 percent functional-test coverage on the critical-path flows. A development company that runs no regression suite and patches Magento manually is shipping platform fragility into your production.

Signal 3: GitHub repository hygiene. Modern Magento engineering happens on GitHub with strict repository conventions. Look for branch protection on main (no direct pushes, mandatory PR reviews from a second engineer), signed commits via GPG (verifies the committer's identity), conventional-commits-style commit messages (feat/fix/refactor prefixes), a documented CODEOWNERS file (which engineers review which subsystems), a CI/CD pipeline with automated linting and test runs on every PR, and a documented release process (semantic versioning, changelog, tag annotation). Ask the development company for a redacted screenshot of their main repository's branch settings - real security cadence shows branch protection enforcement. Companies developing on FTP, on shared SSH access to staging servers, or on a single-branch GitHub repo without PR reviews are working a 2015 development model.

Bonus signal: open-source contribution history. Senior Magento engineers contribute to the platform - the magento/magento2 repository has accepted thousands of community PRs. Ask the development company for a count of merged PRs to magento/magento2 in the last 24 months from named engineers on their bench. Companies with no contribution history are not necessarily incompetent (closed-source contribution is fine) but companies with documented contribution depth carry a stronger architectural understanding of the platform's internals than companies that work exclusively on top of it.

Adobe's Magento security center publishes the security bulletin archive; subscribe to the security alerts mailing list and verify that any candidate development company is also subscribed. The Magento Marketplace (commercemarketplace.adobe.com) lists vetted modules with security review; a development company recommending Marketplace modules over arbitrary GitHub installs is following the lower-risk path.

Element 1: written field-mapping document. A 15 to 40-page document covering every product attribute, customer attribute, order attribute, B2B catalog rule, and metafield equivalent on the source and destination platforms. Magento's EAV model stores product data flexibly with arbitrary custom attributes; mapping 40-plus custom attributes across thousands of products to a destination schema is real engineering work. A development company that quotes data migration without a written field-mapping document has not looked at your source data carefully. Our companion piece on best practices for ecommerce data migration covers the field-mapping methodology in detail.

Element 2: redirect map covering every URL with organic traffic. Typical Magento sites have 5,000 to 50,000 URLs requiring 301 redirects on a migration. Most quotes budget redirects for the top 100 ranking pages; that is a budget-protection mistake. Mid-market Magento stores frequently have 500 to 5,000 pages with organic traffic, and missing redirects on the long tail drops 20 to 40 percent of organic traffic in quarter one - which is worth more than the redirect work would have cost. A clean migration budgets the full URL inventory from a Google Search Console export plus a server-log analysis, mapped to the destination URL structure with a documented 301 chain. Our piece on Shopify 301 redirect best practices covers the methodology when the destination is Shopify.

Element 3: customer-password preservation strategy. Magento hashes customer passwords with Argon2id (since 2.4.0) or bcrypt (older installs). Shopify uses bcrypt with a different work factor. Direct password translation between platforms requires either a custom re-hash flow at first login, or the source platform's password hashes accepted by the destination via a custom authentication module. The fallback is forcing every customer to reset their password on first login post-migration - which costs 10 to 30 percent of returning customer revenue in the first month. A development company that has done migration work names the password-preservation strategy in the proposal.

Element 4: B2B catalog recreation strategy. If the source has B2B (company accounts, customer-segment-specific catalogs, NET payment terms, requisition lists, quote-to-cart functionality), all of it has to be recreated on the destination platform. The recreation work is substantial - mapping source company accounts to destination company accounts, recreating customer-segment catalog visibility rules, re-establishing NET payment terms with the destination payment gateway's credit-limit features, and rebuilding requisition list functionality. Shopify Plus's B2B module has caught up significantly in 2024 to 2026 but the catalog-rule mapping still requires explicit engineering. A development company that quotes a B2B Magento migration without a B2B catalog recreation plan has under-scoped the work.

Element 5: payment-gateway and tax-engine reconfiguration. The destination platform has a different payment-gateway integration surface and a different tax-engine integration surface than the source. Magento's integrations with Authorize.net, Braintree, Stripe, Adyen, PayPal, Klarna, and Afterpay each have to be re-established on the destination platform with correct credentials, currency configuration, fraud-detection rules, and refund flows. The tax engine (Avalara, TaxJar, Vertex) requires re-credentialed integration with the destination platform's API surface. PCI compliance posture transfers (both Magento and Shopify Plus are PCI Level 1) but the SAQ documentation has to be regenerated for the destination.

Honest mid-points on migration cost: the migration work alone runs $50,000 to $300,000 over 12 to 26 weeks depending on catalog size, B2B complexity, and the cleanliness of the source data. Our companion piece on Magento to Shopify migration cost walks through the line-item budget at small-store, mid-market, and enterprise tiers. A quote materially below the floor of those ranges usually indicates skipped work on one of the five elements above.

Stay on Magento when. Catalog complexity exceeds 10,000 SKUs with deep attribute sets, tiered pricing per customer group, and multi-warehouse inventory routing. B2B requirements include company accounts with internal approval workflows, NET-30 payment terms with credit limits, requisition lists, and per-customer-group catalog visibility. Multi-store architecture genuinely requires shared SKUs across regional storefronts with isolated catalog rules and per-region tax engines. ERP integration via Boomi, MuleSoft, or Celigo is already wired to NetSuite, SAP, or Microsoft Dynamics, and the cost of rebuilding the integration on Shopify Plus exceeds the maintenance cost on Magento. The brand is past $50M GMV with internal Magento engineering retained.

Migrate to Shopify Plus when. Adobe Commerce license fees have risen 40 to 60 percent since 2022 and the math no longer works against Shopify Plus's flat $2,500 per month. Your B2B needs fit Shopify's B2B module - the platform shipped company accounts, customer-specific catalogs, NET payment terms, and quote-to-cart in 2024 to 2026, closing most of the gap with Magento for $5M to $30M B2B brands. Hosting and developer retainers exceed $50,000 per year combined. The catalog is under 5,000 SKUs without exotic attribute requirements. The brand wants faster iteration speed and a larger app ecosystem - Shopify's 8,000-plus app store dwarfs Magento's commerce marketplace.

The honest stance from us. Digital Heroes does not actively build new Magento 2 stores in 2026. Our delivery focus is Shopify Plus - we ship migrations from Magento to Shopify Plus, custom Shopify Plus theme builds, headless Hydrogen storefronts on Shopify, and Shopify Plus B2B builds. The Magento engineering rubric in this article is universal - apply it to whichever development company you sign, whether they are a Magento specialist (Magebit, Vaimo, Born Group, Astound Commerce) or a hybrid Magento + Shopify partner (Forix, Rave Digital, ourselves). What we offer in the Magento conversation is the migration path - Magento to Shopify Plus migration with a 3-week refundable readiness audit that answers the stay-or-migrate question with numbers, not preferences. If the answer is stay, we hand you the engineering rubric and you sign a Magento specialist. If the answer is go, we ship the migration.

Reference clients on the Shopify side - Emani Cosmetics ($0 to $2M MRR over 18 months on Shopify Plus), Big Game Sports (B2B replatform), Noble Paris (multi-region Shopify Plus across France, UK, US). The full case studies walk through the engineering work in detail. The team page (Prasun Anand) covers the technical bench depth.