Questions, answered.

May 12, 2026 — per Adobe’s official release schedule. Alongside 2.4.9, Adobe ships security patches for every supported line: 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, and 2.4.4-p18.

You don’t have to upgrade to 2.4.9 the day it ships, but you do need to be on a supported, patched line. If you’re on 2.4.4 or older, your version goes EOL in 2026 and stops receiving security patches — that’s the urgent case. For 2.4.5+, you can stay on your current line as long as you apply the May 12 security patch (2.4.x-pYY).

Typical timelines:

• Express (2.4.7 / 2.4.8 → 2.4.9): 5 – 7 business days
• Standard (2.4.5 / 2.4.6 → 2.4.9): 10 – 14 business days
• Major (2.4.3 or older → 2.4.9): 3 – 5 weeks
• Magento 1 → 2.4.9: 6 – 12 weeks (full re-platform)

Add 2 – 3 days for staging review, regression QA, and the production go-live window.

No. We use a blue-green deployment: the upgrade runs on a parallel staging environment, gets full QA, and then the DNS/load-balancer cuts over to the new version in under 30 seconds. Your live store keeps taking orders the entire time. We do schedule a 5-minute maintenance window for the final database sync, typically at 3 AM in your timezone.

Some will. The pre-upgrade audit (free with every booking) catalogues every extension + custom module on your store and flags incompatibilities before we touch production. For incompatible extensions we either: (1) upgrade to a 2.4.9-compatible version from the vendor, (2) patch the extension ourselves if the vendor is slow, or (3) rebuild the functionality natively. You get a full report before any work starts — no surprises.

Fixed-price tiers, no per-hour surprises:

• Express: $1,499 — minor-version jumps (2.4.7/2.4.8 → 2.4.9), Hyvä intact, < 5 custom modules
• Standard: $3,499 — multi-version jumps, theme migration, up to 20 extensions
• Enterprise: Custom quote — B2B, multi-store, 30+ extensions, ERP/POS integrations, M1 → M2

Every quote includes pre-upgrade audit, full QA, blue-green deploy, and 14 days of post-launch bug-fix coverage.

Adobe Commerce 2.4.9 supports PHP 8.3 and 8.4 (8.4 recommended). MariaDB 10.6 / 10.11, MySQL 8.0, OpenSearch 2.x, RabbitMQ 3.13, Redis 7.2. We handle the full stack — if your hosting needs upgrading we can either coordinate with your provider or migrate you to a more performant setup as part of the upgrade.

Two safety nets: (1) Blue-green means the old version stays warm for 72 hours — one DNS flip rolls back instantly. (2) Every upgrade includes 14 days of post-launch bug-fix support: anything that breaks because of the upgrade gets fixed at no extra charge. After day 14, you can move to a monthly retainer if you want continued cover.

No. Magento upgrades are schema-only — your products, customers, orders, reviews, CMS pages, configurations all stay intact. We snapshot the production database before every step, run the upgrade on a clone, validate counts (orders, customers, products) match before and after, and only then promote to production. Plus the blue-green setup means the original DB is preserved for 72 hours.

Not if it’s done right. We preserve every URL rewrite, canonical, hreflang, sitemap, and structured-data block. Pre/post crawls (Screaming Frog) compare the URL set; any 301 redirects you had stay 301s. Core Web Vitals typically improve on 2.4.9 because of the new caching + Hyvä performance fixes, which is good for rankings, not bad.

We typically run 3 – 4 upgrade cohorts per month with capacity for 2 stores per cohort. The May 12, 2026 launch cohort books out 4 – 6 weeks ahead, so reserve before April 1, 2026 for a Day-1 slot. After that we shift you to the next available cohort — usually within 2 – 3 weeks.

If your store has < 5 extensions, no custom modules, and you’re comfortable with composer + bin/magento, yes. Adobe’s own upgrade tool handles most of it. The cases where DIY usually goes wrong: extension conflicts, broken indexers post-upgrade, payment/checkout regressions you don’t catch in QA, missing data patches, and the dreaded composer.lock conflict between core modules and theme overrides. If your monthly orders have a comma in them, get help.

Hyvä is the modern frontend framework for Magento 2, built on Tailwind CSS + Alpine.js. It replaces Magento’s default Luma theme (which uses jQuery + KnockoutJS) and ships with 5–10× faster page loads, Lighthouse scores in the 90–100 range, and core-web-vitals green by default. Stores that switch typically see conversion lifts of 8–25% from speed alone.

Typical timelines:

• Express (lightly customised theme, < 5 extensions): 2 – 3 weeks
• Standard (custom theme, up to 20 extensions): 4 – 6 weeks
• Enterprise (heavy customisation, B2B, multi-store): 8 – 12 weeks

Add 1 week for staging review + regression QA + the production cutover window.

Some will, some won’t. Hyvä-Compatibility-Module is required for every Luma extension to render frontend HTML — most popular extensions (Mageplaza, Amasty, etc.) ship Hyvä compat modules officially or via the community. The pre-project audit catalogues every extension on your store and flags which need (a) the vendor’s compat module, (b) a custom rebuild, or (c) replacement with a Hyvä-native alternative. You see the report before any work starts.

Hyvä Checkout is a one-page Alpine.js-based checkout that replaces Magento’s slow KnockoutJS checkout. It loads in < 1 second, has a 50% lower bounce rate, and integrates with all major payment gateways (Adyen, Stripe, PayPal, Klarna, Mollie, Razorpay). Yes, you should use it — every Hyvä build we ship now includes Hyvä Checkout by default. Adobe Commerce 2.4.9 ships Hyvä Checkout natively as part of the Hyvä module.

Out of the box, a clean Hyvä install scores 95–100 on Performance, Accessibility, Best Practices, and SEO. With heavy customisation, third-party scripts (GTM, Hotjar, chat widgets), or large media-heavy product pages, expect 85–95. We commit to 90+ as the floor on every Hyvä project — if we ship something below that, we fix it for free.

Hyvä licence is paid per Magento store URL — €1,000 (one-time, perpetual) or €100/year (subscription) per production storefront. Staging environments are free. This is the licence fee paid to Hyvä Themes BV — separate from our development cost. We’ll handle the licence purchase & setup as part of the project (pass-through, no markup).

Hyvä is best for 95% of stores: faster build (4–6 weeks vs 4–6 months), much lower TCO (no separate Node.js infrastructure), works with all Magento extensions via compat modules, and ships green Core Web Vitals out of the box. PWA Studio only makes sense for headless / app-shell / offline-first use cases — and even then, most teams find Hyvä covers 90% of the wins at 20% of the cost.

No. Hyvä runs on the same Magento 2 stack — PHP 8.x, MySQL/MariaDB, Redis, Elasticsearch/OpenSearch. It actually uses fewer resources than Luma because the frontend doesn’t need RequireJS / KnockoutJS bundling. Many stores see hosting bills drop after migration. We can audit your current hosting as part of the project and recommend optimisations.

Fixed-price tiers, no per-hour surprises:

• Theme migration (Luma → Hyvä): $499 — minor design changes, < 5 custom modules
• Custom Hyvä build: $999 — bespoke design, up to 20 extensions, Hyvä Checkout
• Enterprise: Custom quote — B2B, multi-store, ERP/POS integration, headless

Every quote includes pre-project audit, regression QA, blue-green deploy, Lighthouse 90+ guarantee, and 14 days of post-launch bug-fix coverage. Hyvä licence (€1,000 one-time or €100/yr) is separate and paid directly to Hyvä Themes.

Yes — positively, if done right. URLs, redirects, canonicals, hreflang, structured data, and sitemaps all stay intact. Core Web Vitals typically improve dramatically (LCP from 4s → 1.5s, CLS from 0.3 → 0), which is a Google ranking factor. Lighthouse SEO score goes from ~80 (Luma) to ~95 (Hyvä) by default. We do pre/post crawls (Screaming Frog) and report any URL diffs before cutover — no surprise drops.

Two safety nets: (1) Blue-green deploy means your Luma theme stays warm for 72 hours — one DNS flip rolls back instantly. (2) Every project includes 14 days of post-launch bug-fix coverage: anything that breaks because of the migration gets fixed at no extra charge. After day 14, optional monthly retainer for continued cover.

The best time was last year. The second best is now. Specifically: migrate before (a) your next Magento upgrade — combine the two and save 30%, (b) a re-platform or major redesign — Hyvä is faster than re-skinning Luma, (c) Black Friday — if your Luma site is slow, you’re leaving conversion money on the table. Adobe’s 2.4.9 release on May 12, 2026 ships Hyvä Checkout natively, making this an ideal combine-with-upgrade window.

Magento ships with the building blocks for great SEO — canonicals, sitemaps, meta-tag editing, URL rewrites — but those defaults are incomplete and aimed at developers, not search engines. Out of the box, Magento has no structured data on category or product pages, no hreflang for multi-store setups, no llms.txt, weak default meta-templates, layered-nav URLs that bloat the index, and a Luma frontend that drags Core Web Vitals. Most stores never go past the defaults — which is why “Magento SEO” is a paid specialism. The good news: every gap is a fixable engineering problem, not a platform limitation.

An SEO consultant tells you what’s wrong — runs Screaming Frog, looks at GSC, writes a 40-page report, hands it to your dev team. The dev team then has to translate “add Product schema to PDP” into actual Magento layout XML, blocks, and ViewModels.

An SEO developer does both. Audits the site, then ships the fix in code. No translation lag. No “we’ll get to it next sprint.” For Magento specifically this matters — structured data, hreflang, canonicals, llms.txt all live in the codebase, not in a CMS field. Hire the developer.

Three things make it different: (1) URL bloat — layered nav, search results, sort/order params can balloon the index by 10× if not handled. (2) Multi-store / multi-language — hreflang, canonicals across store views, and per-locale URL rewrites are non-trivial. (3) The product/category split — you have category pages competing with product pages competing with CMS pages for the same keywords. Generic SEO advice (“publish blog posts”) doesn’t cover any of this. Magento SEO is mostly a technical problem before it’s a content problem.

Yes — indirectly but measurably. Hyvä gives you Lighthouse 95+ and green Core Web Vitals out of the box, which Google has confirmed as ranking signals. Stores migrating from Luma to Hyvä typically see LCP drop from 4s to under 1.5s, CLS from 0.3 to 0, and Lighthouse SEO score jump from ~80 to ~95. That moves rankings on competitive keywords by 1–3 positions on average. But Hyvä alone doesn’t add structured data, fix hreflang, or generate llms.txt — those are separate work. Hyvä is necessary; not sufficient.

Structured data (JSON-LD) tells search engines what each page is — a Product, an Article, a FAQ, a BreadcrumbList. Google uses it to render rich results (star ratings, prices, availability, FAQ accordions) directly in search, which can double or triple click-through rate on the same ranking position.

Out of the box, Magento ships no structured data. Adding it correctly — Product on PDP, ItemList on category, FAQPage on FAQ pages, Organization site-wide, Person on author bios — is one of the highest-ROI SEO interventions you can make. We ship it via the Panth_StructuredData module on every project.

llms.txt is the robots.txt for AI engines — a structured page index at /llms.txt that tells ChatGPT, Claude, Perplexity, and Google AI Overviews which pages on your site are worth citing. It lists your CMS pages, top categories, blog posts, services, with one-line summaries.

Yes, your Magento store should have one. AI-engine traffic is a fast-growing 2026 channel — Perplexity is sending real e-commerce referrals already. Most Magento stores don’t even know llms.txt exists. Our open-source module auto-generates it on every cron, alongside robots.txt and sitemap.xml. Free win.

Four things: (1) ship /llms.txt — the AI page index. (2) whitelist GPTBot, ClaudeBot, PerplexityBot, and Google-Extended in robots.txt (most templates accidentally block them). (3) use rich, factual content on key pages — AI engines cite pages with clear claims, dates, prices, and structured data. (4) publish content that answers questions directly — FAQ-style headings (“What is X?”, “How do I Y?”) get cited far more often than marketing copy. We do all four as part of the SEO Project tier.

No — and anyone who guarantees first-page rankings is lying. Search results depend on competition, content quality, backlinks, brand authority — none of which are fully under our control. What we do guarantee in writing: Lighthouse 95+, structured data on every page type, hreflang validity, zero index loss vs. baseline, and llms.txt shipping. Those are the technical floors that enable ranking. The actual ranking moves come from the combination of clean technical SEO + content + time. We’re honest about the difference.

Three timeframes: (1) Technical fixes (structured data, Core Web Vitals, hreflang) — 2–6 weeks to show in GSC impressions / position. (2) On-page changes (titles, metas, internal links) — 4–8 weeks for Google to recrawl + reindex + rerank. (3) Content + link-building — 3–6 months for a new pillar page to land on page 1 for competitive terms. Anyone telling you faster is selling snake oil. We send a 30-day position-tracking report after launch so you can see the curve as it bends.

Technical SEO is everything that affects how search engines crawl, render, and index your site — sitemap, robots, structured data, canonicals, hreflang, page speed, mobile-friendliness, redirects, internal linking architecture. It’s the floor. If technical SEO is broken, no amount of content fixes it.

On-page SEO is what’s on each individual page — title tag, H1, meta description, headings, body copy, image alt text, internal links to / from. It’s how you rank for a specific keyword once technical SEO has unlocked indexing.

Magento needs technical SEO first. Doing on-page work on a site with broken hreflang or no structured data is rearranging deck chairs.

Both — and the order matters.

• Before migration: baseline crawl (Screaming Frog), full GSC export, current Lighthouse scores, ranking snapshot for top 100 keywords. This is your “don’t-break-it” reference.
• During migration: preserve URLs, set up 301s for any URL changes, port hreflang and canonicals, port structured data.
• After migration: immediate post-launch crawl, diff against baseline, fix any 404s / redirect chains, resubmit sitemaps to GSC, monitor for index drops over 30 days.

Migrations done without an SEO playbook routinely cause 20–60% organic-traffic drops. Done with one, the loss is zero or near-zero.

Hreflang tells Google which version of a page to serve to users in different countries / languages — e.g. en-GB for UK shoppers, de-DE for German shoppers. Done right, it routes the right user to the right store view and prevents duplicate-content penalties.

It’s almost always broken because of three foot-guns: (1) missing reciprocal tags — if page A links to page B with hreflang, B must link back to A. (2) hreflang loops — A points to B, B points to C, C never points back. (3) wrong locale codes — en_UK instead of en-GB. Magento’s default multi-store setup ships hreflang in the page header but doesn’t validate it. Our audit catches all three on every project.

Yes — measurably and in writing. Every Full Optimization project ships with a Lighthouse 90+ guarantee and a target of 50%+ TTFB reduction. We capture before/after metrics on staging every day during the project (Lighthouse, WebPageTest, RUM if you have it) so you can see the curve flatten in real time. If we miss the agreed targets at go-live, we keep tuning at no extra charge until we hit them. The audit-only tier doesn’t include the fix — it’s a diagnose-and-prioritise report you can hand to any developer to execute.

Three quick checks: (1) Run your homepage through PageSpeed Insights — if the mobile score is below 70, you’re leaving conversion money on the table. (2) Check Search Console > Core Web Vitals — any URL flagged as “Poor” is a Google ranking liability. (3) Time-to-first-byte — if your TTFB is over 800ms on a warm cache, your stack is misconfigured. The free 30-min audit covers all three plus a slow-query log review — you get a written report whether or not you go ahead with the fix.

Mobile: 90+ is the floor we target on every project. 95+ is achievable on Hyvä-based stores with disciplined image strategy and minimal third-party scripts. Below 70 mobile means real revenue impact — Google research and our own client data both show conversion drops sharply once mobile Lighthouse falls under 70. Desktop typically lands 5–10 points higher than mobile because the Lighthouse network throttle is more punishing on mobile. Don’t obsess over the desktop score — mobile is what Google ranks and what most of your customers see.

Yes — checkout is one of the most common Full Optimization scopes. Typical wins: (1) defer all non-essential third-party scripts (chat, analytics, A/B test tools) until after the order is placed, (2) tune the shipping-method and tax-calculation API calls (parallelise where possible, cache where allowed), (3) trim the KnockoutJS view-models that ship with Luma checkout, (4) if you’re open to it, drop in Hyvä Checkout — one-page Alpine.js checkout that loads in < 1s and ships natively in 2.4.9. Checkout-only Lighthouse scores typically jump from 40–60 to 85–95 after this work.

No — that’s the whole reason we use blue-green deploy. The optimised configuration is built and warmed up next to production, then we cut over in < 30 seconds. The old config stays warm for 72 hours, so if anything regresses we flip back instantly. We also do a regression QA pass on staging covering: critical extension flows (search, faceted nav, custom checkout steps, payment gateways), the admin panel, and any custom REST/GraphQL endpoints. The audit catalogues every extension on your store and flags risky ones before any work starts — you sign off the scope, not us.

Core Web Vitals signals start flowing into Search Console within 28 days — that’s the rolling window Google uses for the field-data dataset (CrUX). Visible ranking movement typically takes 6–12 weeks as Googlebot re-crawls and CWV updates feed into the page-experience signal. Stores in competitive SERPs (fashion, electronics, B2B supply) usually see the biggest lift — speed is a tie-breaker against equally-relevant competitors. We do a Screaming Frog crawl pre and post launch and share the URL diff so you can spot any Core-Web-Vital regressions early.

Three categories. (1) Best value: Hetzner dedicated (CCX or AX line) — obscene CPU per dollar, fixed cost, you own the box. Pair with our managed config. (2) Fully managed: Hyvä Cloud, Cloudways, or Sonassi — pricier per month but no DevOps load on your team. (3) Enterprise: Adobe Commerce Cloud if you need the SLA & support contract; AWS behind a custom Terraform stack if you have an in-house DevOps team. We’re hosting-agnostic — the optimisation is portable across all of these. The audit includes a hosting recommendation specific to your traffic shape and budget.

If your Luma frontend is your bottleneck (slow LCP, big JS bundle, KnockoutJS-heavy checkout), yes — Hyvä gets you to Lighthouse 90+ for less effort than re-tuning Luma to the same level. If your bottleneck is backend (slow DB queries, OpenSearch misconfigured, Varnish not in front, third-party-script-heavy theme on a fast CDN), Hyvä won’t fix that — backend tuning will. The audit tells you where your time is actually being spent. If it turns out Hyvä is the answer, we have a separate Hyvä migration service — this performance project would be a stepping-stone or a bundle.

Three layers, each handling different traffic. Varnish sits in front of Magento — it caches full HTML for cacheable pages (category, PDP, CMS) and serves them in < 50ms without ever waking up PHP. FPC (Full Page Cache) is Magento’s own page cache, used as a fallback when Varnish misses. Redis handles two separate jobs: (a) the default-cache for config, layout, blocks, and (b) PHP session storage. We tune all three: Varnish VCL with hole-punching for cart/customer state, FPC tag invalidation, Redis maxmemory + eviction policy, separate Redis databases for cache vs sessions. Done right, your origin only sees logged-in / cart traffic — everything else is served from cache.

Yes — admin tuning is part of every Full Optimization. Common culprits: (1) the indexer running on schedule but not actually completing between runs, (2) bloat in quote, quote_address, and sales_order_grid tables (we run cleanup with a safety-net backup), (3) the admin grid loading the entire product collection because of a missing index, (4) third-party admin extensions running expensive observers on every page load. After tuning, admin pages typically load in 1–2s instead of 8–15s, and the indexers actually keep up with catalogue changes.

Two compounding revenue effects. (1) Conversion lift: stores typically see 8–25% uplift within 90 days post-optimisation, before any UX changes. Google’s own research shows every 100ms of LCP improvement = ~1% conversion gain in retail. (2) SEO lift: rankings improve over 6–12 weeks, which compounds the conversion gain because you’re also getting more traffic. Plus a one-off cost saving: most stores can downgrade hosting after the optimisation (CPU/RAM headroom that was masking the inefficiency is no longer needed) — we’ve seen 30% hosting bill drops. On a $1M/yr store, even a conservative 8% conversion lift covers the Full Optimization fee in under a month.

Yes — Lighthouse 90+ on mobile and desktop on the agreed key pages (homepage, top category, top PDP, checkout step 1) at go-live. It’s in the contract. If we miss it, we keep tuning at no extra charge until we hit it. The audit-only tier doesn’t carry the guarantee — it’s a diagnostic report. The Express Audit + Full Optimization combo does. The Lighthouse target is measured on the staging environment with the production traffic profile (no GTM blocking, no ad-blockers, throttled to Lighthouse’s mobile network) — the same way Google measures it. We won’t cheat the score by removing necessary scripts — we’ll defer / tree-shake / replace them with lighter alternatives.

Magento 1 hit End of Life on June 30, 2020. Adobe stopped releasing security patches, bug fixes, and PCI compliance updates from that date. Every day a store stays on M1, it accumulates unpatched CVEs — and most card processors (Stripe, Braintree, Authorize.net) now flag M1 stores as non-compliant during PCI audits. Beyond security: Magento 2 is faster (PHP 8, Varnish, full-page cache native), has a modern admin, ships with B2B and PWA-ready features, and runs on actively-maintained extensions. Migration isn’t optional anymore — it’s the only safe path forward for serious commerce.

Typical timelines depend on store complexity:

• Small store (< 10k SKUs, < 10 extensions, light customisation): 6 – 8 weeks
• Standard store (up to 50k SKUs, up to 20 extensions, custom theme): 8 – 10 weeks
• Enterprise (B2B, multi-store, ERP/POS/PIM integrations, 100k+ SKUs): 12 – 16 weeks

Add 1 – 2 weeks for staging review + final delta-data migration + the production cutover window. We give a fixed timeline up front and won’t move the goalposts mid-project.

Fixed-price tiers, no per-hour surprises:

• Free Audit: $0 — 30-min call + written report on scope, risks, and timeline
• Standard Migration: $4,999 — up to 50k products, up to 20 extensions, full data + SEO carry-over, 14 days post-launch coverage
• Enterprise: custom quote — B2B, multi-store, ERP/POS integrations, 100k+ SKUs, dedicated PM

Hosting, SSL, payment gateway re-application fees, and any third-party extension licences (e.g. Amasty, Mageplaza) are pass-through with no markup. You always see the line items before signing.

Yes — 100% of standard data migrates: customers (with addresses, groups, store credit, gift cards, password hashes where compatible), orders (open + completed + invoices + shipments + credit memos), products (simple, configurable, bundled, virtual, downloadable), categories, reviews, ratings, CMS pages, CMS blocks, URL rewrites, and store config. We use Adobe’s Data Migration Tool as the foundation, plus custom scripts for any non-standard tables (custom modules, third-party schemas). Three test runs on staging confirm row counts match before the live delta-migration during cutover. Audited reports show before/after counts on every table — nothing slips through silently.

Done right, zero ranking loss — and usually a small lift from M2’s better Core Web Vitals. Our SEO continuity protocol: (1) Pre-migration Screaming Frog crawl captures every indexed URL + status code + title + meta + canonical + hreflang. (2) Every legacy URL gets a 301 redirect to its M2 equivalent (auto-mapped where slugs match, manual where they don’t). (3) Schema.org JSON-LD, hreflang, canonicals, meta robots, and XML sitemaps all carried over. (4) Post-launch crawl compares against pre-launch — any 4xx/5xx flagged and fixed within 24 hours. (5) Search Console resubmission of new sitemap. Most stores see ranking improve within 60 days from speed alone.

No — M1 and M2 have completely different architectures. Every M1 extension needs an M2 equivalent. Three paths:

• Vendor M2 version — Mageplaza, Amasty, Magefan, Aheadworks, Webkul all rebuilt for M2. Often free upgrade with proof of M1 licence.
• Community / Marketplace alternative — if the original vendor disappeared, there’s usually a competitor with feature-parity.
• Custom rebuild — for niche / proprietary extensions, we rebuild on M2’s API + UI components.

The free audit catalogues every extension on your M1 store and maps each to one of the three paths — with cost & risk — before any work starts.

Depends on your store:

• Stay on Magento (migrate to M2): if you have B2B flows, multi-store, custom checkout, ERP/POS integrations, 10k+ SKUs, or international tax requirements. Magento 2 is the cheaper path long-term and you keep the data + URL history.
• Move to Shopify: if you have < 5k SKUs, simple B2C, no custom checkout, and value low operational overhead more than control. Shopify Plus starts at $2,300/month vs Magento OS being free + hosting.
• Move to WooCommerce: rarely makes sense from M1 — you lose the commerce-grade catalog model.

The free audit includes a platform-fit assessment — we’ll tell you honestly if M2 isn’t the right answer.

Both options work — we recommend based on store maturity:

• Like-for-like rebuild (default): pixel-perfect M2 theme matching the M1 design. Lowest risk for SEO + UX continuity. No A/B variable to confuse migration metrics. Choose this if your M1 design still converts well.
• Migrate + redesign: combine the migration with a fresh design (or move to Hyvä for the perf bonus). Only ~20% more time and cost than like-for-like, and you get a 2-for-1 project. Choose this if your M1 design is dated, mobile-weak, or pre-Core-Web-Vitals.

Pre-migration A/B testing on staging proves the new design converts at least as well before cutover — we won’t ship a redesign that hurts revenue.

Every legacy M1 URL gets a 301 redirect to its M2 equivalent. Three layers:

• (1) Slug-match auto-mapping — Magento’s URL rewrite migration handles 80–90% of product, category, and CMS URLs automatically (slugs unchanged).
• (2) Manual mapping — for URLs that changed (e.g. M1 .html suffix dropped, custom routes restructured), we generate a CSV of old→new and load it into M2’s url_rewrite table.
• (3) Web-server fallback — nginx / Apache rules catch anything missed at the URL-rewrite level (e.g. legacy .php paths).

Pre/post Screaming Frog crawls compare every URL — any 404s on legacy URLs get patched within 24 hours of cutover. Zero permanent 404s guarantee.

M2 has a completely different checkout (KnockoutJS-based, multi-step or 1-page via Hyvä Checkout) so a custom M1 checkout flow needs to be rebuilt. Process:

• Document the M1 flow — every step, validation rule, payment gateway, business rule.
• Map to M2 checkout architecture — vanilla M2, Hyvä Checkout, or custom UI components. Hyvä is usually cheaper and faster.
• Gateway re-integration — Stripe, Adyen, Braintree, PayPal, Authorize.net, Razorpay, Klarna, Mollie all have native M2 modules. Stored payment tokens carry over where the gateway supports it (most do).

Recurring subscriptions, gift-card balances, and store credit all preserved. Three test transactions per gateway in staging before cutover.

Two safety nets, both built in:

• (1) Blue-green cutover: M1 stays warm and reachable for 72 hours after cutover. DNS / load-balancer can flip back in under 30 seconds if anything breaks. Customer-facing impact during rollback: zero — we cache-bust both ways.
• (2) 30 days post-launch coverage: anything that breaks because of the migration (data inconsistency, redirect miss, payment hiccup, missing email template) gets fixed at no extra charge for 30 days. After that, optional monthly retainer for continued cover.

We also keep the final M1 database snapshot for 90 days — if a customer reports a missing 2017 order on day 60, we can reconstruct it from the snapshot.

Yesterday. Magento 1 has been EOL since June 2020 — every additional day is a CVE exposure and a PCI-compliance risk. Practical timing:

• If your last PCI audit failed or is upcoming: start now. Most processors (Stripe, Braintree, Adyen) flag M1 as non-compliant in 2026.
• If you’re re-platforming anyway: M2 + Hyvä is the cheapest combined upgrade path.
• If you’re > 6 months from Black Friday: you have time for a comfortable migration with two months of post-launch stabilisation.
• If you’re < 3 months from a peak season: book the audit now, schedule the migration for January.

The longer you wait, the more your M1 stack drifts from anything modern. Book the free audit — we’ll tell you honestly when to start.

Magento Open Source is the free version — it ships with the core e-commerce engine but does not include the B2B module. To run B2B on Open Source you must build the B2B features yourself (custom companies, quote workflow, customer-specific pricing). That is doable but expensive — you’re reinventing what Adobe ships out-of-the-box.

Adobe Commerce (the paid edition, formerly Magento Enterprise) ships the official B2B module at no extra cost: companies + roles + permissions, request-for-quote workflow, requisition lists, shared catalogues, multi-tier pricing, and credit limits / payment-on-account. For 95% of B2B stores, Adobe Commerce + B2B module is the right starting point. Annual licence runs from ~$22,000 USD/year and scales with GMV.

The Adobe Commerce B2B module ships these out-of-the-box:

• Companies & roles — multi-buyer accounts under one company; admin / purchaser / approver / finance roles; org charts.
• Approval workflows — orders over $X route to an approver before submission.
• Request for Quote (RFQ) — buyers convert their cart to a quote; sales reps respond; quote → order conversion.
• Customer-specific pricing — tiered pricing per customer group, contract pricing, hidden prices behind login.
• Requisition lists — saved cart templates per buyer.
• Shared catalogues — SKUs visible only to designated companies.
• Payment on account — Net 30 / Net 60 with credit-limit enforcement at checkout.
• Quick order — SKU-based bulk add-to-cart (paste a list, attach a CSV).

Everything else (ERP integration, custom approval matrices, sales-rep dashboards) is layered on top.

Typical phased timelines:

• B2B Audit: 1 – 3 days — discovery + written report.
• Standard B2B Build: 8 – 10 weeks — B2B module setup, companies/roles, quote workflow, multi-tier pricing, requisition lists, 1 ERP connector, Net-30 + credit limits, sales-rep dashboard, blue-green deploy.
• Enterprise B2B: 12 – 16 weeks — everything above plus multi-region orchestration, headless GraphQL B2B, multiple ERP integrations, custom sales-rep CRM, ABM integration.

Add 2 weeks for UAT with your real B2B buyers, regression QA, and the production cutover. We work daily on staging with review access from week 2.

Fixed-price tiers, no per-hour surprises:

• B2B Audit: $999 USD — written scope, integration plan, risk register.
• Standard B2B Build: $4,999 USD — full B2B build on Adobe Commerce, 1 ERP connector, sales-rep dashboard.
• Enterprise B2B: Custom quote — multi-region, headless, multiple ERPs, custom CRM.

Adobe Commerce licence (~$22,000 – $100,000+/year depending on GMV tier) is paid directly to Adobe. We can supply pricing letters for procurement. Adobe Commerce B2B module is included free with the licence.

Yes, but expect a significant build cost. Open Source ships the core e-commerce engine but no B2B features — so you’re building (or buying) custom modules for companies + roles, quote workflow, customer-specific pricing, requisition lists, payment on account, and shared catalogues. Community modules exist (Mageplaza, Amasty, MGS) but they patchwork rather than integrate as one cohesive B2B model.

Our recommendation: if your annual B2B GMV is > $1M, Adobe Commerce pays for itself in fewer custom modules, faster build, fewer integration bugs, and Adobe support. Below $1M, an Open Source + 3–4 well-chosen B2B modules can work — we audit both routes in the discovery call.

The Adobe Commerce B2B quote workflow:

1. Buyer adds products to cart, hits "Request a quote" instead of "Checkout".
2. Buyer adds notes (volume, custom terms, project deadline).
3. Quote routes to assigned sales rep in the admin.
4. Sales rep adjusts prices, adds discounts, attaches PDF, replies in-thread.
5. Buyer reviews — accepts, counter-proposes, or declines.
6. On accept, quote converts to a regular order with the negotiated prices.
7. Custom email templates fire at each stage (request received, quote sent, accepted, expired).

We customise the routing matrix, approval logic, expiry rules, and PDF templates to match your sales process. Account-rep dashboards (custom built) give sales managers a pipeline view.

Yes — ERP integration is the single most common Magento B2B project. We’ve shipped connectors to:

• SAP (S/4HANA, ECC, Business One)
• NetSuite (SuiteCloud, RESTlets)
• Microsoft Dynamics (365 Business Central, NAV, AX)
• Sage (50, 100, 200, X3, Intacct)
• Acumatica
• Odoo
• Pimcore (PIM)

Sync points typically: products + stock + customer-specific prices (ERP → Magento, real-time or every 15 min), customers + companies (bidirectional), orders + invoices (Magento → ERP). Protocols: REST, SOAP, EDI (X12, EDIFACT), SFTP. We use queue-backed connectors so a slow ERP doesn’t take down the storefront.

Adobe Commerce B2B supports four overlapping pricing strategies:

• Customer groups — e.g. "Tier-A Distributors" get 30% off list across all SKUs.
• Tier prices — volume breaks (buy 10+ for $9.50, buy 100+ for $8.75).
• Contract pricing — customer-specific or company-specific overrides per SKU (Acme Corp buys SKU-123 at exactly $7.20, regardless of group/tier).
• Catalogue rules — conditional discounts ("15% off if customer is in Texas and SKU is in category X").

Prices can be hidden behind login (visitors see "Login for price"), and synced from ERP in real-time. We build the rule matrix in the discovery call so it matches your existing pricing logic without surprises.

Yes — this is the Companies feature in Adobe Commerce B2B. One company account contains many buyer users with role-based permissions:

• Company admin — manages buyers, sees all orders, edits company info.
• Purchaser — can place orders up to a limit; orders above route to approver.
• Approver — reviews and approves pending orders.
• Finance — sees invoices, statements, credit balance only.
• Custom roles — you define new roles with granular permissions (view-only, view-and-quote, view-and-order, view-and-approve, etc.).

Approval workflows trigger by order value, SKU, category, payment method, or any combination. We’ve built 5-step approval chains for enterprise procurement and simple 1-step approvals for small distributors.

Adobe Commerce B2B ships Payment on Account with built-in credit-limit enforcement:

• Each company gets a credit limit ($X) and current balance (running total of unpaid invoices).
• At checkout, the order total is checked against (credit limit − current balance). If over, the order is blocked or routed to an approver.
• Buyers see their account statement (open invoices, due dates, balance) in their dashboard.
• Net 30 / Net 60 / Net 90 terms are configurable per company.

For dunning + payment collection we integrate with Stripe Invoicing, Authorize.net Recurring, GoCardless, or your existing AR system. Auto-invoice + auto-statement generation runs nightly. We’ve also built custom workflows for lockbox + ACH + wire reconciliation against open invoices.

It depends on what you’re building. Magento ships a full GraphQL B2B API covering companies, quotes, requisition lists, shared catalogues, and customer-specific prices. Use cases that justify headless:

• Sales-rep mobile app — reps quote, order, and track orders on the road.
• Buyer portal app — large customers want a branded ordering app.
• Dealer / distributor portals — embedded in their existing systems.
• Composable commerce — Magento as commerce engine, separate frontend (Next.js, Nuxt, Hyvä).

Headless adds complexity (separate frontend deploy, GraphQL caching, auth flows). For 70% of B2B stores, the Hyvä theme on top of Adobe Commerce hits the same speed targets without the headless overhead. We assess both routes in the audit.

Honest comparison:

• Magento / Adobe Commerce B2B — the most flexible. Companies, multi-tier pricing, quote workflow, ERP integration, custom approval matrices, headless GraphQL. Best for $1M+ GMV B2B with custom workflows or ERP-heavy stacks.
• Shopify Plus B2B — fastest to launch, B2B added in 2023 (companies, catalogue access, payment terms). Limited customisation — you live within Shopify’s data model. Best for < $5M GMV B2B with simple workflows and no heavy ERP.
• BigCommerce B2B Edition (powered by B2B Ninja / BundleB2B) — mid-ground. Quote workflow, customer groups, price lists. Less mature than Magento for complex flows.

If your B2B has 5+ approval roles, custom pricing logic, an ERP, or 5,000+ SKUs, Magento wins on TCO and capability. If you’re a small distributor wanting to launch in 30 days, Shopify Plus B2B is faster. We’re happy to recommend the route that actually fits your business — even if it isn’t Magento.

Buy when an existing Marketplace extension covers 80%+ of your need with reasonable config — it’s nearly always cheaper than custom and someone else maintains the upgrade path. Build custom when (a) no extension solves the problem, (b) you need it to integrate tightly with proprietary systems (ERP, PIM, custom checkout flows), (c) you’re selling the extension itself, or (d) the closest off-the-shelf extension would need so much customisation it’s cheaper to start clean. Our spec audit ($499) gives you the buy-vs-build call in writing before you commit.

Three fixed-price tiers, no per-hour surprises:

• Spec Audit: $499 — 1–2 days, just the spec, you can take it to any developer
• Standard Extension: $2,999 — 3–6 weeks, single-purpose extension with Hyvä + Luma support, MFTF tests, docs, GitHub repo
• Marketplace-Ready: $9,999 — 6–10 weeks, includes Adobe Marketplace submission package, EQP compliance, listing copy, screenshots, demo video, customer-support runbook

If your extension is unusually complex (multi-store ERP integration, custom payment gateway, headless GraphQL surface), we’ll quote per spec. No surprise invoices.

Typical timelines:

• Spec Audit: 1–2 days from kick-off call to delivered spec doc
• Standard Extension: 3–6 weeks — week 1 spec sign-off, weeks 2–5 build + tests, week 6 docs + handover
• Marketplace-Ready: 6–10 weeks — standard build plus Marketplace submission, EQP fixes, listing assets, demo video

Add 1–2 weeks if you want a UAT cycle with real users before sign-off.

Yes — every extension we ship includes a Hyvä-compat module by default. We use the standard Hyvä compatibility module pattern (separate view/frontend directories under Hyva_*Compat) so the extension renders correctly on both Luma stores and Hyvä storefronts without code duplication. If you only need one frontend, we’ll happily skip the other and discount accordingly — tell us in the booking form.

Yes, by design. We use data:patch over InstallSchema, di.xml over class rewrites, plugins / observers over preference, and declarative schema for any DB changes. None of those rely on internal Magento implementation details — they’re the documented extensibility surface. The Standard Extension tier includes 14 days of bug-fix coverage; Marketplace-Ready includes 12 months of upgrade compatibility (we test on each minor + patch release and ship a compat patch if anything breaks).

Yes — that’s the Marketplace-Ready tier ($9,999). It includes: full submission package (technical + marketing), Mage Extension Quality Program (EQP) compliance audit, listing copy, screenshots (admin + frontend), 60–90 second demo video, support runbook, and the actual submission to Adobe’s portal. 100% pass rate to date — every extension we’ve submitted has cleared Adobe’s code review on the first attempt because we run the EQP checks ourselves before submission.

You do, fully. When you pay us to build an extension, the source code is yours under a written assignment-of-IP clause in the contract. You can put it on your own GitHub, sell it, modify it, take it to another developer, open-source it — anything. We retain the right to reuse generic patterns (e.g. our boilerplate module skeleton, our PHPUnit test scaffolding) but never anything specific to your business logic, data, or branding.

Yes. Every extension ships with:

• MFTF (Magento Functional Testing Framework) tests for admin + frontend user flows
• PHPUnit unit tests for business logic, with fixtures for test data
• phpcs --standard=Magento2 + PHPStan level 6 linting on every commit
• GitHub Actions CI running the full suite on every push

We commit to green CI before any merge. The next developer picking up the extension can refactor with confidence because the tests catch regressions.

Yes, two docs per extension:

• User guide (admin-facing) — how a store admin installs, configures, uses the extension. Screenshots, troubleshooting tips, common pitfalls.
• Dev guide (engineer-facing) — architecture, extension points, how to override, how to add custom logic on top, API reference.

Both are markdown in the repo (so version-controlled), plus a rendered HTML version. We write docs the way we wish vendors did when we’re consuming their extensions — thorough, honest, and answering the questions you’d actually ask.

Yes, hugely. Quick rule of thumb:

• Plugin — intercepts a public method (before/around/after). Magento’s preferred extensibility mechanism. Multiple plugins can stack cleanly. Use this first.
• Observer — reacts to dispatched events. Use when Magento explicitly fires an event for what you need.
• Preference (rewrite) — replaces a class entirely. Last resort: only one preference per class wins, breaks other modules trying to do the same. We avoid this unless absolutely necessary.

Bad extensions abuse rewrites; good ones use plugins + observers. We default to plugins because they survive Magento upgrades.

Yes — 60+ open-source Magento 2 extensions on GitHub at github.com/mage2sk and github.com/mage2kishan. Real working code for SEO modules, B2B helpers, admin UX improvements, payment integrations, frontend widgets, and more. Browse the source, run the tests, read the docs — that’s the standard you can expect on your custom build. Several have been adopted by the Magento community and run on production stores.

All tiers include 14 days of bug-fix coverage after handover — anything broken because of our build gets fixed at no extra charge. After that, two options: (1) per-incident support at our standard hourly rate (handy for one-off questions), or (2) maintenance retainer ($299–$999/month depending on extension complexity) covering Magento minor + major version compat updates, security patch verification, and minor feature requests. Marketplace-Ready tier includes 12 months of upgrade compatibility built-in.

My standard hourly rate is $65–$95 USD/hr depending on engagement type:

• Hourly retainer (10+ hrs/week): $65/hr
• Ad-hoc hourly: $85/hr
• Emergency / fire-fighting: $95/hr
• Consulting / advisory call: $150/hr (90-min minimum)

Most clients prefer fixed-price projects ($499–$50k+ depending on scope) where I commit to an outcome rather than billing time. Quotes always include the scope, deliverables, and milestones in writing — you don’t pay until we both sign.

Fixed-price when scope is clear: a Magento upgrade, a Hyvä migration, a specific extension build, a performance audit. You know exactly what you’ll get and pay. I take the risk on time overruns.

Hourly retainer when scope is fluid: ongoing maintenance, exploratory R&D, integrations where requirements shift weekly, multi-month builds where priorities re-shuffle. Lower rate, you keep flexibility, no per-task quoting friction.

If unsure, start with a fixed-price audit ($299–$999) — that gives me the data to recommend the right structure.

Typical lead time is 1–3 weeks. Booked-out slots show on the page hero. For emergencies (broken checkout, security incident, post-deploy regression), I can usually start same-day on a 4-hour fire-fighting block at the emergency rate.

I run my calendar in 2-week sprint cycles. If your project needs continuous attention, the hourly retainer model gives you guaranteed weekly hours rather than queuing behind fixed-price work.

Based in Ahmedabad, India (IST, UTC+5:30). My core hours are 9 AM – 7 PM IST, but I shift 2–4 hrs/day for clients in EU/UK/US timezones. Calls are scheduled in your timezone, never mine.

Time-zone overlap with the major paying-client regions: UK 4–6 hrs/day, EU 4–6 hrs/day, US East Coast 2–3 hrs/day, US West Coast 1–2 hrs/day, AU 5–6 hrs/day. For US-only async work I lean on Loom + written briefs — works better than 6 AM standups.

Yes — I sign your NDA as standard, before any commercial discussion. I also have a short mutual NDA template if you don’t have one.

Contracts are simple: a one-page Statement of Work with scope, deliverables, milestones, payment schedule, IP ownership (yours), and a 14-day post-launch bug-fix clause. Everything in writing, signed digitally (DocuSign or PandaDoc). For projects > $25k I use a 30/40/30 milestone payment split: 30% upfront, 40% mid-build, 30% on launch.

You do. 100%, no exceptions. Every line of code I write under contract is your property — full IP transfer in the SoW. You get the GitHub repo, the deploy keys, the documentation, the database, the CI/CD config. I don’t hold infrastructure hostage.

The only exception: any open-source extension I publish under mage2sk/* or mage2kishan/* stays open-source (MIT or AGPL). If you commission custom work that I think the community would benefit from, I’ll ask permission before open-sourcing — never assume.

Honesty: I turn down ~30% of incoming briefs. Common reasons:

• Magento 1.x maintenance. The platform is EOL since 2020. I’ll happily migrate you to M2.4.9, but I won’t patch M1 indefinitely.
• "Just clone Shopify" briefs. If the right answer is Shopify, I’ll tell you so — but I won’t pretend Magento is the right tool when it isn’t.
• Pure design work. I write code, not Figma files. I’ll partner with your designer or recommend one.
• Adult / gambling / regulated grey-area. Personal preference, no judgment.
• Sub-$500 budgets for non-trivial work. The math doesn’t work and I can’t do good work at that price.

I’m the founder of Panth Infotech — a 24-person team in Ahmedabad. For most engagements I’m your direct point of contact and lead engineer. For larger builds (B2B, multi-store, M1→M2 migrations) I bring in 1–3 senior team members under my management. You always have one person to email.

This is the hybrid model: solo-developer accountability with team-grade delivery capacity. Smaller projects ($499–$5k) are usually 100% me; bigger builds ($5k+) flex to 2–4 hands as needed. The SoW always names who’s on the project.

Multiple options:

• Wire transfer / SWIFT — preferred for > $5k
• Stripe / PayPal — credit card / direct debit, 3–4% fee passed through
• Wise (Transferwise) — best FX for EU/UK clients, no markup
• Razorpay — for Indian clients, GST invoice provided
• USDC / crypto — for international clients who prefer it

Invoices in USD by default, but I can quote in GBP / EUR / AUD / INR if you prefer. Net-15 payment terms standard.

Yes — happy to put you in touch with 2–3 past clients in your industry / similar project size. Send your brief through the form, I’ll match you with the most relevant references at the proposal stage.

Public references already on the site: 42 testimonials (5.0 average), Upwork profile (Top Rated Plus, 100% job success), Magento Stack Exchange (Top 3% contributor), GitHub (60+ open-source extensions).

It depends on your team and traffic profile. ACC is worth it when (a) you don’t want to manage servers, Fastly, New Relic, deploy pipelines, and Adobe-tier patching, (b) your traffic is variable and elastic scaling matters, or (c) you need the bundled support & SLA. It’s not worth it when (a) your team already runs DevOps fluently, (b) traffic is small and steady so a $50/mo VPS would do, or (c) you want full control over kernel-level optimisations. Most stores in $1k-$15k/mo MRR profit from ACC; below that, self-hosted on Hetzner/AWS is cheaper.

The four biggest wins, in order:

• Right-size your environments — most ACC stores are 2-3× oversized on RAM & CPU. Adobe doesn’t volunteer this analysis.
• Fix Fastly cache-hit rate — moving from 60% to 90%+ cache-hit rate cuts origin bandwidth 10× and origin compute alongside.
• Audit add-ons — paid add-ons (extra environments, BlackHat, B2B, etc.) often carry beyond their useful life.
• Optimise asset storage — old media library, unused product images, orphaned PDFs — all billed monthly.

A 90-day audit typically uncovers 30-50% potential savings on the monthly invoice.

Common culprits:

• Static content compilation runs on every deploy — fix with SCD_ON_DEMAND_IN_PRODUCTION or skip-static-content build hooks.
• Composer install fetches from scratch — fix with cached composer + COMPOSER_AUTH proper setup.
• Deploy hooks run sequentially when they could parallelise.
• Database upgrade scripts on every deploy — fix with skip patches that haven’t changed.

Tuned correctly, ACC deploys go from 25-40 minutes to 3-5 minutes. We do this on every Standard Cloud Migration project.

ECE-Tools (Magento\CloudPatches + magento/ece-tools composer package) is the deploy/build orchestrator for ACC. It runs your .magento.app.yaml + .magento.env.yaml hooks, generates static content, applies Adobe’s cloud patches, and configures redis/varnish/fastly. Tuning ECE-Tools is the difference between a 5-minute and a 40-minute deploy. Most stores never look at it. We do.

The default Fastly config that ships with ACC is generic — it’s a starting point, not the destination. Real tuning involves:

• Custom VCL for query-param normalisation, geo-routing, A/B-test splitting
• Image optimisation edge rules (WebP/AVIF on the fly)
• ESI fragments for personalised blocks (cart, customer name)
• Proper Surrogate-Key tagging so cache-purge is targeted not nuclear
• Bot-protection rules + rate limits

Done right, you go from 60% to 90%+ cache-hit rate, which cuts origin compute by 10× and bandwidth costs alongside.

Yes, with proper planning. The pattern: (1) spin up ACC Integration with a full database dump from your current production, (2) validate functionality on Integration + Staging, (3) set up real-time DB replication from old → new for the cutover window, (4) off-peak DNS swap with TTL pre-lowered to 60s, (5) keep old system warm for 72 hours as roll-back. Total downtime: typically 0-30 seconds during the DNS flip. Order data flows to new system immediately.

ACC Starter: Single AWS region, shared infrastructure, no Fastly Image Optimizer, max 4 envs, minimal SLA. Best for stores under $1M GMV. ACC Pro: Dedicated 3-node AWS cluster, Fastly Image Optimizer included, unlimited envs, 99.99% SLA, dedicated support. Best for stores over $1M GMV or with B2B / multi-region needs. Pro is roughly 4-6× Starter pricing but the SLA + Image Optimizer alone often justify it for serious stores.

ACC enforces a 3-tier git branch strategy by design:

• Integration: ephemeral feature branches per developer/PR. Each push triggers a deploy. Used for PR review.
• Staging: mirrors Production data (sanitised) and infrastructure. UAT happens here.
• Production: live store. Only promotions from Staging are allowed.

Done right, each branch has its own data-bridge so a Staging deploy can be tested against real-shape data without touching Production. We set this up properly on every project.

Yes, fully — ACC is just Magento 2 on AWS with managed orchestration. You ship custom modules via composer + git just like self-hosted. The constraints: (a) no kernel-level access (can’t install OS packages), (b) PHP extensions are restricted to Adobe’s supported list, (c) cron jobs run on Adobe’s schedule infrastructure. For 95% of stores, none of this matters. The remaining 5% are typically B2B with custom payment processors or ERP middleware — those need careful pre-project audit to confirm fit.

ACC backs up your DB + media every 6 hours and retains 7 days by default (longer on Pro). However, vendor backups are necessary but not sufficient — for real DR you also want: (a) off-cloud backup copies (S3 to a different account), (b) tested restore runbooks (most teams have backups but never tested restore), (c) point-in-time recovery for transactional data, (d) annual DR drill. Standard Cloud Migration includes setting all of this up; Enterprise includes the DR drill.

Less than you think. ACC is just Magento 2 + AWS + Fastly + New Relic. Your codebase is portable — same composer.json works on a self-hosted server. The only ACC-specific bits are .magento.app.yaml + .magento.env.yaml + ECE-Tools dependency, all of which are open-source. Realistic exit time: 4-6 weeks to migrate from ACC back to self-hosted, vs 8-12 weeks the other way (because you’d need to set up the hosting from scratch). So lock-in is real but recoverable — much less sticky than e.g. Shopify.

Adobe doesn’t publish list prices, but the formula is roughly: base licence (tied to your GMV tier — typically $40k-$200k/year) + infrastructure (compute, bandwidth, storage — typically $1k-$15k/month) + add-ons (extra environments, B2B module, AI services, etc.). Real total: Starter stores pay $5k-$30k/year all-in, Pro stores pay $50k-$300k/year+. The bill grows quickly with traffic and bad caching — which is why our cost-optimisation pass typically pays for itself within 2-3 months from invoice savings alone.

Genuinely free. No catch, no upsell, no “book a call to unlock the rest”.

The reason I do it: I’ve been on Upwork since 2018, hit Top Rated Plus, and I see a lot of strong freelancers leaving money on the table because of fixable profile mistakes (weak hero headlines, generic overview copy, mis-tagged niches). Helping a few each month is enjoyable, costs me an hour, and occasionally turns into a referral or a collab — that’s the only ROI I’m optimising for.

What I won’t do: rewrite your entire profile for you, ghostwrite proposals, or run your account. The audit is opinionated guidance you implement yourself.

A written report (Google Doc or Notion link, your pick) covering:

• Hero headline rewrite — the 70-char headline above your photo. I draft 2–3 alternatives in the niche+outcome+proof pattern.
• Overview opening — the first 2 paragraphs that show in search previews. Restructured for skim-reading.
• Portfolio order + gaps — which items to demote, which titles to rewrite, what missing case studies would help.
• Skills + Specialised Profile — which 5–8 skill tags actually move search ranking for your niche, and whether you should add a Specialised Profile.
• Hourly rate — whether to raise, hold, add a project minimum, or bracket your services.
• One sample proposal — my current proposal template, customised to your niche.

~1,500 words. Reads in 10 minutes, takes ~2 hours to apply.

24 business hours from when you submit. Sometimes faster — if you submit Tuesday morning India time, you’ll usually have it by Tuesday evening. If you submit Friday evening, it lands Monday.

I cap intake at ~5 reviews per week so I can keep that promise. If the queue is full, the form will say so and you can choose to be notified for the next slot.

The audit framework (hero / overview / portfolio / skills / rate / proposals) applies to every niche on Upwork. The patterns I’ve seen working in 2025: niche-specific hero, proof-driven overview, results-as-titles portfolio, narrow Specialised Profile, premium-anchored rate.

What changes by niche is the specifics. For design / UX I’ll talk about case-study cover images and Figma links; for writing I’ll talk about portfolio gating and sample variety; for AI / ML I’ll talk about LLM-stack tags and recency signals. I’ve audited ~80 profiles across web dev, design, writing, marketing, data, AI, and admin — happy to share niche-specific examples in the audit.

Especially useful. New freelancers usually struggle with two things: a hero/overview that doesn’t convert because it sounds like every other beginner, and applying to wrong-fit jobs that hurt JSS once they win.

For new profiles I focus on: positioning narrow enough to win the first 3 jobs, hero/overview that signals expertise without inflating it, portfolio fillers (spec work / pro-bono / personal projects) that outperform "I’m new" disclaimers, and the proposal pattern that beats the “I have 5 years of experience” openers most beginners use.

Partially. JSS is driven by client outcomes (private feedback, contract closure mode, dispute history) more than profile copy — so I can’t directly raise it. But the audit can stop the bleeding by:

• Identifying which job categories you’re winning that you shouldn’t (wrong-fit jobs are the #1 JSS killer)
• Tightening niche so the next 5 contracts are higher-fit
• Adjusting rate so you attract clients who close contracts cleanly (very-low-rate clients dispute more)
• Cleaning up portfolio so the right clients self-select in

If your JSS dropped from a single bad client, JSS will drift back up over 6 contracts even without changes. The audit is for systemic fixes, not bandage on a one-off.

Yes. I won’t suggest anything that violates Upwork’s ToS — no fake reviews, no off-platform poaching language, no rate-undercutting tactics, no “suspended-account workaround”. The advice is everything you can do within the platform: better positioning, sharper copy, smarter proposal allocation, sustainable rate growth.

I’ve been on the platform for 8 years without a single ToS warning, so the framework is built around what works long-term, not what’s trending in shady Telegram groups.

I draft example rewrites for the hero headline (2–3 alternatives) and the overview opening paragraph — enough that you can copy/adapt directly. Full overview rewrites, portfolio item rewrites, and per-niche specialised-profile copy are out of scope for the free tier (otherwise I’d burn 6 hours per audit).

If you want a hands-on rewrite of the whole profile + 3 proposal templates, that’s a paid engagement (~$299 fixed price). But ~80% of freelancers who get the free audit can implement the changes themselves with what’s in the report.

No. I read it, write the audit, send it back. Nothing is published, screenshot, shared with third parties, or fed into any LLM. The form data lives on this site (encrypted at rest), the audit doc is private to your link, and I delete the working notes after sending.

If you’d like to be quoted later as a "this audit helped me" testimonial, that’s opt-in via a separate email — never automatic.

Realistic timeline:

• Search visibility: 7–14 days for skill / niche changes to re-index in Upwork search
• Invite volume: 2–3 weeks once the algorithm catches up
• Proposal reply rate: immediate (next batch of proposals already uses the new template)
• Rate raises: 1–2 contracts to hold the new rate without losing close-rate
• JSS recovery: 4–6 closed contracts

Most freelancers see invite volume change within 30 days. Send me a screenshot at the 30-day mark — I genuinely like seeing the data.

The framework (positioning, hero, overview, portfolio, niche, rate) is platform-agnostic. The specifics are Upwork-specific: skill tags, Specialised Profiles, Top Rated mechanics, Connect spend, JSS, Boost-Profile.

For Toptal the audit pattern shifts to interview-prep + portfolio-presentation. For Fiverr it’s gigs + packages + tags. For Contra it’s services + spotlight project. I focus the free audit on Upwork specifically because that’s where I have first-hand sustained data — sticking to one platform makes the advice load-bearing instead of generic.

Skip if any of these apply:

• You’re looking for someone to run your account (apply on your behalf, ghost-interview, bid spam) — that’s a ToS violation and I won’t do it.
• You want a guarantee of N invites or X% rate raise — the audit gives you mechanics, not guarantees. Outcomes depend on your skill, market timing, and execution.
• You want to be told your profile is great without changes. The audit is opinionated and direct — if I think the hero is broken, I’ll say so.
• You’re on Upwork casually with no income goal — the audit assumes you want to be selected for higher-paying work.

Honest answer: about 10% of Magento stores benefit from headless. The shortlist:

• Mobile traffic > 60% AND mobile conversion lagging desktop by 30%+
• You want a real PWA (offline / add-to-homescreen / push notifications) or native iOS/Android app sharing the storefront codebase
• Multi-region with 4+ storefronts and the marketing team wants per-region content control on the frontend
• You have an in-house Node/React/Vue team already — the infra burden is acceptable

For everyone else — speed problems, conversion lifts, Lighthouse scores — Hyvä gets you 90% of the wins at 20% of the cost. We turn down 9 in 10 headless inquiries on this basis.

Hyvä is the right answer for ~90% of Magento stores. It ships Lighthouse 95+, Core Web Vitals green by default, conversion lifts of 8–25%, and uses your existing Magento infrastructure. Project cost: $499–$999. Timeline: 2–6 weeks.

Headless is the right answer when you specifically need: real PWA (offline, install-to-homescreen, push), native iOS/Android sharing storefront code, or a frontend team that wants to ship 10x faster than Magento’s release cadence allows. Project cost: $7,999–$50k+. Timeline: 8–24 weeks. Plus ongoing Node infra ($100–$500/month).

Our headless audit ($999) gives you a written go / no-go answer. Often the recommendation is “just do Hyvä”.

Each shines in a specific situation:

• PWA Studio (React) — Adobe’s official path. Best if you’re on Adobe Commerce + want vendor support + already have React expertise. Heaviest infra burden: separate Node deployment, build pipeline, separate CDN.
• Vue Storefront (Vue 3 / Nuxt 3) — Best if your team already writes Vue. Strong plugin ecosystem (Algolia, Stripe, Klarna). Cleaner DX than PWA Studio. Still needs Node infra.
• Hyvä-headless (Astro / Next.js + Hyvä Storefront API) — The pragmatic middle path. Get Hyvä speed, headless flexibility, but with edge-rendered HTML so SEO is bulletproof. Lower infra burden than PWA Studio. Best for content-heavy stores.

The audit picks the right one for your specific stack.

Real-world ranges (we publish honest pricing):

• Headless audit — $999 fixed. 60-min call + GraphQL coverage assessment + written report + infra cost estimate.
• Standard headless build — $7,999 fixed. 8–12 weeks. Frontend, GraphQL Mesh, up to 10 custom resolvers, payment gateways, service worker, blue-green deploy.
• Enterprise headless — Custom (typically $25k–$80k). 12–24 weeks. Multi-region, B2B, native iOS/Android via React Native or Capacitor, custom checkout.

Plus ongoing infra: Vercel/Netlify $20–$500/month + Magento backend hosting (unchanged). Be wary of agencies quoting $150k+ — that’s usually scope creep, not value.

Yes — if you SSR (server-side render) the storefront. Static-site generation (SSG) or SSR via Next.js / Nuxt 3 / Astro produces fully-rendered HTML at the edge. Googlebot sees the same HTML a user does. Lighthouse scores typically improve (LCP from 2.5s → 0.8s on a good edge deploy).

The dangers:

• Pure CSR (client-side rendering only) is a SEO death warrant. Don’t.
• URL drift — if the new frontend changes URL structure, you lose rankings. We do a pre-migration crawl + 301 redirect map.
• Hreflang / canonicals must be re-implemented on the frontend. Magento’s built-in tags don’t carry over.

Every headless build we ship includes a Screaming Frog pre/post crawl + URL parity report.

For 80% of storefront features — yes. Adobe’s GraphQL covers products, categories, cart, checkout, customer, orders, search, CMS pages, URL rewrites, store config. The 20% gap typically:

• Custom EAV attributes (we add resolvers)
• B2B queries (companies, quotes, requisition lists — partial in Adobe Commerce)
• Custom checkout fields / extension data
• Third-party extension data (loyalty, reviews from non-native sources, custom recommendations)

Our audit catalogues every gap on your store and quotes the resolver work. GraphQL Mesh stitches Magento’s GraphQL with Algolia / contentful / your ERP into one schema. We document the full schema as part of every build.

You have three options:

• Build native headless checkout — Most expensive ($3k–$15k extra). Full UX control. Required for B2B / multi-step / saved-quote flows.
• Hand off to Magento checkout via SSO — Cheapest. Cart on headless, “Checkout” button redirects to Magento Hyvä Checkout (or Luma). Ugly URL transition but works in days, not weeks.
• Embed Magento checkout in iframe — Don’t. SEO mess, payment-gateway PCI complications.

For most $7,999 builds we recommend hand-off to Hyvä Checkout — it’s already 1-page and <1s, which beats most custom headless checkouts. Build native only if you’re in the Enterprise tier.

Yes, the frontend lives separately:

• Vercel — $20/month Pro tier covers most stores. Best DX. Edge runtime + automatic SSG.
• Netlify — Similar pricing. Good if you want Netlify Functions for edge resolvers.
• Self-host Node — If you have an internal ops team. Add ~$50–$200/month per region for the Node app + CDN.

Your Magento backend stays where it is. No changes needed. Magento becomes a GraphQL API + admin panel + checkout endpoint — nothing else changes server-side. We can warm-up edge caches and pre-render top-200 pages so your origin server load actually drops after going headless.

Yes — this is the strongest case for going headless.

PWA: We ship service worker + manifest + push notifications + offline support on every headless build. Users can install your store to their home screen with one tap. Looks like a native app, no app-store review.

Native iOS / Android: Two paths in our Enterprise tier:

• React Native — Share GraphQL queries + business logic with the web frontend. Separate UI components. ~30% code reuse.
• Capacitor — Wrap the PWA into a native shell. ~80% code reuse. Push notifications, deep linking, app-store distribution. Cheapest path to “real” iOS/Android.

Both ship to Apple App Store + Google Play. Apple takes ~7 business days for first review.

Headless makes multi-store easier in some ways, harder in others. The frontend can:

• Route per locale via Next.js / Nuxt i18n routing (`/en-gb`, `/de-de` etc.)
• Pull Magento store_view_id per route — clean separation
• Mix CMS content from a headless CMS (Contentful / Sanity) per region

The complications:

• Hreflang on the frontend (we handle)
• Multi-currency display needs per-route price formatting
• Per-region payment methods need conditional checkout logic (Klarna in DE, Razorpay in IN, etc.)
• Per-region inventory requires Magento MSI configured + GraphQL queries that respect source-stock per region

Our Enterprise tier ships full multi-region orchestration. 8–12 weeks typical for 4–6 stores.

Yes — this is one of the strongest cases for headless. Adobe Commerce B2B exposes most features via GraphQL: companies, company users, quote workflow (with limits), requisition lists, customer-specific pricing, shared catalogues.

The gaps you’ll fill with custom resolvers:

• Some quote-state transitions (approve / decline / counter)
• Net-30 / credit-limit balance display
• ERP-pulled tier-pricing
• Bulk CSV order upload

We’ve shipped 4 headless B2B builds (Adobe Commerce + Vue Storefront / Next.js). Typical timeline 12–16 weeks. The biggest win clients see: B2B buyers love a clean modern UX vs Magento’s default Luma B2B experience, which feels distinctly 2010s. Conversion uplift on quote-to-order conversion: typically 15–30%.

Real talk — this is where most agencies undersell the cost. Going headless adds:

• Two codebases to maintain — Magento backend AND headless frontend. Each has its own dependency tree, security patches, deployment pipeline.
• Frontend developer skillset — You need a React / Vue / Astro engineer on retainer. Magento PHP devs can’t do this work.
• GraphQL schema drift — Each Magento upgrade may change GraphQL responses. We document a regression-test suite as part of the build.
• Service worker bugs — Stale-while-revalidate logic gets tricky for cart / checkout. Plan for ~2–4 hours/month of frontend tuning.

Our retainer (~$999–$2,499/month depending on size) covers all of this. If you don’t have a frontend dev on staff and don’t want a retainer, headless is the wrong call — stay on Hyvä.

Magento handles 50k+ SKUs cleanly when three things are tuned correctly: EAV indexing, Elasticsearch, and Hyvä. Without those, default Luma + MariaDB will start choking around 30k SKUs — category pages take 2–5 seconds, layered nav lags 1–2 seconds per filter click.

• EAV index: schedule the catalog_product_attribute + catalog_product_price + catalog_category_product indexers to "Update on Schedule" with a cron run every 1 minute. Avoid "Update on Save" at 50k+ — admin saves stall.
• Elasticsearch / OpenSearch: required from Magento 2.4+. Tune refresh_interval to 30s, allocate 4–8GB RAM. Re-index rate target: 50k SKUs in <10 minutes.
• Hyvä theme: replaces Luma’s 3MB+ JS with ~150kB Tailwind/Alpine. Catalog list-view renders 60% faster. INP drops from 280ms to 80ms on a 50k-SKU store.
• Hosting floor: 8 vCPU / 16GB RAM / NVMe SSD, Redis for cache + sessions, dedicated MariaDB or Aurora. Cloudways "Pro" plan or Hetzner CX52 minimum.

With those four in place, a 50k-SKU electronics store hits Lighthouse 90+ on category and product pages. I’ve shipped one with 78k SKUs that holds 95+ Lighthouse mobile.

Both work. Different shapes of fit:

Akeneo: dedicated PIM. Cleaner UX for product managers, attribute-set workflow is excellent, multi-language is mature. The Akeneo Magento Connector (official, paid) ships with attribute mapping, channel publishing, image syndication, and incremental sync. Setup: 2–4 weeks. Annual licence: $25k–$120k depending on SKU count + user seats. Pick Akeneo if: you have dedicated catalog managers, >5 product categories with different attribute schemas, and you want a tool built specifically for product data.

Pimcore: PIM + DAM + MDM in one platform. More flexible (you can model anything — products, customers, orders), open-source core with paid enterprise edition. The Pimcore Magento Bridge is community-maintained. Setup: 4–8 weeks (more flexibility = more configuration). Annual cost: free OSS + dev time, or $30k–$80k for enterprise edition. Pick Pimcore if: you also need a DAM (digital asset management for spec sheets, datasheets, certifications), or you want a single platform for product + customer master data.

For pure product data with strong workflow needs, Akeneo wins. For combined PIM + DAM at electronics distributors with thousands of datasheet PDFs, Pimcore wins. Both integrate cleanly with Magento — integrator skill matters more than the tool.

Magento MSI (Multi-Source Inventory, native since 2.3) handles N warehouses with a priority-and-rule-based algorithm:

1. Sources: define each warehouse + drop-ship vendor as a "source" with location coordinates, contact, enabled/disabled flag.
2. Stocks: define which sources serve which sales channels. E.g. EU stock = "Berlin warehouse + Rotterdam warehouse + drop-ship vendor X". US stock = "Dallas warehouse + drop-ship vendor Y".
3. Reservations: when an order is placed, MSI reserves inventory logically (without decrementing source qty) until the order ships. This prevents oversells across concurrent orders.
4. Source selection algorithm (SSA): at fulfillment time, MSI picks the source(s) by priority (lowest priority number wins), distance from shipping address, and stock-availability rules. Native algorithms: "priority" (use the highest-priority source first), "distance" (use closest source). Custom algorithm via plugin: weighted score — e.g. Dallas first if >30 SKUs in stock, drop-ship vendor only if Dallas + Reno are out.

Common gotchas: (1) SSA is slow on category pages with 50k+ products — use cataloginventory_stock_status indexer with "Update on Schedule"; (2) drop-ship vendors should be flagged as "use stock from external source" so qty doesn’t drift; (3) partial-shipment splits work but require checkout customization to show "ships from 2 warehouses" to the customer.

Three real options at different price points:

Channel Advisor (now Rithum): enterprise marketplace integrator. Magento extension, syncs inventory + orders + listings to Amazon, eBay, Walmart, Newegg, Wayfair, Google Shopping. Strengths: bulletproof at $100M+ GMV, mature dispute / reconciliation tools, repricer included. Weakness: enterprise pricing — $30k–$200k/yr depending on GMV. Pick at >$10M marketplace GMV.

Codisto (now Shopify-owned but still has Magento connector): mid-market. Real-time inventory + order sync, listing builder, decent multi-region support. $200–$2,500/mo depending on plan + SKU count. Weakness: Newegg + Walmart support is thinner than Amazon/eBay. Pick at $1M–$10M marketplace GMV.

M2E Pro (free + paid editions): Magento-native open-source extension. Free for Amazon/eBay basic, $500–$2k/yr for advanced features. Strengths: deep Magento integration, no per-SKU fees. Weakness: needs more in-house ops attention than the SaaS tools. Pick at <$1M marketplace GMV with in-house Magento expertise.

Custom (direct API): build directly against Amazon SP-API + eBay API. Justified only at >$50M marketplace GMV with weird requirements (multi-account, complex SKU mapping, custom repricer). Build cost: $80k–$200k. Don’t pick this lightly.

This is Magento’s home-court advantage. One backend, two storefronts (or one storefront with logged-in B2B switching), fully separated pricing and catalogs.

• Customer groups: create "Wholesale Tier 1", "Wholesale Tier 2", "Distributor", "Reseller" customer groups. Each group gets its own price tier per SKU.
• Shared catalogs (Adobe Commerce B2B): assign different SKU subsets to different customer groups. E.g. distributors see professional-only SKUs that B2C never sees.
• Companies + buyer roles: B2B customers belong to companies with multi-buyer / multi-approver / company-admin roles. Native in Adobe Commerce; available via Aheadworks / Mageplaza B2B in Open Source.
• Quote workflow: distributor requests a quote, sales rep reviews, multi-step approval, converts to order. Native Adobe Commerce. Aheadworks "B2B" for Open Source.
• Net-30 / payment terms: per-customer terms (Net-15, Net-30, Net-60). Adobe Commerce native; Open Source via Mageplaza Payment Terms ($199 one-time).
• Tax exemption: per-company resale certificates, tax-exempt customer groups, integration with Avalara / TaxJar for cross-state US distributor tax.

The B2C storefront stays clean — consumers never see distributor pricing or trade-only SKUs. Logged-in B2B users automatically see their tier prices, requisition lists, and quote tools without a separate URL.

Magento has native product compare (the "compare" button on PDP / category) but it’s minimal — basic side-by-side with first-level attributes. Electronics shoppers expect richer comparison.

Native + theming: Hyvä compare module + custom layout for the compare-page renders all 30+ attributes per attribute set in a sticky-header table. Free, but needs ~3–5 days of theming work.

Extensions (in order of fit):

• Mirasvit Advanced Product Compare ($199): adds multi-set comparison, attribute grouping (display "Display" attributes together, "Battery" attributes together), sticky-header on long tables, share-comparison-by-link. Mature, well-supported.
• Magefan Better Compare ($129): lighter alternative, AJAX-based, mobile-optimised. Good for B2C electronics.
• Mageworx Advanced Compare ($249): includes "compare with" widget on PDP, "frequently compared together" recommendations. Adds a B2C upsell angle.

For high-end electronics (cameras, laptops, networking gear) Mirasvit + Hyvä is the standard combo. The compare table itself is also a SEO landing-page candidate — Google ranks "X vs Y" comparison URLs, so structure your compare-by-URL pattern with proper canonicals.

Three patterns, each with tradeoffs:

1. Custom attribute (file type): add a "Datasheet PDF" file attribute to the relevant attribute sets. Upload via admin or sync from PIM. Render as a download button on PDP with download tracking via Google Analytics event. Simplest, free. Limitation: one file per SKU per attribute — not great for products with multiple datasheets, certifications, manuals.
2. Magento Downloadable Product: gated downloads (require login) for warranty registrations or pro-only datasheets. Built-in but heavyweight — the SKU itself becomes "downloadable" rather than a physical product, so this conflicts with main electronics SKU type.
3. DAM + relations (Pimcore / Akeneo): store all PDFs in the PIM/DAM with relations to SKUs (one product → multiple files: datasheet, manual, warranty card, certification). Sync the metadata to Magento, link to the PDF served from PIM/DAM via signed URLs. Best at scale — 50k SKUs × 5 docs = 250k files, which Magento media folder doesn’t love.

SEO bonus: every datasheet PDF should have a clean URL (/datasheet/{sku}-{slug}.pdf), correct Content-Disposition (inline for browser preview), and JSON-LD on the parent PDP linking back to the datasheet as a DigitalDocument. Google indexes PDFs — they drive long-tail traffic to electronics pages.

The market is mature. Three serious options:

Mirasvit RMA ($349 one-time + optional support): full self-service portal, custom return reasons, multi-step approval workflow, return label generation (ShipStation / Shippo integration), repair tracking, refund/exchange/store-credit decisions, customer email automation. Used by 5,000+ stores. Most mature. Pick if RMA volume is 5%+ of orders and you want a polished customer-facing portal.

Mageworx RMA ($299 one-time): similar feature set, slightly less polished UX but cleaner admin. Good fallback if Mirasvit doesn’t fit.

Aheadworks RMA ($349 one-time): tightly integrated with Aheadworks B2B suite if you’re already on that. Strong on B2B return workflows (PO-based returns, distributor reverse logistics).

Extended warranty: separate concern. Two patterns:

• Magento product type "Warranty Plan" + Mageworx Product Warranty ($199): customer adds a warranty plan SKU at checkout. Magento tracks the relationship. Manual claim handling.
• Extend / Clyde / Mulberry third-party warranty providers: turnkey API integration, they handle the underwriting + claims. You get a revenue share. Best for B2C electronics where warranty is a margin-driver.

RMA + extended warranty are 5–15% of post-sale touch in electronics. Get this stack right or lose 0.5–1.5% of margin to bad ops.

Target: <200ms search response time at p95, <100ms layered-nav filter response. Achievable with:

• Elasticsearch / OpenSearch: required since Magento 2.4. Run a dedicated cluster (not co-located with MariaDB) at 4–8GB RAM minimum, NVMe storage. Single-node is fine to ~250k SKUs; shard to 3 nodes above that.
• Searchable attribute curation: not every attribute should be searchable. Review the catalog_eav_attribute.is_searchable flag — turn off "Cost", "Width Map" etc. that customers don’t search. Fewer searchable attributes = faster index + faster query.
• Layered nav indexing: catalog_product_attribute + catalog_search indexers on cron, not on save. Re-index 50k SKUs in 8–12 minutes nightly.
• Synonyms + boost rules: configure synonyms (e.g. "WiFi" / "Wi-Fi" / "wireless networking") in admin → Stores → Search Synonyms. Boost rules promote in-stock + high-margin SKUs.
• Hyvä autocomplete: replace Magento’s default suggest with Hyvä-native autocomplete — ~200ms keystroke latency vs Luma’s 600ms+.
• Optional: Algolia / Klevu / Searchspring — SaaS search overlay. $200–$2,500/mo. Worth it at >100k SKUs or when on-site search is a primary conversion driver. They handle relevance tuning, NLU, personalization out of the box.

For a typical 50k-SKU electronics store, vanilla Magento + Elasticsearch + Hyvä is enough. Add Algolia/Klevu only if the data shows search is a top-3 conversion driver.

For electronics, the platform decision is sharper than for apparel or general retail because of SKU scale, attribute richness, B2B distribution, and warranty workflows.

Shopify Plus wins for electronics when: catalog is <5k SKUs (cameras, audio, speciality electronics brands), pure D2C with no distributor channel, single warehouse, single language, marketplace presence is "Amazon only or none". E.g. a boutique audio brand selling 200 SKUs to consumers. Shopify Plus + a few apps gets to live in 6 weeks at $30k–$60k all-in.

Magento wins for electronics when: catalog >10k SKUs (computer components, IT distribution, consumer electronics retail), multi-warehouse or drop-ship blend, B2B distributor share >20%, multi-marketplace mandatory, PIM integration required. E.g. an IT distributor with 80k SKUs across 4 warehouses, 30% B2B revenue, listings on Amazon + Newegg + eBay. Shopify Plus would need 12+ apps stacked together at $1.5k–$3k/mo + custom dev to fake what Magento does natively. Magento + Hyvä build: 12–20 weeks, $80k–$200k. Pays back in 18 months on app fees alone.

Specific Shopify Plus gaps for electronics: (1) attribute-set inheritance is awkward — managing 30+ specs per SKU across 12 categories means metafield sprawl; (2) MSI equivalent (Shopify Locations) is shallower — no native source-priority rules; (3) B2B is improving but distributor-tier pricing + Net-30 + multi-step approvals still hit limits; (4) marketplace sync requires app stack ($300–$2k/mo) where Magento has direct integrators with deeper feature sets.

Yes — Hyvä is actually better suited to catalog-heavy stores than to brand-storytelling stores, despite the marketing focus on the latter.

Why: Hyvä replaces Luma’s ~3MB of JS (jQuery + RequireJS + KnockoutJS + UI components) with ~150kB of Tailwind + Alpine.js. On category pages with 60 product cards (typical electronics listing), this matters compounds — LCP drops from 3.8s to 1.2s, INP from 280ms to 80ms, and the browser stays responsive while scrolling. On catalog-heavy stores, page weight is the dominant performance variable, not template complexity.

Real numbers from a 60k-SKU electronics build I shipped in 2025:

• Lighthouse mobile: 96 (homepage), 94 (category), 92 (PDP).
• LCP: 1.1s mobile, 0.7s desktop (75th percentile, real-user data).
• CLS: 0.02 (well under the 0.1 threshold).
• INP: 78ms (well under the 200ms threshold).

Caveats: (1) Hyvä is a paid theme (€1,000 one-time per project licence + extension licences) — budget for it; (2) some legacy extensions don’t have Hyvä compatibility patches — check your stack before committing; (3) PWA Studio / pure-headless is overkill for 99% of electronics stores — Hyvä gives 95%+ of headless performance with 30% of the build cost.

Verdict: Hyvä is the default for new Magento electronics builds in 2026. Skip Luma.

Realistic ranges by SKU + complexity tier:

Tier 1: 2k–10k SKUs, single warehouse, B2C-only, Amazon only

• Build: 10–14 weeks. Cost: $35k–$70k.
• Stack: Magento Open Source + Hyvä + M2E Pro (marketplace) + Mirasvit RMA + simple PIM (or no PIM if catalog stable).

Tier 2: 10k–50k SKUs, 2–3 warehouses, 20–40% B2B share, Amazon + eBay

• Build: 14–20 weeks. Cost: $80k–$160k.
• Stack: Magento Open Source + Hyvä + Codisto (marketplace) + Akeneo PIM + Aheadworks/Mageplaza B2B + Mirasvit RMA + MSI configuration.

Tier 3: 50k+ SKUs, 4+ warehouses, >40% B2B distribution, Amazon + eBay + Newegg + Walmart

• Build: 20–32 weeks. Cost: $180k–$400k.
• Stack: Adobe Commerce (native B2B) or Magento OSS + Aheadworks B2B suite, Hyvä, Channel Advisor (marketplace), Akeneo or Pimcore enterprise, Mirasvit RMA + Extend warranty integration, custom MSI source-selection algorithm, ERP integration (NetSuite / SAP).

Hidden costs to budget for: (1) data migration from current platform — $5k–$25k depending on data quality; (2) URL redirect map — critical for SEO continuity, $3k–$10k; (3) ERP / OMS integration — $15k–$80k; (4) ongoing retainer — $2k–$10k/mo for keeping the stack patched + iterating.

I quote fixed-fee for Tier 1 + Tier 2; Tier 3 is time-and-materials with weekly check-ins because surprises are inevitable.

Furniture configurators are deeper than fashion variants but Magento handles them cleanly with the right pattern.

Schema: use Magento configurable products for the primary axis (typically dimension or model) and Custom Options for the secondary axes (fabric, finish, hardware, leg style). Bundle products handle multi-piece sets (e.g. sectional with 4-5 modules). EAV attributes hold the swatch metadata.

Visual swatch picker: the default Custom Options dropdown is unusable for fabric. Wire in a UI extension (Mageworx, Aheadworks Advanced Product Options, or a custom React widget on Hyvä) that renders fabric thumbnails, hover-to-zoom, and a “swatches by mail” CTA.

Validation rules: not every fabric ships on every frame. Use option dependencies (e.g. via the same extension or a custom rule engine) to disable invalid combos in real time.

Scale: 1,000+ valid permutations per product family is achievable. I’ve shipped a custom-sofa configurator with 4,200 valid combinations and a 1.8s LCP on Hyvä. Below 100 SKUs you can fake it on Shopify; above 500 SKUs with 3+ axes, Magento is the answer.

Three integration options, ranked by furniture fit:

• FreightCenter API — the most furniture-friendly. Pulls live LTL rates from XPO, ABF, R+L, FedEx Freight, YRC. Handles white-glove + room-of-choice + threshold delivery as line-item upsells. Good account-rep support. Most furniture brands settle here.
• uShip — marketplace model (carriers bid). Cheaper rates but slower quote turnaround (1-3 hours, not real-time). Better for very-large items where a marketplace bid beats a contract rate. Pair with FreightCenter for instant quotes + uShip fallback.
• Roadie (UPS-owned) — gig-economy local + regional. Excellent for last-mile + same-day in metro areas. Doesn’t replace LTL for cross-country — supplements it.

Integration shape: Magento shipping-method extension calls the carrier API on cart at the freight-quote step. White-glove / assembly / liftgate are separate SKU line items added by the customer (not bundled into the freight rate). Liftgate-required ZIP codes auto-toggle the line item. Real-time API call adds 1.5-3s to the cart, so cache aggressive on identical zip+weight combos.

Yes, and it’s the single biggest CX investment for made-to-order furniture.

PDP message: a per-product lead_time_min_weeks + lead_time_max_weeks attribute drives the “ships in 6-8 weeks” copy. Custom upholstery: 10-14 weeks. In-stock: “ships in 2-3 days.” The number is dynamic — pulled from inventory + production calendar — so it stays accurate.

Production milestones: custom order-status extension (or a custom workflow in sales_order with a state machine) tracks the stages: Order received → Materials cut → Frame built → Upholstery in progress → QC → Shipped → Out for delivery. Customer sees a progress bar on the order-tracking page. Each stage triggers an email (“your sofa is in upholstery this week”) which reduces support tickets ~40% in the data I see.

Outbound visibility: ShipStation or Shippo handles the LTL handoff and surfaces tracking once the carrier picks up. For white-glove deliveries, the carrier’s appointment-scheduling portal (XPO Connect, ABF’s scheduler, or Metropolitan’s app) gets embedded into the order-tracking page so the customer schedules their delivery window without phoning support.

Treat each delivery service as a separate line-item SKU with its own price logic, not as a freight-rate add-on.

• Curbside delivery — carrier drops at the curb. Default for LTL. No extra SKU.
• Threshold delivery — carrier brings to the front door / threshold. SKU price ~$50-$150.
• Room-of-choice — carrier places in the customer’s chosen room. SKU price ~$100-$250.
• White-glove — room-of-choice + unpack + debris removal. SKU price ~$200-$500.
• White-glove + assembly — full setup, includes furniture build + light installation. SKU price ~$300-$800 depending on complexity.

UX: a delivery-options widget on cart (above the freight quote) lets the customer pick the tier. Each tier adds the corresponding line-item SKU. The freight quote stays separate and doesn’t re-fetch when the customer changes tier (the SKUs are virtual / non-shipping).

Carrier coordination: the back-end fulfillment system tags the order with the chosen tier and routes to the right carrier (e.g. Metropolitan / Pilot for white-glove networks). Margin on white-glove is typically 30-40% — meaningful revenue, not a cost center.

Three serious vendors, different fits:

• Cylindo — furniture-specialist. Built for sofa / chair / casegoods configurators. Auto-generates 360-degree spins from 3D models, supports fabric/finish swap in real time, integrates with most configurators including Magento. Premium pricing ($1.5k-$5k/mo). Best fit for medium-large furniture brands.
• Threekit — broader (furniture, jewelry, apparel). Powerful 3D + AR + product configurator unified platform. Steep learning curve + higher TCO. Best fit for brands wanting one vendor for both visualization + configurator (replacing Magento Custom Options entirely).
• Sketchfab — cheapest entry point. Great for static 3D model viewer + iOS Quick Look + Android Scene Viewer integration via <model-viewer> Web Component. No real-time configurator overlay. Best fit for <100 SKU brands wanting AR-on-PDP without the Cylindo / Threekit budget.

Implementation: all three plug into Magento via product attribute holding the 3D model URL or vendor SKU. Front-end loads the viewer lazily on PDP scroll-into-view. Mobile AR triggers via the standard <model-viewer ar> tag — iOS uses USDZ, Android uses GLB.

Conversion lift: 1.8-3.2x AR-on / AR-off on furniture PDPs in the data I see, especially at AOV $1,500+. Pays back the integration cost within 60-90 days for most mid-market brands.

Calendly works fine for <3 showroom locations. Above that, dedicated appointment platforms scale better.

• Calendly — embed on PDP and footer via the official widget. Each showroom is a separate event-type. Customers pick location + designer + time slot. Free for basic, $12-$20/user/mo for team features. Limit: doesn’t handle inventory awareness (“is this sofa actually on the showroom floor today?”).
• SimplyBook.me — multi-location native, supports up to 50+ providers, custom intake forms, automated reminders. Better for retail furniture chains with 5+ showrooms.
• Acuity Scheduling (Squarespace-owned) — mid-tier. Good for design-consult bookings (60-90 min slots) with a virtual + in-person toggle.
• Square Appointments — bundles with Square POS. Good fit for brands already running Square in-store.

Magento integration: embed via product-attribute “available at showroom” flag + a CMS block on PDP that shows the appointment widget. For showroom inventory awareness (“the brown leather version is on the LA floor; the cream is at SF”), pull a per-store-per-SKU availability flag into Magento via custom attribute and surface it in the appointment-picker UI.

Conversion data: 30-50% of high-AOV furniture buyers want to see in person before buying. A booking widget on PDP routes those buyers into a showroom visit with an associate — closes ~25-40% of those visits.

Native Magento B2B (or Open Source + extensions) handles trade programs cleanly:

• Trade application — custom form captures business name, license number, resale-certificate upload, portfolio URL. Submission triggers an admin notification; manual approval flips the customer’s group to “Trade.”
• Tier pricing — customer-group price rules give Trade members 15-30% off retail (your call), with deeper tiers (e.g. 35% at Diamond) gated by annual purchase volume. Enforced at cart by Magento’s native pricing engine.
• Hidden trade catalog — segment-restricted categories let you stock items only Trade members see (e.g. wholesale-only fabrics, designer-only finishes).
• Net-30 invoicing — via Apruve / Resolve / TreviPay payment-method extensions. Customer checks out without a card; invoice sent post-shipment.
• Designer rebate program — track lifetime trade purchases via custom customer attribute. Issue quarterly rebate via store credit (Mageworx / Mirasvit credit extension) or check.
• Volume-tier discounts — cart-level rules (e.g. 10% off at $5k cart, 15% at $10k) layer on top of tier pricing.
• Line-sheet PDF export — trade members generate a branded PDF of selected products via a custom “export selection” action.

Adobe Commerce ships Companies + Quotes natively; Open Source needs Aheadworks B2B Suite or equivalent.

Furniture returns are catastrophically expensive. The right policy + workflow is more about preventing returns than processing them efficiently.

Prevention: swatches-by-mail (free or $5-15 refunded on order), AR / 3D visualization (cuts return rate 30-40% in the data I see), generous pre-purchase consultation (designer chat / showroom booking), and explicit dimensions + weight + clearance-needed measurements on PDP.

Policy structure: most furniture brands run a 30-day return window for in-stock items, no returns on custom upholstery / made-to-order, restocking fee 15-25% to cover reverse freight + repackaging. Some premium brands eat the freight cost as a brand investment.

Reverse freight: integrate with the same LTL carrier (FreightCenter, uShip) that delivered — they handle pickup + return-to-warehouse with one workflow. White-glove returns include unpack-at-customer + repack + load. Cost is typically $200-$600 per return, which is why the restocking fee exists.

RMA workflow on Magento: Magento RMA module + Mirasvit Advanced Reports / Mageworx RMA extension handles the request, approval, return label, restock + refund flow. Photo-upload requirement deters “changed my mind” returns on items that arrived perfect.

Damaged-in-transit: separate workflow — customer files a damage claim with photos within 48h, brand replaces the piece + handles carrier claim with the LTL carrier. White-glove deliveries have lower damage rates (~3%) than curbside (~8-12%).

Furniture is one of the categories where Magento clearly wins above ~$2M GMV.

Where Magento wins:

• Configurator depth — Custom Options + Bundle products + EAV handle 1,000+ valid combinations cleanly. Shopify maxes out at 100 variants per product without third-party apps that add per-month costs and slow PDPs.
• LTL freight — Magento shipping-method extensions integrate FreightCenter / uShip / Roadie natively. Shopify needs Bolt-on apps (Shipper HQ, etc.) with limits on white-glove + assembly upsells.
• B2B / trade — native customer groups + hidden categories + tier pricing. Shopify B2B (Plus-only) added similar features in 2023 but has gaps on multi-step trade approval + designer rebates.
• Lead-time + production milestones — custom order-status workflow on Magento; Shopify doesn’t expose order state-machine.
• Multi-region freight — one Magento backend can serve US LTL + EU pallet courier with separate freight rules per store view. Shopify Markets shares freight logic across regions.

Where Shopify wins:

• Furniture brands under 200 SKUs with simple variants (no real configurator) and parcel-shippable items. Shopify launches in 4 weeks vs 12-16 on Magento.
• Pure DTC, no B2B / trade, no white-glove, in-stock only. Shopify avoids the Magento ops overhead.

Practical rule: under $2M GMV with simple SKUs → Shopify; above $5M GMV with configurator + LTL + B2B trade → Magento; the $2-5M middle is a case-by-case fit decision based on configurator complexity.

US and EU furniture freight are different operational worlds. Magento multi-store handles both; the rules per region are separate.

US LTL: dominant carriers XPO, ABF, R+L, FedEx Freight, YRC. Pricing by NMFC freight class + zone + weight. White-glove networks (Metropolitan, Pilot, J.B. Hunt) handle premium delivery. Liftgate required at residential. Integration via FreightCenter / uShip API.

EU pallet courier: different model entirely. Brands like Palletways, FreightOne, DPD Pallet, DSV. Pricing by pallet count + dimensions + zone. White-glove + assembly is more rare in the EU; most consumers expect curbside or threshold. Two-man delivery teams handle large items (sofas, beds). Integration via partner-specific APIs or aggregators like Sendcloud.

Currency + tax differences: US sales tax (managed via Avalara or TaxJar, varies by state + economic-nexus rules). EU VAT (managed via Magento native VAT engine + per-country rates, with OSS reporting for cross-border B2C and reverse-charge for B2B). UK post-Brexit needs separate handling (UK VAT + customs declarations on EU↔UK shipments).

Magento setup: one backend, two store views (US + EU), separate shipping-method configurations, separate freight-API credentials, separate tax rules. Shared product catalog with per-store-view price + currency overrides.

Brexit footnote: UK customers ordering from EU stock incur UK VAT + customs at delivery (or merchant pre-pays via DDP). Most furniture brands stock locally in the UK to avoid the friction.

Made-to-order upholstery is the highest-margin furniture segment but the most operationally complex. Magento + a production-management extension handles it.

Order capture: the configurator stores every customer choice (frame, fabric SKU, fabric direction, contrast piping, leg style, leg finish, cushion fill, etc.) as line-item options on the Magento order. The order is “locked” once placed — changes require a phone call to support to reissue.

Production routing: custom Magento extension or workflow tags the order with production stage (cut → sew → upholster → QC → ship). Each stage has an SLA (e.g. cut by day 7, sew by day 14, ship by day 56). Production team marks each stage complete via admin or a barcode-scanner app; the customer sees the progress bar update.

Material allocation: fabric is reserved against the order at checkout (Magento MSI reservation) so the production team knows the yardage is dedicated. Backorder triggers a customer email + ETA update if the fabric runs out.

Quality control: the QC step uploads photos before shipping (so the customer sees the actual piece) — cuts post-delivery dispute rate ~50% in the brands I’ve worked with.

Shipping: custom upholstery typically ships LTL with a pre-scheduled white-glove window. The carrier’s appointment scheduler (or a manual call from the brand’s ops team) confirms the date. No surprise deliveries.

Cancellation policy: most brands lock the order at “materials cut” (typically day 5-7). Before cut: full refund. After cut: store credit only or 25% restocking. Communicated upfront on PDP + at checkout.

Realistic ranges for a furniture-specific Magento + Hyvä build:

• Greenfield (replatform from Shopify or new build): 12-16 weeks, $35k-$95k. Includes Hyvä theme + configurator + LTL freight integration + lead-time tracking + AR/3D wiring + B2B trade layer + showroom booking.
• Configurator-only retrofit on existing Magento: 4-6 weeks, $12k-$30k. Adds the fabric/finish/dimension picker + visual swatches + validation rules + custom-options optimisation.
• LTL freight integration only: 2-4 weeks, $6k-$18k. FreightCenter / uShip API + white-glove + assembly line items.
• AR/3D visualization rollout: 4-8 weeks (depends on 3D-model availability), $8k-$25k for the integration; 3D models themselves cost $200-$1,500 each from a vendor like CGI Furniture or Confetti Design.
• B2B trade program retrofit: 3-6 weeks, $10k-$28k. Trade application form + customer-group pricing + Net-30 + hidden catalog + designer rebate tracking.

Ongoing: $1.5k-$5k/mo retainer for continuous optimisation through seasonal calendar (configurator UX iterations, freight rate audits, AR conversion tuning, trade-program refinements). Most brands keep a retainer for the first 12 months post-launch.

What inflates timeline: 3D model acquisition (12+ weeks if starting from scratch), ERP / OMS integration (NetSuite / Acumatica), custom production-management extension if standard ones don’t fit, multi-region launch (US + EU + UK).

The cheapest builds skip AR + skip B2B trade + use a generic LTL aggregator. The most expensive builds include real-time configurator visual rendering + bespoke production-management workflow + 4-region deployment.

At $5M GMV, Magento Open Source is usually cheaper, but the gap isn’t as wide as Magento marketers claim.

Shopify Plus 3-year TCO at $5M: ~$2,300/mo licence floor (or 0.4% of GMV, whichever is greater) → ~$240k licence over 3 years. Add ~0.15% per-tx fee on Shopify Payments (or ~2% if using a 3rd-party gateway) → another $22k–$300k. App stack typically $400–$1,200/mo → $14k–$43k. Plus dev work — assume $30k–$80k. Total: ~$310k–$660k.

Magento Open Source 3-year TCO at $5M: $0 licence. Hosting (Cloudways / dedicated) $400–$1,500/mo → $14k–$54k. Initial build $25k–$80k. Ongoing dev $1.5k–$5k/mo retainer → $54k–$180k. Search / monitoring add-ons $200–$600/mo → $7k–$22k. Total: ~$100k–$340k.

Adobe Commerce changes the calculus — its licence at $5M is roughly $40k–$80k/yr, putting it in Shopify Plus territory. So if you’d need Adobe Commerce features anyway, Shopify Plus is competitive on price and wins on operational cost.

Yes — Shopify → Magento is a well-trodden path. Realistic numbers:

• Timeline: 8–16 weeks for a typical mid-market store. Faster (6 weeks) if catalog is small and design is preserved; longer (24+ weeks) if you’re also re-platforming PIM/ERP.
• Cost: $15k–$60k for a clean rebuild on Hyvä-themed Magento. Add $10k–$25k for ERP / OMS / loyalty re-integration.
• Risk: the three things that go wrong: (1) URL redirects miss long-tail product pages, dropping SEO 20–40% for ~6 weeks; (2) customer passwords don’t migrate (Shopify won’t expose hashes), so you have to force a reset email; (3) saved payment methods at the gateway need re-tokenisation.

Mitigation: run both stores in parallel for 30 days behind a feature flag, only flip DNS once the redirects map ≥98% of traffic and the new store has 30 successful test orders. The risk is real but quantifiable.

The key Shopify Plus features that move the comparison vs Magento:

• Shopify Functions / Scripts — server-side custom logic for checkout, discounts, payments, shipping. Plus-only. Replaces a lot of what apps used to do; competes with Magento’s native sales-rule + observer model.
• B2B on Shopify — companies, customer-specific catalogs, Net-30 — Plus-only and still has gaps (more on that in the next FAQ).
• Multiple expansion stores — Plus includes 9 expansion stores (extra orgs for different regions/brands) at no extra cost.
• Launchpad / Bulk Editor / Flow — automation for sales, inventory, fraud — closes the gap on Magento’s admin power.
• Higher API limits, dedicated support, Avalanche checkout

Plus pricing starts at $2,300/mo or 0.4% of GMV (whichever’s greater), with a hard floor and per-tx fees on top. The gap to regular Shopify Advanced ($399/mo) is significant — most of the Magento-vs-Shopify discussion at the upper-mid market is really Magento vs Shopify Plus.

Shopify Plus B2B has improved a lot since 2023 but still has real gaps vs Magento Adobe Commerce B2B:

• Quote workflow — Magento native (request-quote, negotiate, convert to order). Shopify B2B requires Plus + a third-party app (Sparklayer, B2B Wave) with limits on multi-step approvals.
• Requisition lists — Magento native, including "share with company" and recurring orders. Shopify can fake it with draft orders but no native UI.
• Tiered customer-specific pricing — Magento handles unlimited price tiers per customer + per SKU. Shopify B2B handles company-level price lists but tiered-by-quantity pricing per customer is awkward.
• Net-30 / payment terms — both support, but Magento allows custom terms per customer (Net-15, Net-45, Net-60); Shopify B2B has fixed buckets.
• Approval workflows — Magento allows multi-level (e.g. requester → manager → finance) approvals; Shopify B2B is single-level.

Verdict: if B2B is >30% of revenue with complex workflows, Magento wins. If B2B is <30% with standard "wholesale price + Net-30" mechanics, Shopify Plus B2B is now genuinely good enough.

Different architectures, different tradeoffs.

Shopify Markets (built into all plans, expanded on Plus): one storefront serving multiple regions with currency conversion, market-specific pricing, regional tax, geolocation, language toggling. Excellent for B2C brands selling the same catalog with regional pricing variants. Limitation: catalog is shared — you can’t hide products in one market without scripting.

Magento multi-store: one backend → N websites → N stores → N store views. Each axis can override catalog, pricing, tax, currency, language, payment methods, shipping. Truly independent storefronts sharing a single admin. Excellent for retailers selling different catalogs or running different brands; overkill for a single-brand 3-region store.

If you want Shopify Markets’ simplicity but with full per-region catalog control, Shopify Plus expansion stores cover that — but each is a separate org so you maintain N catalogs. Magento avoids that with a shared catalog and per-store overrides.

Rule of thumb: same catalog, different prices/languages → Shopify Markets. Different catalogs / brands / B2B-or-B2C-per-region → Magento.

Out-of-the-box: Shopify wins.

• Shopify (Dawn theme, no apps): LCP ~1.8s, CLS ~0.03, INP ~150ms. Lighthouse mobile ~85.
• Magento Luma (default): LCP ~3.8s, CLS ~0.12, INP ~280ms. Lighthouse mobile ~45.

But with proper engineering, Magento beats Shopify:

• Magento + Hyvä theme (Tailwind + Alpine.js, no jQuery, ~95% less JS): LCP ~1.2s, CLS ~0.02, INP ~80ms. Lighthouse mobile ~95+.
• Shopify with 8+ apps installed (typical): LCP drifts to 2.5–3.2s as third-party scripts accumulate. Lighthouse drops to 60–70.

So the real comparison is: Shopify defaults are fast but degrade as you add apps; Magento+Hyvä takes 4–8 weeks to stand up but holds 95+ Lighthouse indefinitely because customization happens in your codebase, not in third-party scripts.

For Core Web Vitals as a SEO ranking factor in 2026, Magento+Hyvä is the better long-term bet for stores that will accumulate features over time.

Both can rank well. Different shapes of problem:

Shopify SEO strengths: fast defaults, automatic image lazy-loading, built-in sitemap, clean URL structure, automatic structured-data (Product, BreadcrumbList) on most themes. Weaknesses: forced /collections/ and /products/ URL prefixes, limited control over canonicalization, no native hreflang for multi-region (Shopify Markets sets it, but customization is awkward).

Magento SEO strengths: full control over URL structure, robust hreflang via store views or custom modules, custom canonical rules, JSON-LD structured data per page (with the right modules), built-in XML sitemap with priority/changefreq controls. Weaknesses: defaults need tuning (duplicate-content from layered nav, slow LCP on Luma) — out-of-box, Magento ranks worse than Shopify on technical SEO until you fix it.

In practice: a well-engineered Magento store outranks Shopify because you have more levers (URL structure, canonicalization, structured data, programmatic SEO at scale via category landing pages). A poorly-engineered Magento store loses to a default Shopify store. SEO advantage goes to whichever team puts in the work — neither platform wins this fight by default.

It cuts both ways.

Pro-Shopify: for ~80% of common features (loyalty, reviews, upsell, subscriptions, ERP sync, email capture), there’s a vetted app you can install in 10 minutes. Magento has ~5k extensions on the Adobe Marketplace + Github but quality varies wildly and most need a developer to integrate.

Pro-Magento: Shopify apps are a recurring tax — typical mid-market store runs 8–15 apps at $20–$200/mo each → $300–$2,000/mo in app fees, indefinitely. Magento extensions are usually one-time licence fees. Over 3 years, Shopify app spend often exceeds Magento dev cost.

The hidden cost on Shopify: apps inject JS that compounds. By the time a store has 12 apps, page-load is 30%+ slower than vanilla. Removing apps to fix performance breaks features. This is the most common reason Shopify Plus stores migrate to Magento at $10M+.

Verdict: app marketplace is a feature for the first 1–3 years. After that it becomes a liability if you’re not disciplined.

Honest framing:

Shopify (managed SaaS): 99.99% uptime SLA, auto-scaling for Black-Friday traffic, no DevOps work. Risk: if Shopify de-prioritises a feature you depend on (e.g. Audiences, Linkpop) it disappears with little notice. You can’t pin versions. Major checkout changes are pushed to all stores simultaneously.

Magento Open Source self-hosted: you own the stack — pick hosting (Cloudways, AWS, Hetzner), pick PHP version, pin Magento version, schedule upgrades when you want. Risk: you own incidents (DDoS, hosting outage, bot attacks, OS upgrades). Need either a competent dev or a $1.5k–$5k/mo retainer to keep it patched. Magento security patches must be applied within 30 days or you risk the Magecart-class breaches.

Adobe Commerce Cloud sits between: managed but pricey ($60k+/yr), with the platform-control of Magento but offloaded ops.

Pick Shopify if you don’t want to think about ops. Pick Magento Open Source if you have a dev team or retainer and value control. Pick ACC if you want managed Magento and have $60k/yr to spare.

Different scopes.

Shopify: handles PCI-DSS Level 1 compliance for you. Card data never touches your servers — it’s tokenised at Shopify Checkout. Your PCI scope is SAQ A (the easiest tier — basically a self-attestation that you don’t store/process/transmit card data).

Magento Open Source self-hosted: if you use a hosted gateway (Stripe Elements, Braintree Hosted Fields, Adyen drop-in), card data also never touches your servers — you stay in SAQ A territory. Cost: $0 extra.

Magento with on-server payment forms (rare these days, but Authorize.Net AIM and some legacy gateways): card data touches your server briefly. PCI scope jumps to SAQ A-EP or SAQ D, requiring quarterly ASV scans, annual penetration tests, and full PCI documentation. Cost: $5k–$25k/yr.

Verdict: as long as Magento store uses tokenized payment forms (which any modern build does), PCI burden is roughly equivalent to Shopify. PCI is not a real differentiator in 2026.

Both can — different paths.

Shopify ERP integration: mostly through middleware (Celigo, Workato, Boomi, MuleSoft) or app-store connectors (e.g. Alumio, Patchworks for NetSuite). Pros: connector vendor handles the schema diffs and auth refreshes. Cons: middleware costs $400–$2,500/mo indefinitely, and custom field mappings often require a service-desk ticket. Real-time sync is rare; most are 5-min batches.

Magento ERP integration: direct API integration is the norm. Magento’s REST + GraphQL APIs cover orders, customers, inventory, products. Custom modules can expose ERP-specific webhooks. Pros: no middleware tax (one-time $20k–$80k dev cost), real-time sync is achievable, full control over data shape. Cons: you own the integration — when SAP changes its IDoc format you’re the one fixing it.

Rule of thumb: under $5M GMV with standard ERP setups → Shopify + middleware is faster. Above $5M with complex SKU master data, multi-warehouse inventory, or IDoc-based SAP → Magento direct integration is more reliable and 3-year-cheaper.

Both punt to specialised services for serious multi-jurisdiction tax. The differences are in how easy that integration is.

Shopify: built-in tax engine handles US sales tax (with Shopify Tax — $0.99 per US order on top of standard fees), EU VAT (manual config), UK VAT, Canadian GST/PST. For more complex setups (marketplace facilitator rules, tax-exempt B2B customers, multiple US states), the standard path is Avalara or TaxJar — both have first-party Shopify apps.

Magento: built-in tax-rate / tax-rule engine is more flexible (per-region, per-customer-group, per-product) but requires more configuration. For automated rate updates and economic-nexus tracking, integrate Avalara, TaxJar, or Vertex via the official Adobe-Marketplace extensions. Magento also natively supports tax-exempt customer groups (rare in Shopify B2C, native in Shopify B2B).

EU VAT specifically: Magento handles distance-selling thresholds, OSS reporting, and B2B reverse-charge natively. Shopify needs a 3rd-party (Vatify, Quaderno) for OSS / reverse-charge.

Verdict: for US-only retailers, Shopify Tax + Avalara is the fastest path. For EU + cross-border B2B, Magento + Avalara is more flexible.

We specialize in e-commerce development with expertise in Magento 2, Shopify, and WordPress/WooCommerce. Our services include custom development, theme design, plugin/extension development, performance optimization, and ongoing maintenance and support.

Project timelines vary based on complexity and scope. A simple theme customization might take 1-2 weeks, while a complex custom e-commerce solution could take 2-3 months. We provide detailed timelines during the project planning phase.

Yes! We work with clients worldwide. Our team is experienced in remote collaboration and uses modern communication tools to ensure smooth project execution regardless of timezone differences.

Closer than the brochures suggest. Real numbers from 8 enterprise migrations in this band:

Shopify Plus 3-year TCO at $50M: Plus baseline $2,300/mo OR 0.4% × $50M = $200k/yr (whichever is greater — at $50M the GMV-based fee bites) → $600k+ over 3 years. Per-tx fees ~$75k/yr on Shopify Payments (0.15%) → $225k. 8–12 Plus apps at $1–5k/mo each (Klaviyo, Gorgias, Yotpo, Rebuy, Loop, Postscript, Shipstation, Avalara, Sparklayer for B2B) → $300k–$1.8M. Plus dev / agency $200–500k. Total: $1.3M–$2.9M.

Adobe Commerce 3-year TCO at $50M: AC license tier at $50M GMV is roughly $80–150k/yr (revenue-banded) → $240–450k. Adobe Commerce Cloud infra $50–80k/yr → $150–240k. In-house dev team (3–5 engineers) or agency on retainer over 3 years → $400–900k. Plus extension licenses + monitoring + search add-ons $50–100k. Total: $840k–$1.7M.

AC usually wins TCO by ~$200–800k once you account for Plus app multipliers — but the Plus number is more predictable. AC is cheaper if you run lean; more expensive if you don’t. The TCO winner is whichever platform fits your org without forcing it to grow into the cost.

Both have "Companies" but they solve different procurement realities.

Shopify Plus B2B Companies (released 2023, mature in 2024-25):

• Wholesale-account abstraction — one Company has many buyers
• Tag-based catalog visibility (which products show to which Company)
• Custom price lists per Company
• Draft Orders as quote workflow (single-step approval)
• Net-30 / Net-60 buckets on payment terms
• B2B account hub for self-service reorders

Best for D2C-flavored B2B — wholesale tier where the buyer experience mirrors retail. Strong fit for beauty / apparel / CPG brands selling wholesale to boutiques.

Adobe Commerce B2B Companies (mature since 2018, deepened in 2024):

• Multi-buyer roles per Company (Admin / Buyer / Approver / Junior Buyer)
• Multi-level approval chains (requester → manager → CFO, with $-threshold routing)
• Negotiable Quotes — full RFQ workflow with line-item negotiation, PDF export, version history
• Requisition Lists — recurring orders shared across the Company team
• Customer-segment catalogs — different SKU sets per Company segment
• Per-buyer credit limits + per-buyer payment terms (Net-15 / Net-45 / Net-60 mixed)
• Punchout (OCI / cXML) integration to Coupa / Ariba / SAP SRM

Best for procurement-style B2B — industrial distribution, food-service, MRO, B2B SaaS reseller channels.

Verdict: if your buyer journey involves a quote-to-order cycle longer than 24 hours, multi-buyer roles per company, or punchout integration to procurement systems, AC wins by a wide margin. If your B2B is wholesale-with-self-service, Plus B2B is now genuinely good.

This is the deepest architectural difference. It bites brands with non-standard checkout flows.

Shopify Plus checkout = Shopify Functions:

• Three function types: cart-and-checkout-validation, discount, delivery / payment customization
• Written in Rust or JavaScript, sandboxed, deployed via Shopify CLI
• Sub-50ms execution budget, runs on Shopify infra
• Powerful for: tiered discounts, conditional shipping rates, fraud blocks, B2B PO entry, custom payment routing
• Bounded: can’t add a custom field beyond what Checkout Editor exposes, can’t add a step, can’t reorder steps, can’t change checkout layout beyond Editor blocks, can’t hold-and-resume across sessions, can’t do server-side data lookups longer than 5ms

Adobe Commerce checkout = full Magento module:

• Override Knockout or Hyvä checkout entirely
• Add steps, add custom fields with validators, route based on cart contents
• Integrate ERP-driven shipping rates (live SAP query)
• Surface customer-credit balance live, hold-and-resume checkout across days
• Multi-warehouse split shipping with per-warehouse stock allocation
• Sample-cart workflows (free sample + paid item in same cart with separate fulfillment)
• No execution time limit — anything PHP can do

The Plus ceiling is real. Brands with subscription + one-time-buy mixed, B2B PO entry, multi-warehouse split-shipping, or sample-cart workflows hit it within 6 months. If checkout is your competitive advantage (or part of your B2B procurement integration), Adobe Commerce. If checkout fits the Shopify-Editor-plus-Functions model, Plus is faster to ship.

Different architectures for different problems.

Shopify Plus Markets: single storefront serving multiple regions. Currency conversion, market-specific pricing tweaks, regional tax, geolocation, language toggling. Best for: same brand, same catalog, different pricing/language per region. Tradeoff: catalog is shared — hiding products per market requires Markets-aware tagging or scripting. Works great for D2C brands with one catalog and 4-region pricing.

Plus multi-org / expansion stores: Plus includes 9 separate orgs, each its own admin / catalog / theme / staff accounts. Closer to true multi-store but at the cost of maintaining N catalogs in parallel (a SKU change has to propagate across orgs). PIM (Akeneo / Shopify Pro Sync) helps but adds tooling.

Adobe Commerce native multi-store: 1 codebase / 1 admin → N websites → N stores → N store views. Each level can independently override catalog (selective), pricing, tax rules, currency, language, payment methods, shipping methods, customer groups, even product attributes. Best for: retailers running different brands per region, B2B-and-B2C-per-region, fundamentally-different catalogs per market.

Real-world rule: 1 brand, same catalog, 4+ regions, region-specific pricing → Plus Markets is faster (3-month build vs 6-month). 1 brand, different catalogs per region OR B2B-and-B2C-per-region → AC saves the catalog-duplication tax indefinitely. Multi-brand parent company with 3+ brands → AC wins on shared infra. Hybrid — Plus Markets for the consumer brand + AC for B2B catalogs — is real at $100M+ but operationally heavy.

Both directions are well-trodden. Realistic enterprise numbers:

Shopify Plus → Adobe Commerce (most common at the $25M+ B2B band):

• Timeline: 9–15 months from contract to DNS flip. Catalog migration 4–6 weeks, B2B re-architecture 6–10 weeks, ERP / OMS / PIM re-integration 8–12 weeks, theme + checkout build 12–20 weeks, parallel-run + redirects 4–8 weeks.
• Cost: $300k–$1M for the build + $100–250k for ERP / OMS re-integration + $50–150k for first-year ops retainer. Total Year-1 outlay: $450k–$1.4M.
• Risk: URL redirects miss long-tail pages (drop SEO 15–30% for 6–8 weeks if redirects are sloppy); Shopify customer passwords don’t migrate (force reset); Shopify-app data (Klaviyo events, Yotpo reviews, Loop subscriptions) needs a separate migration plan. Subscription customers often need re-tokenization at the gateway.

Adobe Commerce → Shopify Plus (common when an AC store has outgrown its dev capacity):

• Timeline: 6–10 months. Faster than the reverse because Plus is more opinionated — less custom architecture to rebuild.
• Cost: $150k–$500k for the build + $50–150k for ERP re-integration via middleware + Plus license year-1.
• Risk: AC custom logic (Magento_Sales overrides, complex price rules, custom B2B workflow) often doesn’t fit Functions — re-scope or accept reduced functionality. Multi-store catalogs collapse to a single Markets store or expansion-store cluster.

Run both stores in parallel for 30–60 days behind a feature flag. Flip DNS only when the redirect map covers ≥98% of traffic, 50+ test orders pass on the new platform, and the support team has handled 5+ real customer issues on the new stack.

For non-Adobe shops: not really. For Adobe shops: significantly.

If you’re already running Adobe Analytics + Target (or AEM, or Real-Time CDP), Adobe Commerce’s native integration is a 3–6-month head start:

• Shared identity layer — no separate ID stitching
• Shared data layer — Analytics events fire from AC without a Tealium/GTM-style mapping layer
• Server-side personalization via Adobe Target on category / product / cart pages, native (not via 3rd-party connector)
• AEM Assets as the DAM for product imagery — no separate sync job
• Adobe Sensei AI for product recommendations + search + customer segmentation, native
• Real-Time CDP unified profile across web / app / email / paid media, native

This saves $200–500k in middleware / integration work + $30–80k/yr in ongoing connector / sync-tool fees.

If you’re NOT in the Adobe stack: the integration depth doesn’t matter — you’d be paying for Adobe Experience Cloud licenses you wouldn’t use. Shopify Plus integrates the Shopify ecosystem natively (Shopify Audiences for Meta/Google ads optimization, Flow for automation, Inbox for chat, Shop App for retention, Shop Pay) which is increasingly comparable in breadth to Adobe’s for D2C use cases.

Verdict: if you’re already an Adobe shop, AC’s integration is a quiet but expensive-to-replicate advantage. If not, this row is neutral — pick on B2B / customization / TCO instead.

Plus Academy is genuinely good. The app ecosystem is the bigger story.

Plus Academy = curated playbooks, certified-partner directory, dedicated Merchant Success Manager, quarterly business reviews, peer cohort access. For marketing-led ops teams, the playbooks (BFCM prep, growth experiments, replatform checklists) are 6–12 months of pattern-matching condensed into reference docs. Worth ~$30–80k/yr of consulting equivalent.

Plus apps are more nuanced:

• Pro: for ~80% of common features (loyalty, reviews, upsell, subscriptions, ERP sync, email, SMS, helpdesk), there’s a vetted app installable in 10 minutes. AC has ~5k extensions on the Adobe Marketplace + GitHub but quality varies wildly and most need a developer.
• Con: Plus apps are a recurring tax. A typical $50M Plus brand runs 8–12 apps at $1–5k/mo each → $100–600k/yr in app fees, indefinitely. Top of stack: Klaviyo $1k+/mo, Gorgias $500–2k/mo, Yotpo $500–2k/mo, Avalara $300–1k/mo, Sparklayer (B2B) $500–2k/mo, Loop / Recharge $300–1k/mo, Rebuy $500–2k/mo. Add custom Plus dev on top for things not covered.
• Hidden cost: apps inject JS that compounds. By 12 apps, page-load is 30%+ slower than vanilla. Removing apps to fix performance breaks features. This is the most common reason Plus stores migrate to AC at $100M+.

Verdict: Plus Academy alone is worth the Plus license at $50M+. The app ecosystem is a feature for years 1–3, a liability after that if you’re not disciplined about app curation.

Both can hit Lighthouse 90+ at $50M scale. Different paths.

Shopify Plus performance characteristics:

• Out of box (Dawn or Plus theme, vanilla): LCP ~1.8s, CLS ~0.03, INP ~150ms, Lighthouse ~85 mobile
• With 8–12 Plus apps installed (typical $50M brand): LCP drifts to 2.5–3.5s, CLS 0.08–0.15, Lighthouse 60–75 mobile — third-party scripts compound
• Hydrogen (Shopify’s React-based headless): LCP ~1.3s if engineered well, but adds an entire ops team to maintain
• Built-in CDN, image lazy-loading, automatic Brotli compression — all defaults are good

Adobe Commerce performance characteristics:

• Out of box (Luma theme): LCP ~3.8s, CLS ~0.12, INP ~280ms, Lighthouse ~45 mobile — bad
• AC + Hyvä theme (Tailwind + Alpine.js, ~95% less JS than Luma): LCP ~1.2s, CLS ~0.02, INP ~80ms, Lighthouse 95+ mobile — beats Plus defaults
• AC + PWA Studio (headless): comparable to Hydrogen, similar ops overhead
• Performance depends on dev discipline: a $50M AC store with poorly-tuned cache hits Lighthouse 60. A well-tuned one hits 95.

Verdict for $50M+ brands: AC + Hyvä is the long-term performance winner because customization happens in your codebase, not in installable scripts. Plus is faster to start but degrades as the app stack accumulates. If Core Web Vitals is a top-3 SEO ranking factor for your category (apparel, beauty, electronics), AC + Hyvä is the safer 5-year bet.

Plus Launchpad is the velocity advantage marketing teams cite most often.

Shopify Plus Launchpad: schedule a launch event (BFCM, product drop, flash sale, brand collab) that flips theme + price rules + collection visibility + script tags + email sequences at a chosen moment, then reverts at end-time. Marketing schedules it via the admin UI, no engineering ticket. The countdown / activation / rollback is atomic — either everything flips or nothing does. For a marketing-led ops team, Launchpad turns Black Friday from "dev sprint" into "calendar entry".

Plus Bulk Editor: mass-update SKUs / prices / inventory across markets. Plus Flow: visual automation builder for ops (fraud-flag → manual review, low-stock → reorder, repeat-buyer → loyalty tag). Together these eat 60% of what an engineering team would otherwise be ticketed for.

Adobe Commerce Content Staging (AC-only feature, not in Magento Open Source): preview / schedule / launch content + price changes by date range, similar to Launchpad in concept but with sharper scheduling controls (per-store-view, per-customer-group, conditional). Combined with Page Builder, B2B Rule Engine, Magento Cron, and (with engineering) Adobe Target rules, AC can do everything Launchpad does. The activation curve is steeper — Content Staging is more powerful but less marketer-friendly out of the box.

Verdict: if your bottleneck is "marketing wants to ship a campaign and engineering can’t turn around fast enough", Plus wins on velocity. If you have a strong engineering team that can wire Content Staging + B2B rules + Target rules into Adobe Workfront, AC is at parity but with steeper org investment.

Both are managed, but with very different control profiles.

Shopify Plus (managed SaaS):

• 99.99% uptime SLA, contractually backed
• Auto-scaling for Black Friday / Cyber Monday peaks — handled by Shopify, no capacity planning needed
• Zero DevOps work — no patch schedule, no PHP version pinning, no infra monitoring
• Trade: you can’t pin versions. Major checkout / admin changes are pushed to all stores simultaneously. If Shopify deprecates a feature you depend on (Linkpop, parts of Audiences, etc.) it disappears with limited notice.
• Status page transparency, dedicated Plus SRE escalation

Adobe Commerce Cloud:

• 99.9% standard SLA, 99.99% on the Pro infrastructure tier
• Managed but configurable — pin Magento version, schedule upgrades, choose PHP version within supported window
• Three-tier infra: integration / staging / production, all auto-deployed via Git
• Built on AWS (East / West / EU regions), Fastly CDN included, ECE-Tools for orchestration
• Trade: ~$50–80k/yr for the infra alone (separate from the Adobe Commerce license tier). Managed but you still own deployment-time issues — bad code goes live, you debug it.
• Cloudflare Magento Edge + on-edge B2B caching available as add-ons

If you self-host AC (skip Adobe Commerce Cloud): hosting on AWS / Hetzner / Cloudways runs $400–3k/mo for $50M-scale infra. You own all DevOps. Need either a competent in-house team or a $3–10k/mo managed-Magento retainer. Magento security patches must apply within 30 days or you risk Magecart-class breaches.

Verdict: Plus wins on operational simplicity. Adobe Commerce Cloud wins on configurability (pin versions, control rollouts) but at higher cost. Self-hosted AC wins on cost flexibility but trades operational responsibility.

It bites earlier than most enterprise teams expect, and it compounds with the GMV-based license fee.

How the Plus fee structure stacks:

• License floor: $2,300/mo OR 0.4% of monthly GMV — whichever is greater. This kicks in above ~$575k/mo GMV ($6.9M/yr) where 0.4% × monthly-GMV exceeds the $2,300 floor.
• Per-transaction fee on Shopify Payments: 0.15% of GMV. This is on top of the standard interchange rate (~2.4% + 30¢), not instead of.
• Per-transaction fee on third-party payment gateways: 0.20–0.25% of GMV — even higher. Most enterprise stores use Shopify Payments to avoid this hit.

The math at $50M GMV: license = max($2,300/mo, 0.4% × $4.17M/mo) = $16.7k/mo = $200k/yr just for license. Per-tx fee 0.15% × $50M = $75k/yr extra. Combined Plus platform cost: ~$275k/yr, before apps + dev + Plus Academy.

The math at $100M GMV: license $33k/mo = $400k/yr. Per-tx $150k/yr. Combined: $550k/yr.

The math at $500M GMV: license $1.67M/mo... wait, no — the Plus 0.4% fee caps at $40k/mo (= $480k/yr) by negotiation in most enterprise deals. Per-tx 0.15% × $500M = $750k/yr. Combined post-cap: ~$1.2M/yr. AC license at $500M GMV is ~$300–500k/yr — usually cheaper at this band, but the gap narrows once you account for AC’s ops cost.

Negotiation tip: at $50M+ Plus contracts, the 0.4% GMV-based fee is usually the negotiation lever. Plus reps will cap it (typically at the equivalent of 12 months prepay) and bundle Plus Academy / dedicated Merchant Success. Push for the cap before signing.

Yes — usually a few dozen brands at any time, almost all $100M+. The pattern works but operationally it’s not for the faint-hearted.

The pattern (real, not aspirational):

• Shopify Plus powers the D2C consumer brand — fast campaigns, Launchpad, Plus apps for marketing tools, mobile-first checkout
• Adobe Commerce powers the B2B / wholesale operation — companies, negotiable quotes, requisition lists, multi-buyer roles, custom approval chains, ERP-driven pricing
• Shared backbone: ERP (NetSuite / SAP / Microsoft Dynamics) is the system of record for inventory + customers + orders. PIM (Akeneo / Pimcore) feeds product data to both platforms. Identity service (Okta / Auth0 / custom) for unified login if needed.
• Customer experience: usually visibly two stores. Some brands keep them on subdomains (shop.brand.com for D2C, b2b.brand.com for wholesale); others on entirely separate domains. SSO between them is rare — buyers usually treat them as separate channels.

What goes wrong:

• Two ops teams, two release cycles, two sets of integrations to maintain — operationally heavy
• Promotions / pricing / inventory consistency between the two platforms requires real engineering (PIM is necessary, not nice-to-have)
• Customer service teams need training on both UIs
• Reporting consolidation requires a separate BI layer (Looker / Tableau / Mode) — neither platform’s native reporting handles cross-platform views
• Total cost is roughly platform-A + platform-B + 30% integration overhead

When it’s justified: $100M+ GMV with a hard split between B2C (consumer brand requiring marketing velocity) and B2B (procurement-style with deep workflow needs). Below $100M, picking one platform and paying for engineering on the gaps usually beats hybrid TCO.

Examples: several large beauty / apparel / supplement brands run this pattern; rare in industrial / distribution where AC alone serves both motions adequately.

Both reach roughly the same destination — the path is different.

Adobe Commerce B2B (native): ships a Companies module with a parent → child → buyer hierarchy, role-based purchase thresholds (e.g. Buyer can place orders up to $5k, Approver up to $50k, Company Admin unlimited), and an approval workflow that routes a pending order through the right approver before it’s placed. Cost: rolled into the Adobe Commerce license at $30k+/yr.

Magento Open Source: covered by extensions — Mageworx Companies ($299 + 12mo support), Aitoc B2B Suite (~$899), or BSS Companies (free + paid tiers). Combine with Aitoc Quote Workflow ($299–$799) to fill the approval gap. Total: $1–3k one-time vs $30k+/yr for AC.

The honest trade-off: AC ships a more polished UI, vendor-supported upgrades, and 24/7 SLA. OS extensions cover ~85% of the feature set at 5% of the cost — the remaining 15% is mostly "nice-to-have" admin polish. For most wholesale stores under $10M GMV, OS + extensions is the right call.

The shipped pattern across 40+ B2B builds:

• Buyer side: add items to a cart → click "Request a quote" instead of checkout → quote enters "Submitted" state. Buyer can attach notes ("we need this delivered split across 3 warehouses").
• Sales-rep side: internal admin queue shows new quotes. Rep opens the quote, can edit line-item prices, add discount %, override shipping, attach payment terms (Net-30 / Net-45 / Net-60), set expiry (default 14 days). Quote moves to "Counter-offered".
• Buyer review: email link → sees revised quote with line-by-line price changes highlighted → accepts or counter-counters (limit 2 rounds typically).
• Conversion: "Accept" converts the quote to a placed order with the agreed price + payment terms locked in.

PDF generation: auto-generated on every quote save, with company logo, customer billing/shipping address, line items + per-line pricing, tax breakdown, payment terms in the footer, expiry date in red. Library: Dompdf or mPDF for Open Source; native module for Adobe Commerce.

Expiry rules: stale quotes (past expiry) flip to read-only; buyer can request re-quote which spawns a new draft pre-filled with the old line items at current pricing.

Net-30 isn’t a payment method — it’s a credit-extension contract. The Magento mechanics:

1. Customer-segment configuration: "Verified Wholesale" customer group has Net-30 payment method enabled; new buyers default to "Card-only" until verified by AR.
2. Order placement: buyer chooses "Net-30 / Invoice me" at checkout. Order is placed in "Pending Payment" state — no card charge.
3. ERP push: order webhook fires to NetSuite / SAP / Tally / Odoo as a Sales Order with terms = Net-30. Invoice is generated in the ERP at fulfillment, not in Magento.
4. Invoice tracking: ERP pushes back invoice number + due date to Magento (so the buyer dashboard shows "Invoice #INV-1234, due Dec 15"). AR aging stays in the ERP.
5. Payment received: ACH / wire / cheque hits the bank → AR marks paid in ERP → ERP webhook marks Magento order "Paid" → auto-emails buyer the receipt.
6. Dunning: ERP sends 7-day, 14-day, 30-day-overdue emails. If 60+ days overdue, customer-group moves back to "Card-only" until cleared.

Critical: the source of truth for AR is the ERP, not Magento. Magento just shows the buyer their invoice status — the finance team operates entirely in the ERP.

Surprisingly granular. Magento’s native pricing stack lets you layer:

• Customer-group prices: per SKU, per group (Bronze / Silver / Gold / Platinum). 4 prices for 1 SKU is trivial; we’ve done 24 groups on a paint distributor.
• Tier prices: per group, per quantity-bucket. e.g. Gold tier: $10 at 1–99, $9 at 100–499, $8 at 500+.
• Special prices: per SKU, per customer (not just group), with start/end dates. Useful for "this one big buyer gets $7.50 forever".
• Cart price rules: conditional discounts ("any 100 SKUs from category X = 10% off") layered on top.
• Shared-catalog pricing (Adobe Commerce only): a complete alternate price-list per company-account. Open Source approximation: customer-segment + cart rules.

The wholesale reality — a single SKU might have 12 different prices across your buyer base. Magento handles that; Shopify B2B price lists hit limits around 4–5 tiers.

Performance note: with >500 active customer-group prices per SKU, indexing slows. Mitigation: keep group count under 30, push customer-specific overrides to "special prices" instead of new groups.

Different problems, different tools.

Requisition lists are for SKU lineups buyers reorder manually but frequently. The classic example: a hospital procurement officer maintains a "Monthly cleaning supplies" list with 47 SKUs. They open the list, click "Add all to cart", review quantities, place the order. Native Magento feature (Adobe Commerce); via Wyomind or Mirasvit on Open Source.

• Buyer is in the loop on every order
• Quantities can vary each cycle
• Lineup itself can be edited / shared with co-workers ("share with Procurement team")
• Multiple lists per buyer is normal (one for cleaning, one for office supplies, one for janitorial)

Recurring subscriptions are for SKUs that auto-replenish without buyer involvement. Example: a cleaning-services company auto-receives 20 cases of paper towels every Monday. No order placement, no buyer action — just a charge + ship event.

• Fully automated — buyer is not involved per-cycle
• Quantities are fixed (or fixed with skip-this-month buttons)
• Cadence is fixed: weekly / monthly / quarterly
• Best for fast-moving consumables with predictable burn

Stack: Magesterix Subscriptions, Aheadworks Subscriptions, or custom (built on Stripe Subscriptions or Razorpay for India). Avoid building from scratch — subscription billing has 30 corner cases (failed cards, prorated upgrades, paused subscriptions, regional tax).

Rule of thumb: ~70% of wholesale stores need only requisition lists. ~20% need both. ~10% (heavy MRO consumables) lean subscriptions.

The honest list of what works in 2026:

• NetSuite: direct integration via SuiteScript + REST API. Connectors: Patchworks (mid-market, $400–$800/mo), Celigo Integrator.io ($600–$1,200/mo), Folio3 NetSuite-Magento connector (one-time + support). Custom-built: $20–$40k for a clean implementation. Real-time stock + price; near-real-time order push.
• SAP (S/4HANA, Business One): IDoc-based (legacy) or OData (modern). Connectors: Pixafy SAP-Magento, Boltic SAP, Alumio. Custom: $30–$60k due to schema complexity. Batch sync (every 5–15 min) is the norm; real-time is achievable but pricey.
• Tally: XML-over-HTTP integration (Tally’s native pattern). Connectors: tdlexpert.com Tally-Magento bridge, custom modules from Indian dev shops ($3–$8k). Strong India-market choice; pairs with Razorpay for NEFT/IMPS payment.
• Odoo: XML-RPC API. Connectors: Magemodule Odoo bridge, EmiproTech Odoo-Magento. Custom: $10–$20k. Good for SMB wholesalers who run Odoo ERP + Magento commerce.
• Microsoft Dynamics 365: OData / Dataverse APIs. Connectors: Sana Commerce (built specifically for Dynamics), e-bridge by CData. Custom: $25–$50k.
• Zoho Inventory / Books: direct REST. Connectors: SkyVia, Zapier (small scale). Custom: $5–$15k. Good for SMB.

Decision rule: if you’re under $5M GMV with standard SKU master, a connector + middleware is faster (4–6 weeks). Above $5M with complex multi-warehouse / multi-currency / IDoc-based SAP, custom direct integration is more reliable and 3-year-cheaper despite the higher upfront cost.

5,000 lines is the high end of normal; 12,000 lines is doable with care; 50,000 lines needs a bulk-order asynchronous queue.

• 0–500 lines: synchronous. Submit → validate → cart → checkout in <5 seconds. No special handling needed.
• 500–5,000 lines: still synchronous but with a progress bar. Validation runs in chunks of 200 SKUs at a time to avoid PHP timeout. Total time: 10–30 seconds. Stock + price checks happen before cart insertion.
• 5,000–12,000 lines: asynchronous. CSV uploads → queue job → user gets an email with a "review your prepared cart" link in 1–3 minutes. SKU validation, price-snapshot, and stock-availability happen in the background. Buyer reviews + submits.
• 12,000+ lines: custom queue + multi-batch order (split into 2–3 separate orders to keep the order_items table sane). Often combined with multi-warehouse splitting.

Validation pre-submit: always show buyers (a) which SKUs aren’t found, (b) which are out of stock, (c) which have price differences from their list. Letting them edit / remove problem rows pre-submit cuts post-order disputes 80%.

Anti-pattern: never run a 5,000-line CSV through Magento’s standard add-to-cart events — you’ll trigger the catalog-rule indexer 5,000 times. Use direct quote-item insertion bypassing event observers.

Region-specific. Each has a clear preferred path.

ACH (United States): via Stripe Payments (offers ACH Direct Debit + Plaid micro-deposit verification), Authorize.Net eCheck, or NACHA-compliant gateways like Forte. Stripe is easiest to integrate (official Magento module + 2-day verification). Authorize.Net is cheapest at scale (~$0.10 per transaction vs Stripe’s 0.8% capped at $5).

SEPA Direct Debit (EU): via Stripe SEPA, Mollie SEPA, GoCardless. Mollie has the strongest Magento module + SEPA mandate management. GoCardless is purpose-built for B2B recurring debits and has the best webhook reliability for failed-payment retries.

NEFT / IMPS / RTGS (India): via Razorpay, PayU, or HDFC FirstData. Razorpay has the most mature B2B flow — supports NEFT, IMPS, RTGS, and UPI for sub-500k INR transactions. Direct bank transfers for >500k INR with reconciliation via virtual account numbers.

Bacs (UK): via GoCardless or Modulr. GoCardless dominates here.

Reconciliation pattern: all bulk-payment methods are async — the order is placed in "Payment Pending" state, buyer sees the bank-transfer instructions or initiates the debit, payment confirmation comes back via webhook 1–3 days later, order moves to "Paid" and fulfillment kicks off. Build the UX around this delay — pretending it’s instant breaks trust.

Different shapes of business, not "Magento better" or "Shopify better".

Shopify Plus B2B wins when:

• B2B is <30% of revenue and you’re primarily D2C
• One buyer per company (no role hierarchy)
• Quote workflow is single-level approval at most
• Customer pricing is "wholesale price + Net-30" with no per-SKU complexity
• You don’t need real-time ERP integration (5-min Celigo batches are fine)
• Time-to-launch matters more than long-term flexibility

Magento wins when:

• B2B is >40% of revenue (or pure-B2B)
• Companies with multi-buyer roles + multi-step approval are common
• Customer-segment pricing has 5+ tiers or per-SKU per-customer overrides
• ERP integration is real-time-critical (NetSuite / SAP / Tally / Odoo)
• Bulk-order CSV (5,000+ rows) is a frequent buyer flow
• Requisition lists + recurring orders are core to retention
• You need ACH (US) + SEPA (EU) + NEFT (India) on the same store

The Shopify Plus B2B 2025 update narrowed the gap: companies, customer-specific catalogs, Net-30, draft orders all shipped. But the gaps that remain — multi-step approval, 24+ pricing tiers per SKU, real-time IDoc-based SAP integration, 5,000-row CSV with pre-submit validation — are the gaps that matter for serious wholesale.

Wholesale stores often need products that exist only for specific buyer-segments — restricted-use SKUs, OEM-only items, exclusive bulk packs, or trade-channel pricing that shouldn’t be visible to anyone else.

Magento Open Source mechanics:

• Customer-group product visibility: via Aitoc Customer-Segment Catalog or BSS Hidden Categories ($199–$499). Each product has a "visible to groups" flag — logged-out users + non-matching groups see a 404 or redirect to login.
• Category-level visibility: hide entire categories from anonymous + non-trade groups. Trade buyers see "Wholesale Only" subtree; everyone else doesn’t.
• Login-walled storefront: entire store requires login. New visitors see only a login page + "request trade account" form. Used by pure-B2B distributors who don’t want their catalog scraped or visible to retail customers.
• Per-company custom catalog (Adobe Commerce Shared Catalogs): each company-account gets its own catalog snapshot — SKUs they shouldn’t see are simply not in their feed.

SEO consideration: hidden trade catalogs should return HTTP 404 (not 403) for non-authorised users to stay out of Google’s index. Pair with robots.txt deny rules for the URL paths and a separate sitemap that excludes the trade-only sections.

Pricing visibility: a common ask — show product but hide price until login. Native cart-rule: "Display price = $0 / login to see" with a "Request quote" CTA replacing the price. Done with a small Hyvä template override.

Common path. Risk is real but quantifiable.

The typical custom-portal stack: Laravel / Django / Rails app + MySQL/Postgres + manual ERP scripts. Built 5–10 years ago, hard to hire for, no upgrade path, every new feature is a custom build. Maintenance is a tax on the dev team.

Migration plan (12–20 weeks):

1. Data audit (week 1–2): companies, buyers, customer-group pricing rules, requisition lists, open quotes, AR balances. Map to Magento entities — companies → B2B Companies module, buyers → customers, segment pricing → customer-group prices.
2. Feature parity matrix (week 2): what does the custom portal do that Magento doesn’t out-of-box? Build the gap list. Usually 6–12 items, 3–5 of which need custom modules.
3. Magento + extensions setup (week 3–5): base Magento, Hyvä theme, B2B extensions, ERP connector, payment gateways.
4. Custom-portal data export (week 6): SQL dumps + CSV exports of all customer + order + pricing data. Validate counts.
5. Magento data import (week 7–9): via dataflow / API / direct SQL. Spot-check 100 customers + 50 orders for accuracy.
6. Parallel run (week 10–14): both portals live. New orders go to Magento; old portal is read-only for AR / reporting. Buyers get a "we’ve moved" email + reset-password link.
7. Cutover (week 15): DNS flip. Old portal stays read-only for 90 days for any AR queries.
8. Stabilisation (week 16–20): bug fixes, buyer training, ERP sync tuning.

Risk hotspots: (1) password migration — you can’t move hashes if the algos differ; force a reset email at first login. (2) saved-card tokens — need to re-tokenise at the new gateway via account-updater service. (3) custom-portal-only URLs — build a redirect map covering >95% of indexed traffic before DNS flip.

Real ranges from 40+ shipped projects:

Greenfield Magento Open Source B2B (no migration):

• Timeline: 12–16 weeks build + 4 weeks stabilisation
• Build cost: $30k–$80k depending on segment-pricing complexity + ERP integration depth
• Extensions: $3k–$8k one-time (Companies, Quote Workflow, Subscriptions, etc.)
• Hyvä theme licence: $1,000 one-time
• Hosting: $400–$1,500/mo (Cloudways / dedicated)
• 3-year TCO: $80k–$200k

Migration from Shopify Plus / SAP Hybris / custom portal:

• Timeline: 16–24 weeks build + 4 weeks parallel run + 4 weeks stabilisation
• Build cost: $50k–$140k
• Data migration: $10k–$30k (companies, buyers, pricing, AR balances)
• ERP re-integration: $15k–$50k depending on system
• 3-year TCO: $130k–$320k

Adobe Commerce B2B (vendor-supported):

• Same build cost as Open Source + Adobe Commerce license $30k–$80k/yr based on GMV
• 3-year licence: $90k–$240k on top of build cost
• Pays for itself when (a) you’d need 24/7 SLA anyway, or (b) you’re >$10M GMV with full B2B usage

Below $5M B2B GMV: Open Source + extensions is the right call. $5–$10M: close call — depends on team. Above $10M: Adobe Commerce + Cloud often wins on operational cost despite the licence.

Cheapest B2B build that’s not a regret: $30k. Anything cheaper skips ERP integration or quote workflow and you’ll rebuild within 18 months. The honest floor.

Apples-to-apples at $5M GMV with 5k SKUs and a B2B mix:

• BigCommerce Pro / Enterprise: $399–$2,000+/mo plan + B2B Edition (~$2,000+/mo) + apps ($300–$800/mo for ERP, search, reviews, tax) + theme dev ($5k–$15k one-off). Annualised: ~$50k–$80k/yr excluding payment-processor fees (BC takes 0% per-tx; processor still does 2.4–2.9%).
• Magento Open Source: $0 license + hosting ($300–$1,500/mo on AWS / Cloudways / managed) + DevOps retainer ($1,500–$5k/mo) + extensions ($3k–$10k one-off + $200–$500/mo updates) + theme on Hyvä ($8k–$25k one-off). Annualised: ~$40k–$80k/yr.
• Adobe Commerce: $30k–$60k/yr license at this GMV band + $20k–$50k hosting (Adobe Commerce Cloud or self-managed) + dev. ~$80k–$140k/yr.

Net: BigCommerce Pro vs Magento Open Source on Hyvä is roughly the same money at $5M GMV. Adobe Commerce is the premium tier. Move the GMV to $25M and the gap inverts — Magento OS gets cheaper relative to BC Enterprise.

For a typical mid-market store (1k–10k SKUs, B2B + B2C, 2 years of order history): $15k–$30k and 8–12 weeks end-to-end.

Phases:

• Weeks 1–2: Discovery + architecture + Magento + Hyvä install + dev environment.
• Weeks 3–5: Catalog + customers + orders migration via Cart2Cart / LitExtension or a custom export-import. URL redirect map (BC URLs differ from Magento’s — SEO-critical).
• Weeks 4–7: Theme rebuild on Hyvä (BC Stencil themes don’t port; Hyvä is the modern replacement).
• Weeks 5–8: Payment / shipping / tax reconnection, B2B feature setup, app replacements (each BC app needs a Magento equivalent).
• Weeks 8–10: ERP / WMS / ESP integrations.
• Weeks 10–12: UAT, performance tuning, cutover with 14-day rollback window.

Faster & cheaper paths exist for very simple stores ($5k–$10k, 6 weeks). Bigger / heavier-customization stores creep to $50k+ and 16 weeks — budget accordingly.

BigCommerce B2B Edition (powered by BundleB2B, owned by BC) is real, well-built, and shipped reliably — but it’s an add-on (~$2,000+/mo on top of plan, often Enterprise-tier only). Magento native B2B (Open Source extensions or Adobe Commerce-bundled) is deeper at the seams.

Where they’re comparable:

• Companies / sub-accounts / role hierarchy — both do this
• Customer-segment pricing — both do this
• Quote workflow — both do this; Magento quote-to-order conversion is more flexible
• Net-30 / Net-60 invoicing — both do this

Where Magento goes deeper:

• Catalog gating by company / category / SKU / segment — Magento has the granularity, BC’s rules engine is shallower
• Multi-step approval flows with custom logic — Magento can do almost anything via plugins; BC’s approval rules are template-bound
• Tiered pricing matrices with quantity breaks per company — both do this; Magento doesn’t flinch at 50 segments × 10k SKUs
• ERP-driven catalog (real-time stock, real-time price) — Magento self-hosted lets you do this directly; BC needs API-bound apps and runs into rate limits

If your B2B is straightforward, BC B2B Edition is fine. If your business rules are weird, Magento.

Stencil is BigCommerce’s theme framework: Handlebars templates + SCSS + a few Stencil-specific helpers + the Storefront API for client-side data. It’s well-documented and powerful for theming.

What Stencil handles cleanly: layout customization, component swaps, custom widgets, A/B-able UI, custom checkout (single-page checkout v3 is editable), custom storefront API consumers.

Where Stencil hits ceilings:

• Server-side business logic. You can’t hook into BC’s pricing engine, cart-rules engine, or tax engine the way you can with Magento plugins. Workaround: build an app that proxies the Storefront / Cart APIs — works, but adds latency and a hosting bill.
• Custom DB columns / tables. No direct DB access — you store custom data in metafields (limited size) or in your own backend service synced via API.
• Heavy catalog logic. Real-time stock / real-time price / customer-driven catalog visibility — doable via Channels API but rate-limit-bound.
• Complex multi-currency rules. BC handles standard multi-currency well; weirder rules (per-country tax-inclusive vs tax-exclusive on the same SKU) need apps or workarounds.

Magento gives you full PHP access — you can rewrite the cart engine if you genuinely need to. Different toolboxes.

BC publishes per-plan rate limits on Storefront, Catalog, Cart, and Checkout APIs. Rough numbers (subject to change):

• Storefront API: ~200 req/sec on Standard, 450 on Pro, custom on Enterprise
• Catalog (V3) API: ~150 req/sec sustained
• Cart / Checkout APIs: lower, with stricter burst limits

When they bite:

• Catalog sync from ERP. If NetSuite pushes 8k SKU updates an hour during inventory recon, you’ll throttle. Workaround: batch + queue + retry.
• PIM-driven content updates. Same problem.
• Headless storefronts. Each PDP load makes ~5–10 Storefront API calls; high-traffic homepage = limit-bound.
• 3rd-party app stack on Pro+. Loyalty + reviews + search + abandoned-cart all eat the same per-store budget.

Magento self-hosted has no API limits beyond your own infrastructure — bottleneck moves to MySQL, app server, cache. You control the dial. Different problem space, but the dial is yours.

Magento multi-store is the gold standard: one admin, multiple stores, multiple websites, multiple store views, shared customers / catalog / inventory or independent — you choose. Three brands sharing 80% of catalog with separate themes / domains / currencies / tax rules — native.

BigCommerce Multi-Storefront (released 2022) is real and improving but constrained:

• Available on Pro + Enterprise plans only
• Each storefront shares the catalog; per-storefront pricing / inventory rules are limited
• Customer accounts can be shared or per-storefront, configurable
• Separate themes per storefront, separate checkout

For 2–3 closely-related brands sharing most catalog: BC Multi-Storefront is fine and easier than Magento (no DevOps multiplier).

For 5+ stores, deeply-different catalog rules per store, B2B + D2C splits, country-specific tax / pricing logic: Magento bends, BC starts working against you.

BigCommerce defaults to good Core Web Vitals on Stencil + their CDN: LCP under 2.5s on average for stock themes, decent INP, low CLS. SaaS hosting is tuned by their infra team — you don’t need a performance specialist.

Magento default Luma is poor on CWV. Magento on Hyvä is excellent: LCP under 1.5s achievable with proper hosting + caching (we’ve hit 1.0s on production stores). But it requires the right setup — Hyvä theme + Varnish + Redis + a competent host + optimized images. Without those, default Magento can hit 5s LCP and tank Lighthouse.

Net: BC is good-by-default. Magento is great-with-effort. If your team can’t / won’t invest in DevOps, BC is the safer CWV bet. With a Hyvä team, Magento beats BC on raw speed.

Both can rank well; both can rank badly. Differences in 2026:

• URL control: Magento gives you near-total URL flexibility (URL rewrites table, per-store URL keys). BC gives you URL key control on products / categories / pages but the underlying URL structure (/products/, /categories/) is fixed without a custom domain hack.
• Schema markup: Magento on Hyvä with the schema modules I publish (Product, Breadcrumb, FAQ, Article, Organization) is best-in-class. BC ships basic Product schema; deeper schema needs apps.
• Sitemaps: both auto-generate; Magento can be customized (segmented sitemaps per store, hreflang sitemaps); BC’s is fine but rigid.
• Hreflang: Magento native via store views or via a hreflang module. BC supports hreflang in Multi-Storefront but the implementation is shallower.
• Page speed: covered above — both can be excellent.
• Custom landing pages, blog, programmatic SEO: Magento with CMS pages + the right modules gives you a programmatic SEO surface. BC’s blog is basic; large landing-page programs need 3rd-party apps.

For pure SEO surface area, Magento has more levers. For getting-it-right-without-thinking SEO, BC is fine.

BigCommerce: BC handles infrastructure, security patching, uptime, Black-Friday scaling, PCI scope. Risk shifts to vendor risk — pricing changes, deprecations, feature ceilings you can’t code around. Outages are BC’s problem (and rare).

Magento self-hosted: you own infrastructure risk. Hosting + DevOps + security patching + WAF + Black-Friday scaling + PCI compliance scope are on you (or your hosting partner). Upside: no platform risk, no surprise pricing shifts, no “feature deprecated next quarter”.

Adobe Commerce Cloud: middle ground. Adobe handles infra (mostly), you handle code. More expensive ($30k+/yr); fewer DevOps headaches.

For a 5-person ecom team without DevOps capacity, BC is the lower-risk choice. For a 20+ person team with engineers, Magento is sustainable.

BigCommerce: PCI DSS Level 1 certified at the platform level. As a merchant on BC, you generally complete SAQ-A (the lightest self-assessment) because cardholder data never touches your servers. Easy.

Magento self-hosted: depends on your checkout. Use a hosted payment gateway (Stripe Checkout, PayPal, Braintree hosted-fields) and you’re SAQ-A or SAQ-A-EP. Use server-side card capture (rare in 2026, not recommended) and you’re SAQ-D — full PCI scope, audits, quarterly scans, expensive.

Adobe Commerce: similar to Magento OS; the official Adobe Commerce + hosted-gateway setup is SAQ-A or SAQ-A-EP.

For 95% of merchants on either platform, PCI is SAQ-A — equivalent burden. For high-volume merchants who need cardholder data residency for fraud / chargeback workflows, the equation gets more nuanced.

NetSuite + BigCommerce: well-trodden path. Celigo, Boomi, Jitterbit all have BC + NetSuite connectors. Out-of-box covers items, customers, orders, payments. Custom logic = paid customization on the iPaaS side. Real-time-ish (10–30 min lag).

NetSuite + Magento: equally well-trodden. Celigo, Boomi, plus Magento-specific connectors (MageWorx, Magenest, custom). Real-time achievable via direct DB or queue subscription.

SAP + BigCommerce: doable via SAP Commerce Cloud (different product), or SAP ↔ iPaaS ↔ BC. Less polished than NetSuite path.

SAP + Magento: SAP’s own ecom-bridge tools target Magento natively in some setups (Hybris connector); B1 / S/4HANA ↔ Magento via Boomi or custom.

Odoo + either: Odoo has reasonable connectors for both. Magento has the longer history.

Net: BC is fine for stock NetSuite. Magento is more flexible for custom ERP rules (especially when you need DB-level access for stock-allocation logic).

BigCommerce: native VAT / GST / US sales-tax via Avalara AvaTax integration (most merchants), TaxJar (cheaper), or built-in basic tax tables. EU VAT-MOSS / OSS supported. UK VAT post-Brexit handled via tax tables. Generally clean for under 10 jurisdictions; gets fiddly past that.

Magento: same toolbox (Avalara, TaxJar, Vertex on Adobe Commerce, native tax tables). More flexibility on tax-rule edge cases — B2B tax-exempt customers, mixed product-class rules, country-of-origin-driven rates. Adobe Commerce + Vertex is the heavy-duty enterprise stack.

Where Magento wins: complex tax-class logic per customer-segment, mixed B2B / B2C rules in the same checkout, country-of-import-driven HS-code calculations.

Where BC wins: simple multi-region D2C with standard Avalara rules — setup is faster, fewer edge-case bugs.

"Break" is too strong, but it does become operationally painful. Specifically:

• Database: WooCommerce stores products in wp_posts + wp_postmeta, which is fine for blog posts but a poor fit for a 10k-row catalog. Variant SKUs explode the meta table. By 10k SKUs the meta table is often 5M+ rows, making attribute filtering slow.
• Search: default WP search is LIKE %term% on titles. Past a few thousand products you need ElasticPress or Algolia — both are paid plugins or external services.
• Admin: the products list pagination starts choking at 5k. Bulk-edit, bulk-import, and even category-tree operations get slow. Operators feel it daily.
• Indexes: there’s no Magento-style indexer. Woo recomputes things on the fly, so each cart-rule, tax-rate change, or attribute update slows query response.

Magento was built for catalogs. EAV plus dedicated tables for inventory, prices, and search keep query times stable from 10k to 200k SKUs. The platform-architecture difference is real — not marketing.

$1M is roughly the crossover point. Below it, Woo is clearly cheaper; above it, Magento amortises better. Numbers:

WooCommerce 3-year TCO at $1M: Woo plugin $0. WordPress hosting (Cloudways / Kinsta WooCommerce plan) $80–$300/mo → $3k–$11k. Paid plugins (Yoast Premium, ACF Pro, WPML, Wholesale Suite, AffiliateWP, payment add-ons) $300–$2k one-time + $400–$1.5k/yr renewals → $1.5k–$6.5k. Theme $80–$500. Dev work $5k–$25k. Total: ~$10k–$45k.

Magento Open Source 3-year TCO at $1M: Magento $0. Hosting (Cloudways Magento / dedicated) $200–$700/mo → $7k–$25k. Hyvä theme licence $1,000–$2,000. Dev build $15k–$45k. Ongoing dev $1k–$3k/mo retainer → $36k–$108k. Search / monitoring $100–$400/mo → $3.5k–$14k. Total: ~$60k–$190k.

So at $1M GMV WooCommerce is 4–5x cheaper. The crossover happens because Magento’s fixed dev cost (build + retainer) doesn’t scale up much from $1M to $10M, but Woo’s app/plugin / hosting cost does scale up sharply (especially when you add WPML, WP Rocket, ElasticPress, Wholesale Suite, etc.) by $5M. The two lines cross around $1M–$2M.

Well-trodden path. Realistic numbers for a typical Woo store at 5k–15k SKUs:

• Timeline: 6–12 weeks for a clean Hyvä-themed Magento rebuild, including data import. Faster (4 weeks) for sub-1k SKUs with a stock theme; longer (16+ weeks) if you’re also re-platforming PIM / ERP or have heavy Woo customisations.
• Cost: $12k–$50k for the rebuild + data migration. Tools like cart2cart ($300–$1.2k) handle the bulk product/customer/order transfer; the rest is dev time on theme / payments / shipping / SEO redirects.
• What breaks: (1) WP-specific URL patterns don’t map 1:1 to Magento — you need 301-redirect maps for every product/category, (2) WP user passwords are bcrypt with a different salt, so users have to reset on first login, (3) Yoast SEO meta migrates only if you use a custom mapping plugin, (4) pretty permalink slugs in WP often clash with Magento’s URL rewrite logic.

The migration is more about SEO continuity than tech. Map redirects for every indexed URL, run both stores parallel for 30 days behind a feature flag, validate the redirect map covers ≥98% of organic traffic, then cut DNS.

Viable, but rare and only worth it for content-led businesses with substantial blog traffic and serious commerce needs.

Architecture: WordPress at blog.brand.com (or brand.com/blog/ via reverse proxy) for the editorial side. Magento at shop.brand.com (or brand.com/shop/) for commerce. Shared header/footer via a small JS include or shared theme tokens. Single sign-on optional.

What you gain: WordPress’s editorial tooling (Gutenberg, ACF, Yoast, custom-post-type ecosystem) for content; Magento’s catalog + B2B + multi-store for commerce. Each platform plays to its strength.

What it costs: two CMSes to patch, two hosts (or two Docker stacks), two deploy pipelines, two sets of plugins/extensions to keep up to date. Add ~$300–$1k/mo to ops. Internal linking between blog and shop has to be deliberate (ideally with shared canonical / hreflang strategy across the subdomains).

Who actually does this: media-driven brands (e.g. cooking sites with merchandise, fitness influencers with supplements, magazine-led DTC brands), enterprises with separate "content marketing" and "commerce" P&Ls, and agencies serving both audiences. For most stores, picking one platform end-to-end is cheaper and simpler.

WooCommerce can do basic B2B with the right plugins (Wholesale Suite, B2BKing, WholesaleX) but the gaps vs Magento Adobe Commerce B2B are real:

• Companies + sub-users: Magento has a Company entity with multiple buyers under one account (each with role/permission). Woo plugins fake this with WP roles or an ACF-driven org table — works, but the data model is bolted on.
• Quote workflow: Magento native (request → negotiate → convert to order). Woo: limited to the "Request a Quote" plugin, which emails a draft order — no multi-step approval, no comment thread.
• Requisition lists: Magento native. Woo: not really — saved carts, sometimes.
• Tiered customer-specific pricing: Magento handles unlimited price tiers per customer + per SKU + per quantity. Woo: customer-group pricing is fine; per-customer-per-SKU gets awkward at scale.
• Net-30 / payment terms: Magento allows custom terms per company (Net-15, Net-30, Net-45). Woo: deferred-payment plugins exist but require manual reconciliation.
• Approval workflows: Magento allows multi-level (requester → manager → finance). Woo: nothing native.

Verdict: B2B share >25% of revenue → Magento. B2B <25% with simple "wholesale price + Net-30" mechanics → Woo + Wholesale Suite is workable.

Possible, but architecturally fragile vs Magento.

WooCommerce multi-currency: via plugins like CURCY, WooCommerce Currency Switcher, or WPML’s WooCommerce Multilingual (which bundles a currency switcher). All do the same thing — convert prices on display, optionally per-region. Limitations: no per-SKU per-currency price control without bolt-on plugins; tax handling per region can break with mismatched plugin combos; checkout sometimes shows the wrong total under load.

WooCommerce multi-store: WordPress Multisite + WooCommerce + a sync plugin (e.g. Multilingual Press, Octolize Multistore). Each "store" is a separate WP site sharing users and (optionally) a master catalog. Pros: WP-native. Cons: catalog sync is plugin-dependent and breaks with bigger Woo updates; tax / shipping has to be configured per site; admin operators have to context-switch.

Magento multi-store: one admin → N websites → N stores → N store views. Each axis can override catalog, pricing, tax, currency, language, payment, shipping. Designed-in, not bolted-on.

Rule of thumb: 1–2 currencies, 1 region → Woo is fine. 3+ regions with different tax / shipping / catalog → Magento. The Magento setup is more upfront work but won’t fail in production.

Out-of-the-box Woo wins; with proper engineering, Magento + Hyvä wins.

• WordPress + WooCommerce + Astra/Kadence theme + WP Rocket: LCP ~1.6–2.2s, CLS ~0.05, INP ~150–200ms. Lighthouse mobile ~80–90. Achievable in days.
• Magento + Luma (default): LCP ~3.8s, CLS ~0.12, INP ~280ms. Lighthouse mobile ~45. Painful out of the box.
• Magento + Hyvä theme: LCP ~1.0–1.4s, CLS ~0.02, INP ~70–90ms. Lighthouse mobile ~95+. Takes 4–8 weeks to stand up but stable for years.

The hidden Woo issue: WP plugin sprawl. A typical mid-market Woo store accumulates 25–40 plugins over 2 years. Each adds JS, CSS, and DB queries. By year 3, LCP often drifts to 3–4s and Lighthouse drops to 50–70. Removing plugins to fix performance breaks features.

The hidden Magento issue: if you build on Luma without theme work, you’ll never beat 70 Lighthouse without buying perf-optimization plugins of dubious quality. Hyvä is the right call for any new Magento build.

Yes, but less than WP-people claim, and it doesn’t apply equally to ecommerce.

Where WordPress SEO genuinely wins: blog content, programmatic content pages, internal linking via Yoast/Rank Math’s automated suggestions, schema-markup automation via Yoast, and Gutenberg-driven landing pages with structured data baked in. For content-marketing-heavy sites, WordPress is best-in-class.

Where Magento catches up: product/category SEO. With the right modules (mage2kishan AdvancedSeo, StructuredData, Hreflang, FilterSeo, Crosslinks), Magento generates better category-landing-page SEO than Woo because the catalog data model exposes more programmatic levers (per-attribute landing pages, faceted-nav SEO without duplicate-content traps, native hreflang per store-view).

What actually moves rank: Core Web Vitals (Magento + Hyvä wins), URL structure (both controllable), structured data (both controllable), internal linking (WP wins for content, Magento wins for catalog), domain authority (platform-agnostic).

Verdict: content-marketing-led business → Woo SEO advantage matters. Catalog-led ecommerce business → roughly a wash, with each platform’s native strengths balancing out.

Different operational profiles.

Managed WP hosts (WP Engine, Kinsta, Cloudways WordPress, SiteGround):

• $30–$300/mo for sub-$1M GMV stores; $300–$1,500/mo for $1M–$5M.
• Auto-updates for WP core / PHP, automated backups, staging, CDN, page-cache, security firewall.
• Limitations: hosts often disable certain plugins (heavy ones, security-risky ones); SSH access is limited; you can’t pin PHP version freely.
• Best fit: store owners who don’t want to manage ops, willing to pay 2–3x raw VPS cost for the convenience.

Magento on Hetzner / AWS / Cloudways:

• Hetzner dedicated: $50–$200/mo for sub-$1M; $200–$600/mo for $1M–$5M. AWS / GCP: 2–4x that.
• Cloudways Magento: $50–$700/mo, similar managed-feel to WP Engine but with more Magento control.
• You own: PHP version, MySQL tuning, Redis cache, Varnish layer, OpenSearch indexing, security patches.
• Best fit: operators with a dev or retainer who value control and lower long-run cost.
• Adobe Commerce Cloud: $40k–$200k/yr for managed Magento — the WP-Engine-equivalent, but expensive.

Verdict: Woo hosting is "set and forget" cheaper at <$1M GMV. Magento hosting is meaningfully cheaper at >$5M GMV but requires real ops capability.

Roughly equivalent, as long as both use tokenized payment forms.

WooCommerce: with Stripe / Braintree / PayPal / Square (the standard payment plugins), card data never touches your server. PCI scope is SAQ A — the easiest tier, basically a self-attestation. Cost: $0 extra. With on-server gateways like Authorize.Net AIM (rare on Woo, but possible), PCI scope jumps to SAQ A-EP — quarterly ASV scans, $5k–$25k/yr in compliance work.

Magento: identical situation. With Stripe Elements / Braintree Hosted Fields / Adyen drop-in / PayPal smart buttons, you stay in SAQ A. With on-server payment forms (rarely seen on modern Magento), you move to SAQ A-EP or SAQ D.

Where Magento has a small edge: Adobe Commerce ships with PCI-DSS Level 1 attestation for hosting; Adobe Commerce Cloud is PCI-DSS Level 1 certified at the infrastructure layer. WooCommerce hosting is host-dependent — managed WP hosts (WP Engine, Kinsta) are usually PCI-DSS Level 1 at the infra layer too, but you have to confirm with each host.

Verdict: not a real differentiator in 2026. Both platforms with tokenized gateways = SAQ A.

Both can. Different paths.

WooCommerce ERP integration: mostly via middleware (Celigo, Workato, Boomi) or app-store connectors (e.g. WP-CRM, NetSuite for WooCommerce by Folio3). Pros: connector vendor handles schema diffs and auth refreshes. Cons: middleware costs $400–$2,000/mo indefinitely; custom field mappings often require service-desk tickets; real-time sync rare (most are 5-min batches).

Magento ERP integration: direct API integration is the norm. Magento’s REST + GraphQL APIs cover orders, customers, inventory, products. Custom modules can expose ERP-specific webhooks. Pros: no middleware tax (one-time $20k–$80k dev cost), real-time sync achievable, full control over data shape. Cons: you own the integration — when SAP changes its IDoc format or NetSuite deprecates a SuiteScript, you’re fixing it.

For Indian ERPs (Tally, Zoho Books): Tally Magento connectors are mature (Cynoteck, Gateway, Adobe Marketplace listings). Tally Woo connectors exist (TallyXL, others) but tend to be batched 1–6 hour syncs. For real-time inventory + orders, Magento has the edge.

Rule of thumb: under $1M GMV with stock NetSuite / Tally → Woo + middleware is faster. Above $5M GMV with custom SAP / NetSuite workflows → Magento direct integration is more reliable and 3-year-cheaper.

Both punt to specialised services for serious multi-jurisdiction tax. The differences are in how easy that integration is.

WooCommerce tax: built-in tax engine handles US sales tax (manual rates, or with WooCommerce Tax / Avalara plugin), EU VAT (manual config or with EU VAT Compliance plugin), UK VAT, Canadian GST. For complex setups (marketplace facilitator rules, B2B reverse-charge, OSS reporting), the standard path is Avalara, TaxJar, or Quaderno — all have first-party Woo plugins.

Magento tax: built-in tax-rate / tax-rule engine is more flexible (per-region, per-customer-group, per-product, per-store-view). Native support for tax-exempt customer groups, tax classes per attribute, and OSS reporting with the right module. Avalara, TaxJar, Vertex have official Adobe-Marketplace integrations.

EU VAT specifically: Magento handles distance-selling thresholds, OSS reporting, B2B reverse-charge natively or via official extensions. Woo needs a third-party (Vatify, Quaderno, EU VAT Compliance) for OSS / reverse-charge — works but adds plugin surface area.

India GST specifically: Magento has native + community modules (GST Manager, India GST by Webkul) covering CGST / SGST / IGST splits, HSN codes, e-Way bill linkage. Woo has plugins but they’re thinner.

Verdict: US-only retailer with simple tax → Woo + Avalara is the fastest path. EU + cross-border B2B, or GST-heavy India operation → Magento is more flexible.

Use multi-store when your storefronts share most of the catalog, customer base, or admin operations — you get one upgrade, one extension stack, one hosting bill, and surgical per-store overrides where needed. Use separate installs when storefronts are run by different teams, have totally distinct catalogs, or need fundamentally different stacks (e.g. one Hyvä, one Luma headless). 90% of cases we see are multi-store wins — the maintenance and SEO consolidation alone usually justify it.

Magento has three scopes:

• Website — isolation boundary for customers, carts, orders and (by default) prices. Use one website per legal entity / region with separate carts.
• Store — root-category boundary. Use multiple stores per website when you need different catalog trees (e.g. brand A vs brand B sharing a checkout).
• Store view — locale boundary. Use one per language inside the same store (e.g. EN, FR, DE views of the EU store).

Wrong-scope configuration is the #1 source of multi-store pain. We map the hierarchy in the audit before any code is written.

Magento supports multiple currencies natively. We typically wire it up like this: (1) Allowed currencies set per website. (2) Live FX feed (ECB, OpenExchangeRates, fixer.io) with cron import every hour. (3) Per-currency rounding rules and price-display formatting per locale. (4) Optional fixed prices in customer-group + website scope to avoid FX drift on premium SKUs. Customers see only the currency for their region; admins see all currencies side-by-side in reports.

Three rules: (1) Every URL must reference every other locale variant of itself, including a self-reference. (2) Each variant must point back — bidirectional. (3) Always include x-default. We generate hreflang server-side per URL (not via JS), validate it on every deploy with Screaming Frog, and emit it on canonical URLs only. Common foot-guns we prevent: hreflang on non-canonical URLs, region-only tags without language, and hreflang loops between cross-linked storefronts.

Both. Magento has a customer account scope setting (Stores > Configuration > Customers > Account Sharing Options): set to Global for one account across all websites, or Per Website to isolate. Most multi-region setups want per-website isolation (so a UK customer can’t accidentally order at US prices), while same-language sibling stores often share globally. Switching this setting after launch is painful — we always decide it upfront in the audit.

Done right, no. The Magento application is shared in memory; each store view just changes what gets rendered. Done wrong — with bloated core_config_data, runaway URL rewrites per store, or unscoped extension queries — multi-store can be measurably slower. We size Redis + Varnish for the storefront count, scope every config to the right level, and load-test each store view separately before launch. We commit Lighthouse 90+ on every storefront, regardless of count.

Payment method config is scoped per website. We typically enable: iDEAL + Bancontact for NL/BE, Klarna + Sofort for DE/AT, BACS + Worldpay for UK, Stripe + Apple Pay + Google Pay for US/CA, Razorpay + UPI for IN, plus PayPal as a global fallback. Each website only exposes payment methods that work for its region — customers never see options that will fail at gateway.

Yes — three layers of control: (1) Catalog price scope set to Website, so each website can have its own price list. (2) Customer-group pricing for tier-based discounts (B2B, VIP, etc.). (3) Cart price rules per website for region-specific promotions. We can also import region-specific price CSVs nightly from your ERP if you have a master pricing system. Tax-inclusive (EU/UK) vs tax-exclusive (US) display is handled at the same scope.

Each regulation has different requirements — we configure them per store-view, not site-wide. GDPR (EU + UK): explicit cookie consent before any tracking, right-to-be-forgotten endpoint, data-export request flow. CCPA (California): “Do Not Sell My Personal Information” link, opt-out by default. LGPD (Brazil): explicit consent + DPO contact in footer. PIPEDA (Canada): less invasive, but still requires consent for marketing. We use scoped cookie-consent extensions that auto-detect the visitor region, and integrate with your CRM for unified data-subject-access requests.

Yes. Theme assignment is scoped per store-view, so each storefront can have its own theme, logo, colour palette, fonts, header, footer, even checkout layout. Most clients use one parent theme with per-storefront skins (cheaper to maintain, faster to build, easier to upgrade). For radically different brands — e.g. a luxury sub-brand vs a discount sub-brand on the same backend — we deploy fully separate themes with shared core blocks. Hyvä supports this pattern natively.

Yes — Adobe Commerce B2B (companies, quote workflow, requisition lists, customer-specific pricing, Net-30 / Net-60 payment terms) is scoped per website. So you can run B2C in the US, B2B in DE, and a hybrid B2B+B2C in the UK off the same backend. Each region can have its own sales reps, quote approval flow, payment terms and ERP integration. Salesforce / HubSpot / NetSuite integrations can also route per region. (Note: B2B requires Adobe Commerce, not Open Source.)

Lower than running N separate Magentos — that’s the point. (1) One upgrade applies to all storefronts. (2) One extension stack to license & maintain. (3) One hosting bill (provided you sized it for the storefront count). (4) One admin login for your ops team. The catch: set up wrong, multi-store can become an n-by-n compatibility matrix every time you change something. That’s why we audit + diagram + scope-test before any code goes live, and bake regression tests for each storefront into the deploy pipeline. 30 days post-launch + retainer covers ongoing localisation.

3-year all-in TCO at $200M GMV, comparable scope (B2C with light B2B, 3 regions, mid-complexity catalog):

Adobe Commerce 3-year TCO at $200M: license $80–150k/yr → $240–450k. Adobe Commerce Cloud infra $30–80k/yr → $90–240k. Implementation (mid-tier or tier-1 SI) $400k–$800k one-time. Ongoing engineering retainer $30k–$80k/mo → $1.08M–$2.88M over 3 years. Adobe Marketplace extensions $50k–$150k. Total: ~$1.9M – $3.7M.

Salesforce Commerce Cloud 3-year TCO at $200M: license / revenue-share $500k–$1M/yr → $1.5M–$3M. Implementation (tier-1 SI: Capgemini, Accenture, Publicis Sapient) $800k–$2M one-time. Ongoing SI retainer $50k–$150k/mo → $1.8M–$5.4M over 3 years. Cartridges + integrations $100k–$300k. Total: ~$4.2M – $10.7M.

The TCO gap at $200M GMV typically lands at 2–3× in favor of Adobe Commerce. The gap narrows above $1B GMV but rarely closes — SFCC’s revenue-share pricing scales linearly with GMV; AC’s license tiers cap out.

SFCC pays for itself when the value of native Salesforce ecosystem integration exceeds the 5–10× license premium. In practice, that means:

• You already run on Salesforce. CRM (Account 360), Marketing Cloud (Journey Builder + Email Studio), Service Cloud (cases + returns), Mulesoft (integration), Tableau (BI). The data flows into a single Salesforce org with no middleware.
• Your CX is data-flow-driven. Personalization comes from CRM data (segments, lifetime value, service interactions). SFCC + Einstein AI plugs into that natively. Replicating it on Adobe Commerce requires significant integration engineering ($300k–$1M).
• Your Service Cloud reps need order context. SFCC orders surface inside Service Cloud with one click. Replicating on AC requires a custom integration that’s never as smooth.

If you don’t check those three boxes, SFCC’s license premium is a tax you’re paying for ecosystem features you don’t use. The break-even GMV where pure-economics tip toward SFCC is ~$2B+ — and even then, only when you’re Salesforce-native.

Yes — and the gap is wider on smaller-mid enterprises, narrower on $1B+ ones.

License floor comparison:

• Adobe Commerce: ~$22k/yr (Pro tier, <$1M GMV) → $190k/yr (Pro tier, $25M+ GMV).
• SFCC: ~$200k/yr entry tier (Starter or B2C Commerce). Realistically closer to $300–500k/yr at any meaningful scale because SFCC pricing is partly revenue-share (typically 0.3–0.5% of GMV).

At $50M GMV: AC ~$60k/yr license, SFCC ~$300k/yr → 5×.

At $200M GMV: AC ~$120k/yr, SFCC ~$700k/yr → ~6×.

At $1B GMV: AC ~$200k/yr (tier cap), SFCC ~$3M/yr (revenue-share keeps scaling) → 15×.

The ratio gets worse at scale because Adobe’s pricing tiers cap out while Salesforce’s scales linearly. License-only TCO is one of the strongest arguments to migrate off SFCC at $1B+ GMV.

The native integrations that are genuinely hard to replicate on Adobe Commerce:

• Account 360 + Order History. SFCC orders show up inside Salesforce CRM Account 360 with no middleware. Sales reps see commerce + service + marketing in one view. AC requires a custom Salesforce Connector ($150k–$300k build).
• Marketing Cloud Journey Builder triggers. SFCC events (cart-abandon, order-placed, return-requested) drop into Journey Builder out-of-the-box. AC integration needs MuleSoft or Patchworks middleware.
• Service Cloud case-from-order. Customer service rep clicks an order in Service Cloud → sees full order context, can issue refunds / RMAs. AC equivalent requires custom integration.
• Einstein AI personalization. SFCC + Einstein uses Salesforce’s data lake (CRM + commerce + marketing). AC + Sensei AI uses Adobe’s data lake. Different gravity wells.

The "AC can replicate this with a custom integration" answer is technically true but practically expensive — typical replication of native SFCC + Salesforce stack via AC + middleware runs $500k–$1.5M up-front + ongoing middleware fees. If you’re fully Salesforce-native, SFCC’s premium starts to make sense.

Different architectural philosophies, very different ceilings.

SFRA (Storefront Reference Architecture) on SFCC: JavaScript controllers, ISML templates, reference-architecture cartridges. You extend by adding cartridges to the cartridge-path; you can’t change the Demandware platform itself. No DB schema changes, no PHP, no custom services running on the server. Pros: guardrails, security, multi-tenant safety, easier upgrades. Cons: hard ceiling — anything outside the SFRA model requires either a workaround or escalation to Salesforce. Examples that get blocked: custom ERP write-paths, deep custom checkout flows, non-standard payment routing logic, complex B2B approval chains.

Magento module system on Adobe Commerce: full PHP modules with DB schema (db_schema.xml), observers, plugins (interceptors), GraphQL extensions, headless-API extensions, custom services. You can change anything — the platform is the framework. Pros: no real ceiling, extensions ship to Adobe Marketplace as products. Cons: more rope to hang yourself with; bad extensions slow the store; upgrades require regression testing.

Verdict: 80% of common features fit SFRA fine. The 20% that don’t are the reason enterprises re-platform from SFCC to AC.

Adobe Commerce wins on B2B depth + cost — it’s a single codebase. SFCC B2B is a separate product line with its own gaps.

Adobe Commerce B2B (native): Companies (parent-child accounts), Negotiable Quotes (request → negotiate → convert, with multi-step approvals), Requisition Lists, customer-segment catalogs (different products visible per customer group), tier prices per SKU per group, sales-rep impersonation, Net-30 / Net-60 / custom payment terms per customer, shared catalogs across stores. All in one codebase.

Salesforce B2B Commerce: separate product from B2C SFCC. Companies + multi-buyer accounts, contract pricing, MyAccounts portal, reorder workflows, quote requests. Capable but feels like a parallel platform — UX differs from B2C SFCC, admin is split, migration between B2B and B2C SFCC is non-trivial. Enterprise B2B is solid but you’re effectively running two SFCC instances if you have B2C + B2B.

Practical pick: if B2B is >25% of revenue and you want one platform serving both, AC wins. If B2B is the only line and you’re committed to Salesforce stack, SFCC B2B is fine. If B2B is <25% and bolted onto B2C, AC’s native B2B beats SFCC’s B2B-as-a-separate-product hands-down.

Both handle multi-region well, with different patterns.

SFCC multi-site model: sites + locales + currencies share product data via a Master Catalog. Per-site overrides for content, pricing, and merchandising. SI partners specialise in this — large enterprise multi-site SFCC builds are routine. Strengths: scales smoothly to 50+ locales sharing a base catalog. Weaknesses: per-region completely-different catalogs are awkward; you end up managing exclusion rules.

Adobe Commerce multi-store model: websites → stores → store views, with each axis able to override catalog, pricing, currency, language, tax, payment methods, shipping. Strengths: scales to 5–20 distinct stores with very different catalogs (different brands, different product mixes). Weaknesses: scaling to 50+ locales sharing a catalog needs more configuration discipline; not as turn-key as SFCC.

Implementation complexity:

• SFCC: 4–8 months for 5-region multi-site, $400k–$1M with tier-1 SI.
• AC: 3–6 months for 5-store multi-region, $150k–$500k with mid-tier agency.

Both ship hreflang correctly. SFCC wins on scale + locale density; AC wins on cost + per-store catalog flexibility.

Both can hit excellent CWV with engineering discipline. SaaS multi-tenancy is mostly neutral — it’s the architecture choices on top that matter.

SFCC defaults: SFRA-based stores hit Lighthouse mobile 75–85 out of the box. CDN edge is included (Salesforce’s eCDN), so static assets are fast globally. Performance ceiling: 90+ Lighthouse mobile with a clean SFRA cartridge stack and disciplined third-party tag management. Watch out: SFCC’s page generation is server-rendered and can be slow under heavy load if cartridges aren’t optimised.

Adobe Commerce defaults: Magento Luma sits at 45 Lighthouse mobile. With Hyvä theme (Tailwind + Alpine.js, ~95% less JS), it hits 95+. Adobe Commerce Cloud includes Fastly CDN, so static assets are also fast globally. Performance ceiling on AC + Hyvä is genuinely higher than SFCC defaults — but requires the Hyvä re-theme commitment ($25k–$80k).

Practical comparison: SFCC out-of-box > AC Luma out-of-box; AC + Hyvä > SFCC tuned. If CWV is a top-3 priority, AC + Hyvä is the strongest play. If you want fast defaults without a re-theme project, SFCC ships closer to that.

Both offer enterprise-grade SLAs but with different shapes.

Salesforce Commerce Cloud SLA: 99.99% uptime guarantee on the platform layer. Multi-tenant SaaS — Salesforce manages the entire stack, including Black Friday auto-scale. Service-credit refunds if uptime drops below 99.99% in a billing period. In practice: SFCC platform incidents are rare; when they happen, all SFCC customers are affected simultaneously.

Adobe Commerce Cloud SLA: 99.95% uptime on the standard tier; 99.99% on Pro tier (the one most enterprises run). Adobe manages infra, you manage application code. Auto-scale happens via Fastly + auto-scaling Magento application servers. Service-credit refunds if uptime drops below the threshold. In practice: AC Cloud incidents are usually customer-specific (your code bug, your extension regression) rather than platform-wide.

Self-hosted Adobe Commerce / Magento OSS: SLA is whatever you negotiate with your hosting provider (Cloudways, AWS, Hetzner). Typical: 99.9–99.99% depending on tier.

Verdict: SFCC and AC Cloud Pro are roughly equivalent on SLA. Self-hosted Magento needs more ops discipline to match. SLA differences are not the deciding factor — both are credible enterprise platforms.

Both directions are feasible. The economics + timelines differ significantly.

SFCC → Adobe Commerce (more common):

• Timeline: 6–12 months for a typical mid-enterprise re-platform.
• Cost: $250k–$1M for the rebuild + integration work.
• What migrates: catalog, customers, orders, content (CMS pages), redirects.
• What doesn’t migrate: SFRA cartridges (architecture is incompatible — must be rewritten as Magento modules), Einstein AI training data (can’t be exported in usable form).
• Driver: typically license-cost reduction (30–50%) + customization roadmap freedom.

Adobe Commerce → SFCC (less common):

• Timeline: 12–18 months. Discovery + architecture takes longer.
• Cost: $1M–$3M for the rebuild + tier-1 SI engagement.
• What migrates: catalog, customers, orders, content.
• What doesn’t migrate: custom Magento modules (must be rebuilt as SFRA cartridges), Sensei AI configuration.
• Driver: typically Salesforce ecosystem consolidation (acquired company brings them under group’s SFCC standard).

Both directions are well-trodden paths. The business case must be clear because the project costs are 7-figure regardless of direction.

Different talent gravity. Affects both initial cost and ongoing ops.

SFCC partner ecosystem: dominated by tier-1 SIs — Capgemini, Accenture, Cognizant, Publicis Sapient (formerly Sapient), Astound Commerce, Tata Consultancy Services. Rates: $200–400/hr for senior, $150–250/hr for mid, $80–150/hr for offshore. Partner tiers (Strategic, Crest, Ridge) reflect Salesforce certification depth + book-of-business. Pros: deep Salesforce stack expertise, enterprise change-management capability. Cons: high day-rates, slow turnaround on small changes, premium "you must work with us" gating.

Adobe Commerce partner ecosystem: tier-1 SIs (Wunderman Thompson, Vaimo, Born Group, Diconia), mid-tier agencies (50–200 staff, e.g. Bounteous, Inviqa, Atwix), full-stack freelance specialists. Rates: $80–200/hr depending on tier and geography. Adobe Solution Partner program tiers (Specialized, Gold, Platinum) reflect certification + portfolio. Pros: wider pool, easier to swap partners, mid-tier agencies offer excellent value. Cons: tier-1 SI capability for very large transformations is thinner than Salesforce’s.

Talent supply matters because: when you need to scale from 6 to 12 developers, AC’s deeper pool wins. When you need a 50-person SI team for a global rollout, SFCC’s tier-1 SIs win. Pick the partner before picking the platform.

Both have surprise costs that don’t show up in the initial sales pitch.

Salesforce Commerce Cloud hidden costs:

• Revenue-share creep. SFCC pricing scales with GMV — every successful year increases license cost. Renewals at $1B GMV often surprise CFOs.
• Sandbox limits. SFCC sandboxes are quota-limited (development sandbox, staging, etc). Hitting limits means buying more environments at premium rates.
• Tier-1 SI lock-in. The certified-SI ecosystem is a small club; rate negotiations are limited. Switching SIs is expensive (knowledge transfer + certification).
• Cartridge upgrades. Salesforce platform upgrades sometimes break cartridge integrations; tier-1 SI fixes are billable.
• Einstein AI seat fees. Salesforce charges per-seat for Einstein features that started "free" in evaluations.

Adobe Commerce hidden costs:

• Hosting overruns at peak. Adobe Commerce Cloud auto-scales but the bill follows. Black Friday spikes can 2–3× a quarterly hosting bill.
• Extension dependency hell. Mid-market AC stores accumulate 30–60 third-party extensions. Upgrades become regression-test marathons. Budget $20k–$80k/yr for extension maintenance.
• Security patch lag. Adobe ships security patches monthly; if you don’t apply within 30 days, breach risk rises sharply. Patch-application is real ops work — $5k–$20k/patch with regression.
• Hyvä theme licensing. Hyvä is paid (~€1k/yr/store-view + per-developer fees). Often missed in initial budgets.

Both platforms cost more in year 2 than year 1 — plan for it.

Yes, by an embarrassing margin. On a stock Magento Open Source 2.4.8 install with the default catalogue:

• Lighthouse mobile performance: Hyvä 95 – 99 vs Luma 25 – 45 (orange/red zone)
• JS bundle (gzipped, homepage): Hyvä ~70 KB vs Luma ~450 KB
• First Contentful Paint (4G mid-tier Android): Hyvä 0.4s vs Luma 1.8s
• Largest Contentful Paint: Hyvä 0.9s vs Luma 4.1s
• Time to Interactive: Hyvä < 1s vs Luma 4 – 8s
• Interaction to Next Paint: Hyvä ~60ms vs Luma ~380ms

These numbers are from production stores I’ve migrated, not synthetic benchmarks. The gap shrinks slightly under heavy customisation, but Hyvä still wins by 2 – 3x on every Core Web Vital.

Luma: $0 license, ships with Magento Open Source. The cost is in performance work afterwards — a Luma store usually needs $5 – 15k of optimisation to claw the Lighthouse score above 60.

Hyvä: $1,000 – $2,000 one-time license per store (per major version), then you own the code forever — no per-seat, no SaaS fee. Migration dev runs $5 – 20k depending on customisation depth and extension count. Greenfield builds tend to be cheaper than migrations because there’s no porting work.

3-year TCO: Hyvä typically wins by $5 – 30k once you factor in the conversion lift (8 – 25%) and the avoided performance-tuning bills. Stores with strong organic traffic break even fastest because every second of LCP improvement compounds across millions of pageviews.

Probably yes — the answer depends on the extension category:

• Storefront-impacting paid extensions (Amasty, Mageplaza, Magefan, etc.): ~95% have native Hyvä support in 2026, or work via the Hyvä Compatibility Module.
• Marketplace storefront extensions (free): ~70% native or compat-supported. Some niche ones may need a port.
• Admin-only extensions (reporting, exports, RMA): 100% — they don’t touch the storefront so Hyvä doesn’t affect them.
• Heavy frontend customisation extensions (page builders, layered nav, configurators): 80 – 90% have Hyvä parity, but check each one before committing.

The audit step in any migration starts with a per-extension compat check — no surprises mid-build.

Depends on where the bleeding is. Two patterns I see:

• Storefront slow, checkout OK → full Hyvä first. If PLP/PDP Lighthouse is < 50 and bounce rate is high, fix the entry pages first. Hyvä Checkout is a smaller win on top.
• Storefront OK-ish, checkout abandonment > 70% mobile → Hyvä Checkout first. Captures ~50% of the perf wins for ~25% of the migration cost. Lower risk, faster ROI. Then plan a full Hyvä migration in a later phase.

For heavily customised Luma stores where a full migration is genuinely $30k+, Hyvä Checkout alone is often the right answer for the first 12 months. The two aren’t mutually exclusive — they stack.

Three rough sizes:

• Small (low customisation, < 10 extensions): 4 – 6 weeks, $5 – 10k. Mostly theme port + brand re-skin. Fastest payback.
• Medium (custom Luma child theme, 10 – 25 extensions, some B2B): 6 – 9 weeks, $12 – 20k. Most stores fall here.
• Large (multi-store, heavy custom modules, B2B-heavy, 25+ extensions): 10 – 16 weeks, $25 – 60k. Often phased — full Hyvä on B2C storefronts first, B2B portal in a later phase.

Side-by-side QA + soft cutover (10% traffic for 7 days, then full) is included in every estimate. Roll-back plan stays available for 14 days post-cutover.

Yes — Hyvä supports the full Magento B2B feature set (company accounts, requisition lists, quotes, shared catalogues, tier pricing). The work is in re-implementing custom UI on top of those features.

What needs porting:

• Company-account dashboards (custom Knockout templates → Alpine + Magewire)
• Requisition list / quick-order UIs (usually a clean refactor; the Hyvä versions are simpler)
• Custom price-tier display logic on PLP/PDP (move from KO to Alpine)
• B2B-only checkout flow tweaks (often easier in Hyvä Checkout)

B2B-heavy stores often see bigger conversion lifts after Hyvä migration than B2C ones — buyer expectations on UX have caught up to consumer-grade, and B2B Luma UX usually lags badly.

Same Magento multi-store mechanism (websites, store views, store-scoped configs) — Hyvä sits on top, doesn’t change the architecture. Per-store theme overrides, per-store-view translations, per-store catalogue all work identically.

Where it’s actually better than Luma:

• Tailwind config can be per-child-theme, so different brand looks share the parent Hyvä foundation without LESS-import gymnastics
• Alpine state is local to each Hyvä component, so store-view-specific UI tweaks don’t leak across views
• Faster builds — no `setup:static-content:deploy` per-locale RequireJS pipeline grinding through 8 store views

For 5+ store-view setups, Hyvä actually saves engineering time on top of the perf wins.

If done right, no. If done wrong, yes — but it’s preventable. The risk areas:

• URL structure changes: none, if you keep the same Magento URL rewrites. Hyvä is a theme layer, not a URL change.
• Schema markup: Hyvä emits product/breadcrumb/organization schema by default. Verify it matches your current structured data, port any custom JSON-LD.
• Meta tags + canonical: handled by Magento core, so Hyvä doesn’t change them. Verify after cutover with a crawl.
• Page speed (positive): Lighthouse 95+ improves Core Web Vitals, which improves Google rankings on competitive queries. The lift usually shows up 4 – 8 weeks post-cutover.

Standard playbook: full Screaming Frog crawl pre-cutover, same crawl post-cutover, diff every node. Submit updated sitemap. Rankings hold or improve within 2 months in 90%+ of cases.

Adobe hasn’t formally deprecated Luma, but the de facto signals are clear:

• No meaningful Luma updates since 2022 — only security backports.
• Adobe’s own 2024 announcement positioned Hyvä as the recommended frontend for Adobe Commerce going forward.
• Adobe Commerce Cloud onboarding for new merchants now defaults to Hyvä project templates.
• Magento Open Source still ships with Luma as default (won’t change in 2026), but every "what should I build new with?" recommendation from Adobe Solution Partners points at Hyvä.

The way to read this: Luma will keep working for 5+ more years (Magento doesn’t break things), but it’s in maintenance mode. Building greenfield on Luma in 2026 is choosing the legacy stack on day one.

The Hyvä Compatibility Module is a separately-licensed wrapper that lets Luma-only extensions render their UI inside a Hyvä storefront without rewriting them. It does this by injecting a sandboxed Knockout/RequireJS environment for those specific extensions, while the rest of the page stays Hyvä-native.

What it covers:

• ~95% of paid Luma-only extensions from major vendors (Amasty, Mageplaza, Magefan, Aheadworks, etc.)
• Most Magento Marketplace storefront extensions that haven’t shipped native Hyvä support yet
• Custom Luma extensions written in-house (with some setup work)

What it doesn’t cover:

• Page-builder extensions that try to take over the whole page rendering pipeline
• Extensions that hard-code Luma-specific class names everywhere
• The performance wins — Compat Module re-introduces some Luma JS, so a Compat-heavy store loses 10 – 30% of the Hyvä perf win. Still way ahead of pure Luma.

Yes, and mostly in your favour. The required skills:

• Tailwind CSS: mainstream front-end skill, huge talent pool, easy to hire
• Alpine.js: small, easy to learn — most React/Vue devs pick it up in a weekend
• Magewire (server-side reactivity): Hyvä-specific, but well-documented. 1 – 2 weeks to ramp
• Magento backend (PHP, GraphQL, modules, plugins): identical to Luma — same talent pool

Compare to Luma which needed:

• jQuery (still findable, but devs hate it now)
• RequireJS (legacy, fewer experts every year)
• KnockoutJS (effectively dead — almost nobody under 30 has used it)
• UI Components XML (Magento-specific arcana)

Hiring for Hyvä is genuinely easier than Luma in 2026, and the dev quality is higher because the talent pool overlaps with mainstream web dev.

Hyvä, by a clear margin. The reasoning:

• Active development: Hyvä ships a new version every 6 – 8 weeks. Luma ships security patches only.
• Adobe’s direction: Adobe Commerce + Hyvä is the strategic frontend stack for 2026 – 2030.
• Talent pool: Tailwind/Alpine devs are growing; jQuery/Knockout devs are aging out.
• Extension ecosystem: new extensions ship Hyvä-first from 2024 onwards. Luma compat is becoming a "legacy support" feature in marketplace listings.
• Hyvä team: Acquired by Vaimo in 2024, well-funded, growing engineering team. Not a side-project.

Realistic horizon: Luma will work for 5+ more years but stop being competitive in 2 – 3. Hyvä has 10+ years of clear runway. If you’re planning a build that’ll live 5+ years, Hyvä is the only sensible answer in 2026.

For 95% of Magento stores: Hyvä. Server-rendered, Tailwind + Alpine, Lighthouse 95+, $5 – 20k build, simple to hire for, simple to maintain.

The 5% who should pick PWA Studio know it from the start: native iOS/Android app sharing one GraphQL backend with the web, $50M+ GMV, dedicated React team already on payroll, and a budget that covers the 8x cost multiplier without flinching. If you’re unsure which group you’re in, you’re in the 95%.

For a typical mid-volume Magento store (50 – 500 SKUs, B2C, 1 storefront, no exotic UX):

• Hyvä build: $5 – 20k. Hyvä parent license + child theme bootstrap + brand tokens + PLP/PDP/header/footer/cart re-implementation in Tailwind + Alpine. 4 – 12 weeks elapsed time.
• PWA Studio build: $50 – 200k+. Apollo Client setup + GraphQL schema design + React component library + service-worker config + bundle optimization + SSR / SEO config + headless cache strategy. 16 – 40 weeks elapsed time.

The gap is roughly 8x and it doesn’t close as scope grows. Custom features in PWA Studio cost more to build (every feature touches React + GraphQL + Apollo cache) and more to test. The "PWA Studio is faster long-term" argument doesn’t hold up against production data — most teams are still shipping features faster on Hyvä three years in.

Same Magento 2.4.8 install, same product catalog, same hosting:

• Hyvä: Lighthouse Performance 95+ on every page out of box. ~70 KB JS bundle. LCP under 1s on mid-tier mobile. Predictable across PLPs, PDPs, cart, checkout. No tuning required.
• PWA Studio: Lighthouse 70 – 85 typical for production stores. Variable — depends entirely on bundle size, hydration strategy, image handling, route caching. Specialist tuning can push it higher (90+ achievable) but it costs 80 – 200 hours of perf engineering and it regresses every time someone adds a feature.

The "PWAs are faster" narrative was true vs Luma (where the bar was Lighthouse 30). It is not true vs Hyvä. Hyvä wins on perf in 9 out of 10 head-to-head benchmarks in 2026.

Hyvä is server-rendered. Crawlers receive fully-formed HTML, structured data renders immediately, no hydration gap, no escape-fragment dance. SEO works out of the box — same as old-school PHP rendering.

PWA Studio needs careful SSR config to avoid leaking rankings: Apollo SSR setup, cache hydration on the client, fallback HTML for crawlers, escape-fragment cleanup, route-level meta-tag injection. Many real PWA Studio implementations leak rankings during build complexity — the dev team optimises for the React experience and Googlebot times out before hydration completes. We’ve seen production stores drop 30 – 50% organic traffic in the first 6 months post-PWA-launch and only recover after a 6-figure SSR-tuning project.

If SEO is in your top-3 reasons for the rebuild, Hyvä is the safer answer.

Concrete numbers from real engagements:

• Hyvä: $5 – 15k/year. One stack (PHP + Tailwind + Alpine), one build pipeline, one mental model. Magento upgrades are mostly transparent. Hyvä parent theme upgrades take 1 – 3 days per major version.
• PWA Studio: $50 – 100k/year. React expertise on retainer, GraphQL schema upkeep, Apollo cache tuning, service-worker debugging, SSR config maintenance, bundle-size budgets policed every PR. Magento upgrades require coordinated GraphQL contract testing. PWA Studio version bumps occasionally rewrite half the codebase.

Over 3 years that’s a ~$240k delta on maintenance alone, on top of the 8x build cost gap. The cost difference compounds — every quarter you stay on PWA Studio costs more than the equivalent quarter on Hyvä.

Sort of, but the framing is misleading. PWA Studio ships a Progressive Web App by default — installable on Android home screen, offline-capable for cached routes, push-notification ready. It’s not a native app — it doesn’t ship on the App Store / Play Store on its own.

To get a real native app from PWA Studio you wrap it with Capacitor or React Native. That works because the React frontend is already built — but it’s a separate engineering effort with its own App Store review process, push-notification infrastructure, and platform-specific UX.

Hyvä can also be installable as a basic PWA (service worker for offline, manifest for home-screen install) — that’s a separate Hyvä module. What Hyvä can’t do is share its frontend codebase with a native app on App Store / Play Store. That capability is the real PWA Studio differentiator. If you don’t need it (and 95% of stores don’t), the "mobile app" framing isn’t worth the 8x cost.

Real cases where PWA Studio is the right call:

• D2C brand shipping web + iOS + Android from one engineering team, where the native apps are non-negotiable (cosmetics, athleisure, lifestyle) and have material revenue.
• B2B with kiosk — physical retail kiosks running the same React app as the web checkout, sharing GraphQL state, branded as one experience.
• Content-led commerce where a separate CMS (Contentful, Sanity) drives content + pages and Magento is purely the commerce backend — true headless decoupling.
• Smart-display / TV / set-top-box commerce — extremely rare but does exist for media + entertainment merchants.

If your roadmap doesn’t look like one of those, PWA Studio is overkill. "We might build a native app later" is not a real multi-channel reason — it’s a $150k frontend gambling on a feature that may never ship.

Hyvä Checkout is a separate paid module — Magewire-driven (server-rendered state), one-page, fully customizable in Tailwind, Lighthouse 95+. Most Hyvä stores adopt it once they see the LCP delta vs default Magento checkout. Add-on cost ~$1k.

PWA Studio Checkout is fully client-side React, talks to Magento via GraphQL mutations, supports advanced UX (multi-step animations, instant validation, payment-method UX patterns SPAs do well). The ceiling is higher for very-custom UX, but you pay for that ceiling with build complexity and ongoing maintenance.

For most stores the Hyvä Checkout ceiling is more than enough — sub-1s LCP, full control over fields, support for every Adobe-Marketplace payment method. The PWA Studio Checkout ceiling only matters if you have specific UX requirements that need an SPA (Apple-Pay-style sheet animations, real-time multi-currency conversion in the cart). If you don’t, the simpler ceiling wins.

Hyvä developer: Magento dev who knows Tailwind + Alpine. Tailwind and Alpine are 30-min skills for an experienced dev — most Magento devs pick them up in a week. Wide talent pool, $50 – 100/hr in 2026, hireable on Upwork / LinkedIn / direct in 1 – 2 weeks.

PWA Studio developer: Magento dev + React + Apollo Client + GraphQL schema design + service-worker debugging. That’s 5+ overlapping specialties. Narrow pool, $100 – 200/hr in 2026, hireable in 1 – 3 months and only if you’re paying market rate. The agency that built your PWA Studio storefront will move on; you’ll be hiring on the open market three years later.

Long-term ownership is the most under-priced variable in this decision. By year 3, "who maintains this?" matters more than "who built this?" — and Hyvä wins that race.

Both are Adobe-blessed in 2026, but the support models are different:

• PWA Studio is an Adobe-owned project — Adobe ships the source, Adobe pays the core team. It’s in the Magento Open Source repo, Adobe Commerce documentation references it as the official headless reference. That said, Adobe’s public roadmap commitment to PWA Studio has been quieter in 2025 / 2026 than 2020 – 2022, and most new Adobe Commerce + Hyvä deals don’t mention PWA Studio at all.
• Hyvä Themes is independent (Vendic-led, Netherlands), but Adobe acquired a stake / partnered formally and Adobe’s 2024 + 2025 announcements list Hyvä as the recommended frontend for new Magento builds. Hyvä is shipping — new releases monthly, active dev community, growing extension marketplace.

If you optimise for "what does Adobe sell to enterprise customers in 2026" — that’s Adobe Commerce + Hyvä, not Adobe Commerce + PWA Studio.

Same starting point (existing Luma store), same scope:

• Luma → Hyvä: 4 – 12 weeks, $5 – 20k. Hyvä Compatibility Module covers most marketplace extensions for free. Brand tokens port to Tailwind config. Most stores recoup the cost in 3 – 6 months on conversion lift.
• Luma → PWA Studio: 16 – 40 weeks, $50 – 200k+. Every extension needs a GraphQL contract. Frontend is rebuilt from scratch in React. Extension marketplace coverage is much thinner — many paid Luma extensions have no PWA Studio equivalent at all. ROI window is 18 – 36 months at best, often longer.

The migration cost differential is the clearest signal in the decision. If you’re migrating off Luma in 2026, Hyvä is almost always the right answer unless your roadmap genuinely requires native apps + multi-channel + you have the team and budget to support it.

Rarely, and only for very specific multi-brand setups. Real cases I’ve seen:

• Multi-brand parent — flagship D2C brand on PWA Studio (with native apps), B2B back-office portal on Hyvä on a separate Magento instance. Two surfaces, two stacks, two dev teams, shared product data sync.
• Regional split — North-American storefronts on PWA Studio (where the React team is based), EMEA storefronts on Hyvä (where the Magento + Tailwind team is based). Same backend, different frontends per region.

What I haven’t seen work: trying to run both Hyvä and PWA Studio on the same store / same domain. The maintenance burden compounds, the dev team gets pulled in two directions, and you end up paying 1.5x the cost of either stack alone. If you find yourself drafting a "we’ll do both" plan, that’s usually a sign the underlying decision wasn’t made — pick one and commit.

The codebases are 99% identical. The actual AC-only modules are a finite, well-known list:

• Magento_Company — multi-buyer B2B accounts with hierarchy, role permissions, shared catalogs, and company-specific pricing.
• Magento_NegotiableQuote — RFQ workflow with multi-round price negotiation between buyer and merchant.
• Magento_RequisitionList — recurring SKU lists for repeat B2B orders.
• Magento_PageBuilder — the drag-drop visual CMS editor.
• Magento_Staging — schedule price / content / promo changes to a future date with preview-mode.
• Magento_GiftCard, Magento_Reward, Magento_Rma — gift cards, loyalty points, return-merch authorisation.
• Magento_CustomerSegment — rules-based audience builder for promos and content.
• Adobe Commerce Cloud — managed Pro/Enterprise infrastructure (not a module, but bundled).

That’s the actual delta. Everything else — PWA Studio, GraphQL, Hyvä compat, REST — is identical between editions.

Rough rules I’ve seen hold across ~30 Magento stores:

• Pure D2C, no B2B: ~$25M GMV. Below that, OS plus a Page Builder alternative + scheduled-promo extension covers the gap for $5–10k one-time vs $30–80k/yr recurring.
• B2B-heavy (50%+ B2B share): ~$10M GMV. Native Companies + Negotiable Quotes + Requisition Lists save real dev hours; extension stack hits 80% feature parity but the last 20% gets expensive.
• Regulated industry (finance / healthcare / gov): the SLA + direct-from-Adobe patching alone justify the license at almost any GMV — you’re paying for compliance posture, not for features.
• Already in Adobe stack (Analytics + Target): integration value is real, knock $20k off the break-even threshold.

The break-even calculation is rarely about features alone. It’s features + ops time saved + risk reduction. On a $10M B2B store with a small ops team, the AC license can pay back in 4–6 months purely on hours saved by Page Builder + Companies.

~85% parity, yes. The OS B2B stack I recommend in 2026:

• mage2kishan B2B Suite (or Aitoc / Bizzbee / Magenest) — multi-buyer accounts, role permissions, company-specific catalogs — ~$1.5–3k one-time.
• Mageworx Negotiable Quotes — RFQ workflow with multi-round negotiation — ~$400.
• Aheadworks / Mageplaza Requisition Lists — recurring SKU ordering — ~$300.
• Net-30 + Purchase Order: Mageplaza Net Terms or custom (~$1k one-time).

Total ~$3–5k one-time vs AC’s $30–80k/yr recurring. What you don’t get from the OS stack: AC’s admin UX polish on the company-account flows, and tight Adobe-Analytics-driven segment-based pricing. For most B2B stores under $15M GMV, the OS stack is the right answer.

Yes, three viable paths:

• Magezon Page Builder Plus (~$300) — the closest functional clone of AC Page Builder. Drag-drop rows / columns / banners / sliders / product blocks. Ships with 60+ pre-built widgets. The default OS recommendation in 2026.
• Mageplaza Page Builder (~$200) — lighter, faster, fewer widgets but enough for most marketing-led teams.
• Hyvä + Tailwind + Builder.io / Sanity: headless-ish CMS, marketers edit in Builder/Sanity, content syndicates to the Hyvä storefront. Most flexibility, highest dev investment.

None of these match AC Page Builder’s native-Magento-block awareness (e.g. dynamic catalog blocks). For most OS sites the Magezon route covers 90% of marketing-team needs at 1% of AC’s recurring cost.

Less complex than a re-platform, more involved than a routine upgrade. Same database schema, vast majority of code carries over unchanged. What actually happens:

• License + Cloud activation — week 1.
• Extension audit: identify which OS-only extensions duplicate AC native modules (often 4–8 of them). Plan to remove or replace — 1–2 weeks.
• Schema reconcile: AC ships extra DB tables for staging / GiftCard / Rma / CustomerSegment. Setup:upgrade handles most; expect 1–2 days of edge cases.
• B2B re-platform: if you had OS B2B extensions, migrate data into Magento_Company tables — 1–3 weeks depending on volume.
• Page Builder content: existing CMS content stays as legacy WYSIWYG; new content uses Page Builder. No mass migration needed.
• Regression QA + cutover — 2 weeks.

Total: $30–100k all-in depending on customisation depth and extension count. 6–10 week project for a typical $10–30M store.

Cloud adds three things on top of the AC license:

• Managed infrastructure: Adobe runs the AWS-hosted environment with auto-scaling, Fastly CDN, New Relic APM, ElasticSearch, RabbitMQ, and Redis pre-configured. You don’t pick a hosting provider or DevOps a server cluster.
• Pro vs Starter tiers: Pro adds dedicated infra, multi-environment (integration / staging / prod), and 99.99% uptime SLA. Starter is shared infra, single environment.
• Bundled monitoring + WAF: Fastly WAF, Adobe Stock images, integrated Adobe Analytics — rolled into one invoice instead of stitched together.

What it costs: typically $80–250k/yr all-in (license + infrastructure + Fastly + monitoring), vs ~$30–120k/yr for self-hosted AC + your own AWS / hosted infra. The premium is real; whether it’s worth it depends on whether your team wants to own the DevOps. For most $20M+ stores without a dedicated DevOps function, Cloud earns the markup.

Yes, but the tiers aren’t public — Adobe quotes per-deal. What I’ve seen in the wild (2024–2026):

• Adobe Commerce (self-hosted), low-GMV tier: ~$22–35k/yr. Stores up to ~$1M GMV.
• Adobe Commerce, mid-GMV tier: ~$35–60k/yr. Stores $1–25M GMV.
• Adobe Commerce, high-GMV tier: $60–120k+/yr. Stores $25M+ GMV.
• Adobe Commerce Cloud, Starter: ~$50–80k/yr (license + bundled infra).
• Adobe Commerce Cloud, Pro: $80–250k+/yr (multi-env, dedicated infra, full SLA).

The tiers ratchet on revenue audit (annual). If your GMV grows past the threshold, Adobe will renegotiate at renewal — this catches a lot of fast-growth stores by surprise. Always model the next two tiers when budgeting.

What you get with AC support (Pro / Cloud Pro):

• Severity 1 (production down): 1-hour response, 24/7, phone-callable. Adobe engineer engages until resolution.
• Severity 2 (major function impaired): 4-hour response, business hours.
• Severity 3 / 4 (minor / question): 1 business day, ticket-only.
• Direct security patch delivery with pre-disclosure window before public CVE.
• Adobe Technical Account Manager (TAM) at Pro Cloud / Enterprise tiers.

What it doesn’t cover: bugs in your custom code or third-party extensions (those are agency / dev-team scope), and SaaS-level zero-downtime guarantees (you still need DevOps / agency on retainer for deployment, perf tuning, custom code support). The SLA is genuine; it’s also genuinely scope-limited to platform code. For most non-regulated stores, an agency retainer plus Mage Report patching service ($100–500/mo) covers the practical equivalent.

Both editions get the same patches; the difference is delivery channel and timing.

• Cadence: Adobe ships ~4 quarterly Magento Security Patches per year, plus emergency hotfixes for critical CVEs (typically 2–4 of those per year).
• AC delivery: patches available via Adobe support portal with pre-disclosure window (~1–2 weeks before public CVE). AC customers can patch ahead of public disclosure.
• OS delivery: patches drop to GitHub / Composer simultaneously with public CVE disclosure. No pre-disclosure window.
• Application urgency: high. Magento has been actively exploited (Magecart skimmer attacks 2021–2024). Stores 30+ days behind on patches show up in scanning. Mage Report / Sansec / Sucuri all monitor patch status publicly.

For stores in regulated industries with mandatory patch-window SLAs, AC’s pre-disclosure + direct delivery is genuinely load-bearing. For typical D2C stores, OS + a patching retainer ($200–500/mo for an agency to apply patches within 7 days) covers the operational equivalent.

Mostly AC, but it’s nuanced:

• Adobe Analytics: AC ships a native connector module with pre-built event mapping (product views, add-to-cart, checkout, purchase). OS can integrate via Adobe Launch (free) or a community connector — works, just more setup hours.
• Adobe Target: integration is at the JavaScript layer (mbox / at.js), so works on either edition. AC adds tighter customer-segmentation handoffs.
• Adobe Experience Manager (AEM): integration is via API. Both editions can talk to AEM equally well; the AEM commerce-pages connector targets AC by default but works on OS with config.
• Real Customer DataPlatform (RT-CDP): Adobe pushes this into AC contracts; OS doesn’t get the bundled hook.

If you’re fully committed to the Adobe Experience Cloud stack, AC + AEM + Analytics + Target sold together gets meaningful Adobe-bundle pricing. If you’re only using one Adobe product, OS + a custom connector is cheaper.

Most don’t. The breakage rate I’ve seen:

• Hyvä + Hyvä-compatible extensions: 100% carry over — AC and OS run the same Hyvä.
• Plain OS extensions from major vendors (Aheadworks, Amasty, Mageplaza, Magezon): ~95% work unchanged. Edge cases: extensions that monkey-patch core checkout or admin grids may collide with AC’s versions.
• OS B2B extensions: ~50% of these duplicate AC’s native B2B modules. Plan to remove them and migrate data into Magento_Company tables. Don’t leave both running.
• Custom modules: nearly always carry over. The collisions are with AC-native features (Staging / GiftCard / Rma / CustomerSegment) — if your custom module duplicates one, refactor.

Practical migration plan: pre-flight audit of every installed module against AC’s module list, decide remove / keep / replace per extension, run side-by-side regression in staging. 1–2 weeks of focused work for a typical 30-extension store.

More negotiable than most buyers realise. Levers I’ve seen work:

• Multi-year commit: 2–3 year contracts unlock 10–20% off list. Adobe’s sales team is targeted on commit-length.
• Migration credits: if you’re moving from OS, ask for a migration discount — Adobe runs programs for OS-converts at 15–25% off year 1.
• End-of-quarter timing: Adobe FY ends late November. Quarter-end deals (March / June / September / December) get better terms.
• Bundle with Adobe Experience Cloud: if you’re also buying Analytics or Target, the bundled price is materially lower than line-item.
• Competitive bid: Adobe sales will discount when shown a serious BigCommerce / Shopify Plus / Salesforce CC quote. Even if you’ve decided, get a reference quote to bring to the table.

Realistic outcome: 15–30% off list price for most committed deals. Don’t accept the first quote; renewal negotiations also leave 10–15% on the table if you push.

Afterpay ships an official Magento 2 module via the Magento Marketplace and via Composer (`afterpay/module-afterpay`). Setup is three steps: (1) create an Afterpay merchant account at portal.afterpay.com and grab your Merchant ID + secret key, (2) install the module + configure under Stores → Config → Sales → Payment Methods → Afterpay, (3) test in sandbox before flipping production. The module supports product page messaging (the “4 instalments of A$X” widget), cart messaging, and checkout. Afterpay was founded in Sydney in 2014 — it’s the de-facto BNPL rail for AU consumers, particularly fashion / DTC / lifestyle. We’ve integrated it on 30+ AU stores.

Since 1 July 2018, imports under A$1,000 are subject to GST when sold to AU consumers by overseas merchants — previously they were GST-free. If you’re an international seller selling into AU, you must register for GST under the OSR (overseas-supplier registration) scheme once your AU sales exceed A$75,000 in a 12-month period. In Magento, this is configured via Stores → Config → Sales → Tax: set up an AU-specific tax zone, apply 10% GST to all goods + services, and gate B2B orders by ABN to skip GST where appropriate. We’ll wire the tax-class mapping, ABN-based exemption flows, and OSR-compliant invoicing per ATO requirements.

ABN (Australian Business Number) validation is critical for B2B Magento stores so you can skip GST on tax-invoice flows where the buyer is a registered business. Two approaches: (1) Live lookup via the ABR (Australian Business Register) web service — we wire an extension or custom module that calls abr.business.gov.au/json/AbnDetails.aspx at registration / checkout, validates the ABN, and stores the verified entity name. (2) Offline checksum validation using the ABN modulo-89 algorithm for instant client-side validation before the live lookup. We typically combine both: instant feedback on the form, live verification before order placement. Combine with a customer attribute `is_abn_verified` and a customer-group rule to expose B2B catalogues / Net-30 terms only to verified ABNs.

Stripe AU — global rail, best for international DTC stores already on Stripe elsewhere. Lowest international card fees, native Apple Pay / Google Pay, deep developer ecosystem. Settlement to AU bank in 2 business days. eWAY — Australian-founded (now part of Global Payments), best for established AU retailers wanting AU-bank merchant services. Strong AMEX support, mature recurring-billing, AU-based phone support. Pin Payments — Australian-owned, Sydney-based, simplest pricing model (one flat rate, no monthly fees). Best for AU-only SMB stores. Recommendation: Stripe AU for DTC scale, eWAY for B2B + AMEX-heavy, Pin Payments for AU-only SMB. We’ve wired all three across 40+ AU Magento stores.

Yes — BPAY is the standard for B2B Magento stores in Australia, particularly for trading-account / Net-30 customers who prefer to pay via internet banking rather than card. There’s no off-the-shelf Magento BPAY module from BPAY itself, but two community modules + a custom approach work well: (1) generate a unique CRN (customer reference number) per order, (2) display the BPAY biller code (yours) + CRN on the invoice + order-confirmation email + customer order history, (3) reconcile incoming BPAY payments daily via your bank’s BPAY remittance file (CSV import to a custom Magento module). For high-volume merchants, integrate with NAB Transact or Westpac PayWay which both offer real-time BPAY APIs. Combine with ABN-gated customer groups so only verified B2B accounts see BPAY at checkout.

Australia Post ships an official Magento 2 module (free) that wires their MyPost Business API for ParcelPost (regular), Express Post (next-day metro), and StarTrack (B2B / large-parcel / regional). The module handles real-time rate quoting at checkout, label printing, manifesting, and tracking events. StarTrack is Australia Post’s premium B2B / regional service — same module covers it. For multi-warehouse stores (e.g. Sydney + Melbourne), we wire ShipperHQ on top so the cart picks the closest warehouse based on postcode + product availability + carrier-rate-shopping. We also build custom routing rules for rural / NT / TAS where Australia Post has different SLAs and StarTrack is often more cost-effective for parcels > 5kg.

Rural Australia, Northern Territory, and Tasmania need special handling because (a) Australia Post SLAs are 5–10 business days vs 1–3 for capital cities, (b) some couriers (Couriers Please) don’t deliver beyond metro areas, and (c) freight to remote NT / TAS often costs 3–5× metro rates. Our standard build: (1) postcode-based shipping zones in Magento with separate rate tables for metro / regional / remote, (2) carrier fallback chain (Australia Post Express → StarTrack → Sendle → Aramex) configured via ShipperHQ, (3) delivery-time messaging on PDP + cart so customers in remote NT see “5–10 business days” up-front, (4) optional freight surcharge for parcels > 5 kg to NT / remote TAS, (5) signature on delivery default for rural to reduce lost-parcel claims.

The Privacy Act 1988 + Australian Privacy Principles (APPs) apply to any business with annual turnover > A$3M (and to all health-data / credit-data businesses regardless of size). For Magento stores: (1) cookie consent banner (we wire CookieYes or CookieFirst with AU-specific text), (2) privacy policy covering APP 1 (open and transparent), APP 5 (notification), APP 6 (use / disclosure), APP 12 (access), APP 13 (correction), (3) opt-out flows for marketing / SMS (Spam Act 2003), (4) data-subject-access requests (DSAR) automation — we build an admin tool that exports a customer’s data on request within the 30-day APP-12 deadline, (5) Notifiable Data Breaches scheme — if you’re breached, you have 30 days to notify the OAIC + affected individuals. We configure logging + monitoring so a breach can actually be detected, not just notified after the fact.

Adobe Commerce Cloud (Sydney region) — managed Magento, Adobe handles patches / upgrades / Fastly CDN / New Relic. Best for stores doing > A$5M/yr that want zero infra burden. Costs A$1,500 – A$5,000+/month depending on tier. Lock-in to Adobe’s deploy flow (ECE-Tools). Self-host on AWS Sydney (or Cloudways Sydney / MyHost / BigCloud) — cheaper (A$200 – A$1,500/month), full control, can use any Magento version / extension. Best for stores doing < A$5M/yr or technical teams that want flexibility. Trade-off: you (or we) own patches / upgrades / CDN / monitoring. Recommendation: under A$3M/yr revenue — AWS Sydney + Cloudways for managed-VPS comfort. Over A$5M/yr — Adobe Commerce Cloud Sydney is worth the price for the SLA + Fastly + auto-scaling. We’ve migrated stores both directions.

Real overlap is 4–6 hours per day between IST (India Standard Time, UTC+5:30) and AEST (Australian Eastern Standard Time, UTC+10) — or AEDT (UTC+11) during daylight saving. Specifically: 1 PM – 7 PM IST = 5:30 PM – 11:30 PM AEST (your business afternoon / early evening, our late afternoon / evening). We schedule daily stand-ups, calls, screen-shares in this window. For early-morning Sydney calls (8–10 AM AEST = 3:30–5:30 AM IST), we offer that on launch nights or for critical incidents. Async tools we use: Loom for code walkthroughs, written end-of-day status notes (sent before our 7 PM IST = your 11:30 PM AEST), Notion project board kept current. WA / NT (UTC+8) overlap is 2 hours longer; SA / NT during AEST is similar to east-coast.

Common Shopify / BigCommerce → Magento migration path for AU stores: (1) data export — products, customers, orders, blog posts via Shopify’s API or BigCommerce’s API (we use Cart2Cart for bulk + custom scripts for edge-cases), (2) URL preservation — map old `/products/` → new `/.html` via 301 redirects so SEO doesn’t drop, (3) payment-rail re-wire — Shopify Payments → Stripe AU + Afterpay + Zip (we install + configure all three), (4) tax + GST — Shopify auto-calculates AU GST; on Magento we wire ATO rate tables + ABN-based exemption, (5) app → extension swap — e.g. Klaviyo → Mailchimp/Klaviyo for Magento, Yotpo → Yotpo for Magento, ReCharge → Aheadworks Subscription. Typical timeline: 6–10 weeks for a 5k-product Shopify store with 50k orders of history. AU-specific gotchas: GST low-value-threshold logic, AU postcode validation, ParcelPoint pickup-point integration if Shopify had it.

Yes — Hyvä is the right choice for any AU fashion / DTC store launching or replatforming in 2026. Three reasons: (1) Speed — Hyvä loads 5–10× faster than Luma. AU mobile networks have slightly higher latency on rural routes, so the speed gain is more visible than in metro-only Shopify benchmarks. (2) Afterpay / Zip messaging — Hyvä has clean Tailwind components for the “4 instalments of A$X” widget on PDP / cart / checkout, much easier to style than Luma’s KnockoutJS. (3) Conversion — AU fashion DTC stores are mobile-first (60–75% mobile traffic). Hyvä’s Lighthouse 95+ + green Core Web Vitals = better mobile rankings = lower CAC. We’ve migrated 8 AU fashion / DTC stores to Hyvä, average conversion uplift 12–22% in the 90 days post-launch. See our /hyva-theme-development-service page for details.

We offer flexible pricing models including fixed-price projects, hourly rates, and monthly retainers. The pricing model depends on the project scope and client preference. We provide detailed quotes after understanding your requirements.

We accept various payment methods including bank transfers, PayPal, and major credit cards. For larger projects, we typically work with milestone-based payments to ensure both parties are aligned throughout the development process.

We stand behind the quality of our work. If you're not satisfied with the deliverables, we'll work to make it right. Our contracts include clear terms about revisions and milestones to ensure project success.

Magento ships with basic table-rate tax, which is fine for a single-state store. The moment you have economic nexus in more than one state — very common after Wayfair v. South Dakota (2018) — you need a real tax engine. We integrate TaxJar, Avalara AvaTax, or Vertex depending on your scale and budget. The engine pulls live rates per state, county, and even ZIP+4, files returns automatically, and keeps a full audit trail.

All three have official Magento 2 connectors. Setup involves: (1) install the extension, (2) wire the API key, (3) map your nexus states + product tax codes (PTCs), (4) enable address validation, (5) turn on auto-filing if eligible. We typically pick TaxJar for stores under $5M revenue (cheaper, simpler), Avalara for $5M–$50M (more PTCs, exemption-cert handling), and Vertex for enterprise + B2B with complex exemptions.

They’re state-level privacy laws, all GDPR-flavoured but with different scopes:

• CCPA (California, 2020) — right to know, delete, opt-out of sale
• CPRA (California, 2023) — adds “sensitive personal info” + Cal Privacy Protection Agency
• VCDPA (Virginia, 2023) — opt-in for sensitive data, DPIA requirement
• CPA (Colorado, 2023) — universal opt-out signal (Global Privacy Control)
• CTDPA (Connecticut, 2023) — similar to CPA

Magento doesn’t handle this natively. We deploy a cookie-consent CMP (Cookiebot, OneTrust, or open-source Klaro), per-state-view opt-out flows, and a DSAR automation (data-subject-access requests handled in < 45 days). Configured per state-view, not site-wide — California users see the “Do Not Sell” link, others don’t.

Yes, but it’s much simpler than self-hosting card data. Using Stripe Elements or Stripe Checkout, your store never touches a raw PAN — you qualify for SAQ A (the easiest PCI tier). You still need to: (1) serve checkout over HTTPS only, (2) not log card data anywhere, (3) complete the SAQ A self-assessment annually, (4) run quarterly ASV scans (your acquirer usually provides these). We’ll lock down the Magento install (admin-URL randomisation, 2FA, restricted IPs, no card-data caching) so SAQ A actually applies.

For ACH payments, we integrate Stripe ACH, Authorize.net eCheck, or Plaid + Dwolla — depending on your volume and risk tolerance. Stripe ACH is easiest (3-day clearing, $0.80 cap fee), but holds funds until clear. For Net-30 / Net-60, we build a customer-segment-based payment method (only B2B-approved customers see it), with a credit-limit field on the customer record (synced from Equifax or Dun & Bradstreet via API), automated invoice generation, and a dunning workflow for overdue accounts. Adobe Commerce + B2B module includes most of this out of the box; on Open Source we build it custom.

Magento 2.3+ ships with MSI (Multi-Source Inventory), which lets you define multiple warehouses (sources) and ship orders from the closest one. We layer on ShipperHQ for rules-based routing (e.g. “ship from CA warehouse for ZIPs west of 100, NJ warehouse for east”), dimensional-weight pricing, and rural-route fallbacks (USPS for ZIPs UPS won’t deliver to). For B2B with reserved stock, we add custom code to lock inventory per quote until expiry. ShipStation integration handles label printing + tracking back to Magento.

Yes — all three have official Magento 2 modules. Affirm is the strongest US-native player (founded SF, 2012); their on-site messaging (“As low as $25/mo with Affirm”) on PDPs lifts AOV by 30–85% in our data. Klarna is bigger globally but very strong in US fashion / lifestyle. Afterpay (now Cash App Afterpay) leads in US under-30 demos. We typically wire 2 of the 3 + Apple Pay + Google Pay for full coverage. Risk + approval handled by the BNPL provider, not you.

This trips up a lot of stores. UPS & FedEx have delivery-area surcharges for rural ZIPs, and they refuse to deliver to many PO boxes / military APO/FPO addresses. USPS covers all of them (including Alaska, Hawaii, Puerto Rico, Guam, US Virgin Islands), often cheaper. We build fallback rules: try UPS Ground first, fall back to USPS Priority for unreachable ZIPs. For Alaska / Hawaii orders we always quote USPS or surface-rate UPS, never expedited. Address validation (USPS API or Smarty Streets) catches typos before the label prints — saves real money.

For most US B2B stores under $5M revenue, Magento Open Source + Hyvä + a few B2B extensions works fine. You add: customer-specific catalogs (Mageplaza / Amasty), quote-request flows, Net-30 payment, ACH gateway. Total: $50–100/yr in extension licences. Adobe Commerce ($22k+/yr licence) makes sense when you need: shared catalogs across companies, requisition lists, multi-tier corporate accounts (parent / child orgs), built-in quote workflow with seller approval, and page builder / live search / product recommendations AI features. We’ll write a candid recommendation in the audit — usually against Adobe Commerce unless you’re >$10M.

From Ahmedabad (IST, UTC+5:30) we have 2–4 hours of real-time overlap with US East Coast daily — roughly 6:30 PM – 9:30 PM IST = 8:00 AM – 11:00 AM EST. We schedule status calls in that window. For US West Coast (PST, UTC-8) the overlap is just 1–2 hours late evening for us, so we run that mostly async: daily Loom recap videos (3–5 mins), written end-of-day status notes, and Slack-first communication. Most West Coast clients tell us they prefer it — they wake up to a clean status update instead of needing a call.

Yes — we’ve done several. Typical Shopify Plus → Magento migrations take 6–10 weeks. We use Magento’s Data Migration Tool for products, orders, customers; custom scripts for metafields and Shopify-specific apps. AWS US-East-1 (N. Virginia) is the standard Magento hosting region for US stores — we deploy via Adobe Commerce Cloud (managed) or self-hosted on EC2 + RDS Aurora MySQL + ElastiCache Redis + OpenSearch. Average cost: $1,200–3,500/month for managed, $600–1,800 self-hosted. URL preservation (301-redirects from Shopify URLs) is critical — we map all of them to keep SEO equity.

If your store sells to (or markets to) children under 13 — toy stores, kids’ clothing, edtech — COPPA (Children’s Online Privacy Protection Act) applies. You must: (1) get verifiable parental consent before collecting any data on under-13s, (2) post a clear COPPA-specific privacy policy, (3) let parents review/delete the child’s data, (4) not condition participation on disclosure of more info than needed. We implement: age-gate at registration, parental-consent flow (email-plus or signed-form upload), data-segregation (under-13 records flagged + auto-purged on request). Penalties for non-compliance run up to $50,120 per violation — do not skip this.

Two layers: (1) UK GDPR + DPA 2018 for personal data — lawful basis, DSAR automation, retention rules in customer + sales_order. (2) PECR (Privacy and Electronic Communications Regulations) for cookies & marketing — ICO requires opt-in consent for non-essential cookies before they fire (no “continued use = consent” banners, no pre-ticked checkboxes). We ship a Cookiebot / Usercentrics / Klaro setup wired into Google Tag Manager & Magento’s native cookie API so analytics, ads, and chat widgets only load after consent. Banner copy reviewed against ICO guidance.

Post-1 January 2021 the UK left the EU VAT area, so:

• UK→UK B2C: standard 20% VAT, register at £90k turnover (2024+ threshold).
• UK→EU B2C: use the EU IOSS scheme for orders under €150 (one VAT registration covers all 27 countries) or register per-country above that.
• UK→EU B2B: zero-rated with VAT-number validation; reverse charge.
• EU→UK B2C: overseas sellers register for UK VAT below £135 thresholds.

We rebuild Magento’s tax engine with these rules, plug in EU-OSS / IOSS schemes, and validate VAT numbers via VIES (EU) + HMRC (UK). MTD invoicing wired into QuickBooks / Xero / Sage.

MTD is HMRC’s mandatory digital VAT-record-keeping + e-submission rule. All VAT-registered businesses (regardless of turnover, since April 2022) must keep digital records and submit VAT returns via MTD-compatible software. Magento itself isn’t MTD software — it must feed compliant software:

• QuickBooks Online (most popular) — we connect via the Magento ↔ QBO bridge.
• Xero — native Magento connector (e.g. A2X, Greenback).
• Sage Business Cloud / Sage 200 — via Magento’s ERP-connector framework.

Every Magento order & credit-memo lands in your accounting software with VAT-rate breakdown, invoice number, and HMRC-compliant fields. No more month-end CSV exports.

BACS Direct Debit is the UK’s preferred B2B rail — lower fees than cards (typically 0.5–1% vs 2–3%), better cash-flow control, and customer-friendly. The standard route is GoCardless, which has a mature Magento 2 module. We:

1. Install + configure the GoCardless Magento module on your environment.
2. Wire it into Magento’s B2B module (Adobe Commerce) or a custom company-account flow (Open Source).
3. Add a Net-30 / Net-60 invoice flow with auto-collected mandates (signed online once, debited monthly).
4. Reconcile in QuickBooks / Xero with VAT-rate awareness for MTD.

For Adobe Commerce B2B, this slots into company + sales_rule tables for customer-specific pricing and approval workflows.

Pick by use case:

• Worldpay (FIS / Vantiv-owned) — the legacy UK leader, best for established UK retailers with bank-direct relationships. Solid fraud tools.
• Opayo (formerly SagePay, now Elavon) — very common with mid-market UK SMEs. Good for predictable monthly fees.
• Stripe — best developer experience, easiest scaling abroad (US / EU multi-currency), modern Strong Customer Authentication (SCA / 3DS2). Slightly higher base rate.
• Adyen — enterprise / multi-region. One contract for UK + EU + APAC, unified reporting, but minimum monthly volume.

We integrate any of them — many UK stores run Stripe + Klarna + BACS as a three-rail stack.

Klarna and Clearpay (UK-branded Afterpay) are both essential for UK fashion / DTC — ~30–40% of UK online shoppers under 35 expect a Pay-in-3 / Pay-in-4 option. Both have official Magento 2 modules:

• Klarna — Pay in 3, Pay in 30 days, financing. Strong UK + Nordic + DACH. Higher fees (3–6%) but lifts AOV 30–50%.
• Clearpay — Pay in 4 over 6 weeks. Big in UK / AU fashion. Slightly cheaper than Klarna.

We install, configure, and wire the on-site widgets (PDP price-line + cart + checkout). FCA-compliant disclosure copy reviewed. We also handle the FCA-required affordability check banner that came in May 2026.

Most UK stores need 2–3 carriers for cost optimisation:

• Royal Mail Tracked 24 / 48 + Special Delivery — cheapest for low-weight (< 2kg).
• DPD UK — best 1-hour delivery slot, premium retail. Native Magento module via DPD’s API.
• Evri (formerly Hermes) — cheapest 2–5kg, weak tracking but good price.
• Yodel / ParcelForce — backup / regional use.

We integrate via ShipperHQ (rule engine) or direct carrier modules — rule-based routing by weight, postcode, value, and delivery promise. Booking labels auto-generated from Magento order grid; tracking webhooks update sales_order.

Highlands & Islands (Scottish Highlands, Hebrides, Orkney, Shetland, Northern Ireland, Channel Islands, Isle of Man) are a known Magento gotcha — carriers charge surcharges of £5–£25 that vanilla Magento doesn’t apply by default. We:

1. Add a postcode-prefix matrix (IV, KW, PA, PH, ZE, BT, GY, JE, IM ranges) to shipping_table_rate.
2. Wire ShipperHQ rules so only Royal Mail or specific premium carriers serve those postcodes — no DPD next-day promises that can’t be kept.
3. Apply surcharges in checkout with clear copy (“£X surcharge for Highlands & Islands”) so customers don’t complain post-purchase.
4. Optionally exclude express options for those regions to avoid late-delivery refunds.

We’ve shipped this for a Manchester homeware store + a Glasgow whisky retailer.

Three patterns, depending on volume:

• Single-store, geo-priced — one storefront with VAT calculated by destination. Cheapest. Good for small UK-first stores selling occasionally to EU.
• Two storefronts, shared catalogue — store for UK (GBP, UK VAT, Royal Mail) and store for EU (EUR, IOSS, DHL Europe). One Magento backend, one PIM, separate checkouts. Most popular pattern.
• Two websites, two backends — legally separate UK Ltd + EU GmbH/BV. Best for £5M+ stores with EU fulfilment hub (Netherlands / Ireland). Magento website-level split.

We architect, build, and migrate live data — including reroute + 301 from old single-store URLs.

Real, daily, 4–6 hours of working overlap:

• India Standard Time = UTC+5:30
• UK = UTC+0 (GMT, winter) or UTC+1 (BST, summer)
• Overlap window: 1 PM – 7 PM IST = 8:30 AM – 2:30 PM GMT (winter) or 9:30 AM – 3:30 PM BST (summer).

That covers your morning standup, mid-morning review, and lunchtime hand-off. Daily 4 PM GMT review on staging is the typical cadence. If you need late-day overlap (post-3 PM GMT) we can flex 2–3 days/week. Slack / WhatsApp async covers the rest. We’ve worked this way with London, Manchester, Edinburgh, and Bristol clients for years.

Depends on your volume + budget:

• Adobe Commerce Cloud (Dublin region) — best if you’re already on Adobe Commerce. Auto-scaling, Fastly CDN, 24/7 Adobe support, < 30ms latency to most UK postcodes. Costs £25k+ /yr, locks you to Adobe.
• UKFast / Pulsant — UK-based managed Magento hosting. Cheaper (£5–15k /yr), excellent UK support, ISO 27001 accredited, data stays in UK (good for some UK GDPR / public-sector contracts). Less auto-scaling.
• Cloudways London / Linode London / Hyvä Cloud — good middle ground for £500k–£5M stores, £200–800 /mo.

We help benchmark + migrate — the right answer is rarely the most expensive one.

Almost certainly yes if you’re on Luma. UK fashion shoppers convert dramatically better on fast mobile experiences:

• Lighthouse 95+ on Hyvä vs typically 40–60 on Luma fashion themes — Google ranks fast pages higher for category/PDP queries.
• Hyvä Checkout loads in < 1s — 50% lower bounce vs Magento Luma checkout, especially mobile.
• Klarna / Clearpay widgets render natively without the React/jQuery double-render Luma has.
• Royal Mail / DPD / Evri shipping pickers render instantly, no spinner-on-spinner.

Typical migration timeline: 4–6 weeks. Conversion lift in the first 90 days post-launch is usually 8–25% from speed alone — then optimisation work compounds it. See our Hyvä service page for fixed-price tiers.

iDEAL handles 70%+ of all Dutch online payments — if your store doesn’t support it, you’re losing two-thirds of your potential checkouts. The standard route is via Mollie or Adyen (both Dutch-founded), each of which exposes iDEAL as a payment method out of the box. We install and configure the official Mollie or Adyen Magento modules, wire them to your bank-acquirer of choice, and turn on iDEAL 2.0 (formerly iDEAL+) which is rolling out across 2024 – 2025 with one-tap mobile checkout, recurring SEPA mandates, and tokenisation. Payment-method ordering, bank-list rendering and PSD2 SCA hand-off are all configured at the store-view level so iDEAL appears first for NL customers and elsewhere for BE / DE.

Both are excellent and both are Dutch-founded, but they target different sizes of merchant. Mollie is the simpler choice for SMBs — flat per-transaction pricing (~€0.29 + ~1.8% for iDEAL), 2-day onboarding, no monthly fee, and a Magento module that’s a 5-minute install. It supports iDEAL, Bancontact, Klarna, Apple Pay, SEPA, credit cards. Adyen is the better choice for high-volume / enterprise stores — interchange-plus pricing (cheaper at scale), unified global processing, advanced fraud (RevenueProtect), and a much more powerful back-office (financial reports, settlement timing, dispute automation). Rule of thumb: under €5M revenue Mollie wins on simplicity, over €5M Adyen wins on cost. We’ve shipped both and can recommend based on your transaction volume + currencies + cross-border footprint.

AVG is the Dutch implementation of GDPR, and the Dutch Telecommunicatiewet (Telecomwet) + ePrivacy rules require explicit opt-in for any non-essential cookie — no “by using this site you accept” banners, no pre-ticked boxes. We install Cookiebot, OneTrust, or a Magento-native consent manager (Mageplaza GDPR / Amasty), configure it to: (a) block GTM, Hotjar, marketing pixels and chat widgets before consent, (b) categorise cookies as essential / functional / analytics / marketing, (c) honour withdrawal of consent without re-asking immediately, and (d) log consent records (timestamp, IP, scope) for the 24-month Autoriteit Persoonsgegevens (AP) audit window. We also wire DSAR request flows to your support inbox.

Three rates: 21% standard (most goods), 9% reduced (food, books, medicines, public transport, hairdressers, etc.), and 0% (intra-EU B2B with valid BTW-nummer + intra-community supply). In Magento we configure: (1) tax classes per product (21% default, 9% for food/books, 0% for B2B EU), (2) tax rates per customer-tax-class (B2C BTW-included, B2B BTW-excluded with reverse-charge note), (3) BTW-nummer validation at customer registration via VIES (the EU’s central VAT validation service), (4) invoice templates that show BTW separately with the correct percentage and your BTW-id + KvK-id, and (5) the "BTW verlegd" reverse-charge text on cross-border invoices.

The Kleineondernemersregeling (KOR) exempts Dutch businesses with under €20,000 in annual NL revenue from charging BTW. If you opt in, you don’t charge BTW, can’t reclaim input BTW, and can’t show BTW on invoices — instead invoices must say "vrijgesteld van BTW vanwege de kleineondernemersregeling". In Magento this means: (a) tax class “None” on all products with a 0% rate, (b) invoice template that omits BTW lines and shows the KOR-exemption note, (c) checkout that doesn’t display "incl. BTW" anywhere. If you cross €20,000 mid-year you must register for BTW immediately and start charging from that day — we add a Magento dashboard widget that warns when revenue approaches €18k.

PEPPOL (Pan-European Public Procurement OnLine) is the EU standard for structured e-invoices. In the Netherlands it’s mandatory if you sell to government suppliers (central government has required it since 2017, municipalities since 2019) and increasingly expected for B2B. It’s not yet mandatory for private B2B, but the EU’s VAT in the Digital Age (ViDA) reform will roll it out across 2028–2030. We integrate PEPPOL via Magento extensions (Storm, AvaTax, or custom via the official PEPPOL Access Point providers like Tradeshift, Storecove or BasWare). Output is a structured UBL 2.1 XML invoice routed via the PEPPOL network — not a PDF. If you sell to ministries or larger municipalities you need this; if you’re pure DTC you can wait.

For intra-EU B2B sales you can apply the 0% reverse-charge BTW rate only if the buyer has a valid BTW-nummer registered in the EU’s VIES database (VAT Information Exchange System). In Magento we add a custom customer attribute btw_nummer (or vat_id if you’re using Magento’s built-in field) to the registration form, validate it real-time against the VIES SOAP API on submission, and gate the B2B-only customer group + 0% tax rate behind a successful validation. We also store the validation timestamp for audit and re-validate every 90 days (since BTW-nummers can be revoked). For non-EU B2B (UK post-Brexit, US, etc.) we use the relevant local validation API or fall back to manual approval.

PostNL dominates Dutch parcel delivery and Dutch shoppers expect three things: (1) a delivery date picker at checkout (PostNL guarantees next-day for 99% of NL addresses), (2) pickup-point selection (~3,500 PostNL points in NL — Dutch shoppers love these for "delivery while at work"), and (3) a self-service return label. We use the official PostNL Magento extension or one of the popular alternatives (Tig PostNL is the de-facto choice). It wires to your PostNL business contract and adds: address-validation against the Dutch postcode + house-number database, dimensional-weight quoting, label generation directly inside the order admin, COD support if needed, and webhook-driven shipment-tracking sync back into Magento. We also integrate DHL Parcel NL as a fallback / multi-carrier option and Pakketdienst Quick for B2B same-day Randstad delivery.

Yes — this is one of Magento’s strongest features. We typically architect it as 1 website → 3 stores (NL, BE, DE) → 3 store-views with a shared catalogue and shared customers, but per-store BTW rates, currencies (all EUR but separate tax-config), languages (Nederlands / Frans-Nederlands / Deutsch), payment methods (iDEAL for NL / Bancontact for BE / Klarna + Sofort for DE), and shipping carriers (PostNL for NL / bpost for BE / DHL for DE). Hreflang per store-view, separate sitemaps, separate Google Search Console properties. Same Magento backend, ~30% lower TCO than running three separate Magento installations.

Depends on revenue + ops maturity. Adobe Commerce Cloud (Frankfurt region) is the right pick if you’re on Adobe Commerce (paid Magento), have >€5M revenue, want managed Fastly + New Relic + 24/7 Adobe support, and don’t want a sysadmin on staff — ~€30k/yr+. TransIP (Dutch, founded in 2003 in Leiden) is excellent for SMBs — cheap (~€30/mo VPS), local NOC, native Dutch support, Magento-optimised hosting plans starting around €100/mo. Leaseweb (also Dutch, Haarlem) is the choice for high-traffic / B2B where you need bare-metal or hybrid — ~€200/mo+ for proper Magento dedicated. Combell and Hostnet are alternatives. We can audit your current hosting + recommend per workload.

Almost certainly yes. Dutch shoppers have very low patience for slow checkout (consistently in EU surveys), and Hyvä cuts page-load to < 1.5s and Lighthouse to 95+. Combined with iDEAL (which is already a 2-tap flow) the result is a checkout that’s objectively faster than most native apps. Stores typically see 8 – 25% conversion lift in the 90 days post-migration. Hyvä supports iDEAL via Mollie / Adyen / Multisafepay out of the box, ships with native Hyvä Checkout, and integrates with PostNL pickup-point modules. Project takes 4 – 6 weeks for a typical NL DTC store and pays back in 2 – 4 months from conversion lift alone.

India is UTC+5:30 and the Netherlands is UTC+1 (CET) or UTC+2 (CEST in summer). The reliable daily working overlap is 4 – 6 hours — specifically 12 PM – 6 PM IST = 7:30 AM – 1:30 PM CET. We schedule status calls + design reviews in your morning (your espresso, our afternoon) and ship the day’s work to staging by ~5 PM CET. Loom recap + written EOD note follows so you wake up with the full picture. For urgent production incidents we’re reachable on WhatsApp / Slack until ~9 PM CET. No "we’ll get back to you tomorrow" surprises — you have real working overlap, not just async hand-offs.

TWINT is the dominant Swiss mobile-payment rail — 5M+ Swiss users, near-mandatory for any Swiss DTC checkout. Two integration paths:

• Direct TWINT acquirer — via Datatrans or Wallee, which both have certified Magento 2 modules. Best for stores doing >CHF 500k/yr in Swiss volume; fees ~1.3–1.8%.
• Stripe CH or Adyen as TWINT enabler — both now offer TWINT as a payment method on top of their existing Magento connectors. Best for multi-region stores that already run Stripe / Adyen elsewhere; fees slightly higher (~2.0–2.5%) but one contract.

We wire TWINT QR-on-PDP, TWINT in checkout, and the QR-on-paper-receipt flow for omnichannel B2B. Sandbox tested before live-key swap on cutover night.

Switzerland has 4 official languages, and Swiss shoppers strongly prefer their regional language. The right Magento structure:

• One website (single product catalog, single inventory).
• One store for Swiss commerce (CHF, MWST 8.1%, Swiss Post rules).
• 4 store views: de_CH, fr_CH, it_CH, en_CH.
• URL structure: /de/, /fr/, /it/, /en/ with hreflang per view (de-CH, fr-CH, it-CH, en-CH).

Translations live in Magento’s native i18n + catalog_product_entity_*_store tables — we manage the translation pipeline (typically via Crowdin or Phrase) so the DE source-of-truth syncs cleanly to FR / IT / EN. Locale-aware schema.org emitted per store-view.

revFADP (revised Federal Act on Data Protection) is Switzerland’s data-protection law, in force since 1 September 2023. It replaced the 1992 FADP and is broadly “GDPR-equivalent” — the EU recognises it under an adequacy decision, so EU↔CH data flows continue freely.

Key Swiss specifics vs EU GDPR:

• Only natural persons are protected (EU GDPR also covers some legal-entity edge cases).
• Profiling has stricter explicit-consent rules.
• DPO appointment is voluntary (not mandatory like under EU GDPR Art. 37).
• Sector regulators on top — FINMA for finance, BAG for health.
• Penalties are applied to individuals (executives), not just companies.

We wire revFADP-compliant cookie consent, DSAR automation, retention rules in customer + sales_order, and a privacy notice in DE / FR / IT / EN.

Switzerland is not in the EU customs union, so every CH↔EU parcel crosses a customs border. For premium DTC (luxury, watches, fashion), DDP (Delivered Duty Paid) is the expected default — the seller pre-pays VAT + customs so the customer never sees a surprise bill at the door. Two-part Magento setup:

1. Pricing engine — we add an EU-VAT calculation layer (per destination country: DE 19%, FR 20%, IT 22%, NL 21%, etc.) on top of CHF list prices, and quote “CHF X (DDP, all duties included)” in checkout.
2. Carrier rules — Swiss Post + DHL CH both offer DDP-bonded labels with the right HS commodity codes per SKU. We populate product_attribute with HS codes (8-digit), country-of-origin, and net weight, and the carrier module emits the right CN23 / commercial-invoice docs.

For low-value parcels (< EUR 150), IOSS to EU is optional; for >EUR 150 it’s mandatory full customs clearance.

Swiss MWST (Mehrwertsteuer / TVA / IVA) has three rates from 2024+:

• 8.1% standard — raised from 7.7% on 1 January 2024. Most goods + services.
• 3.8% special — hotel accommodation.
• 2.6% reduced — food, books, medicines, newspapers.

Registration threshold is CHF 100k worldwide turnover — foreign sellers shipping into CH must register if they cross it. Magento setup:

1. Configure 3 tax rates in tax_rate table per canton (rates are federal so it’s really one set, but we keep the canton column for future-proofing).
2. Map MWST tax classes to product attribute sets (e.g. food vs general).
3. Show price inclusive of MWST on PDP / cart / checkout (Swiss B2C convention) but exclusive for B2B store views.
4. Quarterly MWST return: export from Magento, file via the federal eMWST portal.

Pick by stage + budget:

• Hostpoint (CH-based, St. Gallen) — managed hosting, good for <CHF 1M stores. Data stays in CH (good for some FINMA-touching catalogs). CHF 50–200 / mo.
• Infomaniak (CH-based, Geneva) — eco-friendly, ISO 27001, popular for French-speaking CH. Similar price band to Hostpoint.
• Cyon / Metanet — smaller CH-based options for SMBs.
• AWS Zürich (eu-central-2) — opened 2022, ideal for >CHF 5M stores wanting auto-scale + Swiss data residency. CHF 500–3,000+ / mo.
• Adobe Commerce Cloud (Frankfurt) — if you’re already on Adobe Commerce. ~30ms latency to most Swiss postcodes. Data leaves CH (DE-hosted), worth checking against your revFADP risk register. CHF 25k+ /yr.
• Hyvä Cloud — great middle-ground for Hyvä-based Swiss stores.

We benchmark + migrate — the right answer depends on data-residency requirements (FINMA / health) and traffic profile.

Many Swiss stores want both: PostFinance (the Swiss Post-owned bank, hugely trusted by older Swiss shoppers) and Stripe CH (best dev experience + global cards). They live happily side-by-side as separate Magento payment methods:

• PostFinance e-Payment — via the official Magento 2 module; handles PostFinance Card, PostFinance e-finance, and a few common credit-card rails as a redirect flow.
• Stripe CH — via the official Stripe Magento 2 module; handles Visa/MC/AMEX, Apple Pay, Google Pay, Klarna, and now TWINT as a payment-method.

We wire both, set Stripe as default for <CHF 200 orders (lower fees on cards) and PostFinance as default for >CHF 500 (higher trust on big-ticket items). Refund + chargeback flows tested for both. PostFinance settles to your Swiss IBAN; Stripe settles to whatever bank you nominate.

Almost certainly yes if you’re on Luma. Swiss luxury / watch shoppers expect the speed + polish of brand sites like Rolex, Omega, IWC — and they shop on iPhone in DE / FR / IT:

• Lighthouse 95+ on Hyvä vs typically 40–60 on Luma luxury themes — Google ranks fast pages higher for “rolex submariner switzerland”-style queries.
• Hyvä Checkout loads in < 1s — halves bounce on CHF 5,000+ checkouts where any latency creates doubt.
• TWINT QR + Apple Pay render natively on PDP without the React/jQuery double-render Luma has.
• Multi-language store-view switching (DE↔FR↔IT) is instant on Hyvä, vs full-page reflow on Luma.
• Datatrans / Wallee enterprise checkout integrate cleanly via Hyvä payment-method bridge.

Typical migration timeline: 4–6 weeks. Conversion lift in the first 90 days post-launch is usually 8–25% from speed alone. See our Hyvä service page for fixed-price tiers.

Pure-language store-views work for most Swiss stores, but for stores with strong regional brands (e.g. luxury watches with Zürich vs Geneva flagship boutiques) we sometimes layer a region dimension on top:

• Default Swiss store: 4 store-views (DE / FR / IT / EN), one CHF price-list, MWST 8.1%.
• Region overlays via customer_segment or store_group: Zürich-default sees the Zürich boutique address + DE; Geneva-default sees the Geneva boutique address + FR; Ticino-default sees the Lugano boutique address + IT.
• Click-and-collect: per-region pickup-point modules so a Geneva shopper sees Geneva pickup options first.
• Hreflang: de-CH, fr-CH, it-CH, en-CH at minimum — we don’t fragment further by canton (Google treats CH-DE as one regional target regardless of which canton).

Real, daily, 4–6 hours of working overlap:

• India Standard Time = UTC+5:30
• Switzerland = UTC+1 (CET, winter) or UTC+2 (CEST, summer)
• Overlap window: 12 PM – 6 PM IST = 7:30 AM – 1:30 PM CET (winter) or 8:30 AM – 2:30 PM CEST (summer).

That covers your morning standup, mid-morning review, and lunchtime hand-off. Daily 14:00 CET review on staging is the typical cadence. If you need late-day overlap (post-15:00 CET) we can flex 2–3 days/week. Slack / WhatsApp async covers the rest. We’ve worked this way with Zürich, Geneva, Basel, and Bern clients for years.

Yes — and for most Swiss DTC stores it’s the right default. Three patterns by volume:

• Single store, geo-priced — one storefront, MWST + EU-VAT calculated by destination, DDP shipping for EU. Cheapest. Good for <CHF 2M stores.
• Two store-views per language pair — e.g. de-CH + de-DE, fr-CH + fr-FR, etc. One Magento backend, separate prices/tax per region. Most popular for >CHF 2M.
• Two websites, two backends — legally separate CH AG + EU GmbH/BV. Best for >CHF 10M with EU fulfilment hub. Magento website-level split.

Customs is the wrinkle — CH is outside the EU customs union, so even the “single store” pattern needs DDP labels + HS codes wired into Swiss Post / DHL. We architect, build, and migrate live data including 301 redirects.

Luxury watches are the canonical Swiss e-commerce vertical — high AOV (CHF 2k–500k), strict authorised-dealer rules, B2B (boutiques / retailers) + DTC (collectors) on the same catalog. Setup:

• Adobe Commerce (or Open Source + B2B-features extension) for the company entity — authorised dealers as company records with credit limits and customer-specific pricing.
• Catalog gating: limited-edition / haute-horlogerie SKUs hidden from DTC, visible to verified B2B accounts only.
• Payments: Datatrans or Wallee for high-AOV cards (3DS2 strong-auth), IBAN bank-transfer for B2B, TWINT only on <CHF 1k accessories.
• Authentication: serial-number + warranty registration on PDP, with optional NFC chip-tap (we’ve built this).
• FINMA / AML: for >CHF 100k orders the “Geldwäschereigesetz” (anti-money-laundering act) requires identity verification — we wire Onfido or Veriff into checkout.
• Multi-language: DE / FR / IT / EN baseline, optional ZH-Hant + Arabic for international collectors.

Typical timeline: 8–12 weeks. Enterprise tier above is sized for this.

Three patterns work, in increasing complexity and cost:

• Quiz-based shade finder — 5–7 questions on undertone, depth, finish, climate. Built natively in Magento with custom product attributes + a thin Alpine.js quiz UI on Hyvä. Conversion lift typically 0.8–1.4x baseline. Cost: ~$3k–$8k.
• AR try-on (Modiface / YouCam Makeup / Perfect Corp) — live camera overlay on PDP. Integration via REST + JS SDK. Conversion lift 1.4–2.8x on PDPs with AR. Cost: ~$8k–$20k integration + $1k–$5k/mo licence to the AR vendor depending on traffic.
• Hybrid (quiz → AR confirm) — quiz narrows to 3 shades, AR confirms the pick. Best conversion in my data.

For brands under ~$5M GMV, start quiz-only. AR pays for itself above ~$5M because the licence amortises across volume.

None of the “Shopify-native” subscription apps run on Magento directly. The viable options:

• Recharge — offers a Magento integration via API, but it’s thinner than the Shopify version. Best for hybrid brands already running Recharge on a Shopify D2C site.
• Bold Subscriptions — same caveat. API-level integration, not native admin.
• Mageworx Subscriptions / Aheadworks Subscriptions / Amasty Subscriptions — Magento-native extensions. These are the recommended path for Magento-first brands. Native admin, native checkout, native customer account dashboard. Mageworx is the most feature-complete in 2026.
• Custom build on Magento subscription product type — viable for $50M+ brands with unique flows (sample-then-buy + tier-locked products + skip-a-month + swap).

For most cosmetics + beauty Magento builds, Mageworx Subscriptions + a custom sample-then-buy flow on top is the right call.

Beauty brands need tier-based loyalty (Sephora Beauty Insider model). Three credible paths:

• Smile.io — integrates with Magento via API. Best UX, best onboarding flow, weakest customisation. Good for under $10M GMV.
• LoyaltyLion — deeper feature set (referrals + reviews + tier-locked products + partner rewards). Stronger Magento-side admin. Best for $5M–$50M brands.
• Mageworx Reward Points / Amasty Reward Points + custom tier engine — Magento-native, fully owned. Best for $20M+ brands wanting full data + flow control. We typically build the tier engine on top of Amasty.

If loyalty is >30% of your revenue today, lean toward Magento-native — the platform owns customer + order + spend data, so tier rules + earn / redeem + birthday rewards live where they belong instead of via a webhook round-trip.

Yes, with the right attribute model. Under MoCRA (Modernization of Cosmetics Regulation Act, 2022), US cosmetics need:

• Facility registration with FDA (one-time, you handle directly)
• Product listing per SKU (one-time per SKU, you submit to FDA via Cosmetics Direct portal)
• Adverse-event reporting workflow (15-day SAE rule)
• Ingredient list (INCI) on product label + PDP
• “Professional use only” flag where applicable

Magento setup: each product gets fda_listed, inci, warnings, professional_use_only, net_quantity attributes. A small Hyvä component on the US storefront renders the FDA-compliant label block from those attributes. The PDF label generator (PrinceXML / Dompdf) consumes the same attributes for physical labels. One source of truth.

EU Cosmetic Products Notification Portal (CPNP) is required before any cosmetic product is placed on the EU market. The workflow:

1. Responsible Person designated — an EU-based legal entity. Many brands appoint a third-party RP service (Obelis, Cosmetics Europe, etc.).
2. Cosmetic Product Safety Report (CPSR) — Part A (data) + Part B (assessor sign-off). Lives outside Magento.
3. CPNP notification per SKU — SKU-level data submitted to CPNP. Confirmation reference number stored as a Magento product attribute (cpnp_ref).
4. INCI list in EU local language(s) — per-storefront translation in Magento. INCI names follow EU Cosmetic Ingredients (CosIng) database.
5. Per-storefront PDP block — renders EU-compliant ingredient list, RP address, batch code, MoS / PAO icon.

I’ve done this for 4 EU beauty brands. Magento handles the storefront-rendering side cleanly; the regulatory workflow lives in your QA / RA tooling outside Magento.

Cosmetics in India fall under the Drugs and Cosmetics Act 1940 + Cosmetics Rules 2020 (replaced 1945 rules). Key requirements:

• Form COS-1 Import Registration for any imported cosmetic (Schedule D-III). Issued by CDSCO; valid 3 years; SKU-level.
• Manufacturing licence if produced in India (state-level Drug Controller).
• Hindi-language ingredient list on label is encouraged (not strictly required for English-literate markets but required for retail in many states).
• Net quantity in metric units (g / ml).
• Manufacturer / importer name + address + batch + manufacturing date + best-before date on label.

Magento setup: India storefront gets a separate website / store-view with cdsco_reg, hindi_inci, importer attributes. Hyvä PDP block renders Hindi INCI alongside English. Currency in INR, GST tax class. Razorpay / PayU / Cashfree as primary gateways — Stripe doesn’t play well with INR + GST + UPI in 2026.

Magento layered nav handles this cleanly with the right attribute design:

• Per-ingredient boolean attributes — contains_paraben, contains_sulfate, contains_fragrance, contains_gluten, contains_silicone, etc. Layered nav exposes “Free from” filters.
• Positive flags — is_vegan, is_cruelty_free, is_reef_safe, is_pregnancy_safe, is_clean_beauty. These tend to outperform “free from” framing for SEO and conversion.
• Customer profile allergens — logged-in customers save up to 5 allergens. Magento auto-warns on PDPs that contain them (red banner). Wishlist / cart adds blocked with a confirmation modal.
• INCI catalogue as a structured attribute (one source of truth for ingredient list, allergen flags, regulatory fields).

Performance note: with 30+ filter attributes on a 5,000 SKU catalogue, you’ll need Elasticsearch / OpenSearch (not MySQL native search). Magento ships ES out of the box from 2.4.x.

Three credible paths for beauty brands:

• Refersion — affiliate-first, mid-market. Magento integration via API / pixel. Tracks per-influencer sales by promo code or unique link. Best for under $10M GMV with tier rewards (1–5%, 5–10%, 10%+ commission brackets).
• Aspire (formerly AspireIQ) — influencer-first, full lifecycle (discovery + outreach + brief + approve + track + pay). Pricier but pays back fast for brands running 50+ influencer relationships. Magento integration via UTM + promo-code attribution.
• Impact (impact.com) — enterprise, mature partnership platform. Best for $20M+ brands with diverse partner mix (influencer + affiliate + B2B referrer + content site).
• Magento Affiliate Pro / Mageworx Affiliate — Magento-native extension. Cheapest, weakest UX. OK as a starting point if you want full data ownership.

I usually recommend Refersion or Aspire for Magento-first beauty brands. UGC integration via Yotpo or Bazaarvoice runs alongside — influencer-driven UGC pulled into PDPs is a 12–18% conversion lift.

Both ship Magento extensions and both work cleanly. Decision criteria:

• Yotpo — mid-market, $1M–$50M GMV sweet spot. Strong photo / video review collection (post-purchase email + SMS). Loyalty + referrals bundled. Good Magento extension, native admin. Cheaper than Bazaarvoice.
• Bazaarvoice — enterprise, $50M+ GMV. Stronger syndication (push reviews to Walmart / Amazon / Sephora retailer channels). Better moderation tooling for high-volume brands. Pricier per-review.
• Stamped.io / Trustpilot — budget alternatives. Stamped is fine; Trustpilot is too generic for beauty (no shade / skin-type filtering on reviews).

Beauty-specific feature to ask about: review filtering by skin tone / skin type / age range. Yotpo and Bazaarvoice both support it; Stamped doesn’t. This filter is a 8–15% conversion lift on foundation / serum PDPs because customers find reviews from people who match them.

Three layers:

1. Sample box product type — a Magento bundle product where the customer picks 4–6 sample-size variants from a curated pool. $10–$20 box price, free with subscription.
2. Sample-to-full mapping — each sample SKU links to its full-size SKU via a Magento product attribute (full_size_sku). Drives the post-box email automation.
3. Conversion automation — 14 days after the sample box ships, an email triggers per-sample “loved it? get the full size at 20% off” with a one-click upsell that drops the full-size SKU into the cart with the discount applied via Magento cart price rule.

Magento implementation: bundle + custom attribute + Klaviyo / Mailchimp transactional flow listening to a custom event from Magento on box-shipped. Sample-to-full conversion runs 22–38% in beauty data I’ve seen, which is wildly profitable because the sample box CAC is already paid down.

Honest take. Shopify wins for beauty brands when: catalog is <100 SKUs, single region, no subscription program, no tier-based loyalty, low-volume influencer relationships, ops team is 1–2 people. The Shopify app ecosystem has the best beauty-native apps (Klaviyo, Recharge, Smile, Yotpo) wired together cleanly.

Magento wins when any of these are true: catalog >200 SKUs with shade variants, subscription + loyalty stacked on top of D2C, multi-region compliance (FDA + EU CPNP + India CDSCO), influencer programs with tier rewards, want full data ownership over customer + skin profiles, multi-brand or multi-store on shared inventory, B2B salon supply alongside D2C.

The crossover point I see in practice is around $5M–$10M GMV. Below that, Shopify pays for itself in ops simplicity. Above that, the Shopify app stack starts costing $5k–$15k/mo in app fees + the data-fragmentation tax bites — and Magento + Hyvä comes out cheaper at scale even with the higher dev cost.

Honest fixed-price tiers, no per-hour surprises. All three include pre-project audit, regression QA, blue-green deploy, Lighthouse 90+ guarantee, and 14 days of post-launch bug-fix coverage.

• Beauty Express ($12k–$25k, 6–8 weeks) — Hyvä storefront + ingredient/allergen filters + quiz-based shade finder + Mageworx Subscriptions + Smile.io loyalty integration. Single region (US or EU or IN).
• Beauty Standard ($25k–$60k, 10–14 weeks) — everything in Express + AR shade matcher (Modiface / YouCam) + tier-based loyalty (LoyaltyLion or custom Amasty) + Refersion influencer tracking + Yotpo UGC. Two regions (e.g. US + EU).
• Beauty Enterprise ($60k–$150k+, 14–24 weeks) — everything in Standard + multi-region compliance (FDA + EU CPNP + India CDSCO) + Akeneo PIM + B2B salon supply layer + Aspire / Impact partnership platform + custom loyalty engine. Three+ regions, multi-brand.

Hyvä licence (€1,000 one-time or €100/yr) is paid separately to Hyvä Themes. Subscription / loyalty / AR / PIM SaaS fees are passed through (no markup).

A verdict of Compatible means the extension renders its frontend HTML correctly under Hyvä 1.3+, doesn’t inject Knockout or RequireJS dependencies, doesn’t break the cart or checkout flow, and survives a clean reindex + setup:upgrade. Backend admin behaviour is identical regardless of frontend theme — every status here judges only the storefront. So if a verdict says “Compatible”, you can install it next to Hyvä without porting work; if it says anything else, the row description explains exactly what gap remains.

Yes. A Hyvä module verdict means the vendor (or community) ships a small bridge package — usually free, distributed via composer or marketplace — that re-renders the extension’s frontend in Tailwind+Alpine instead of Luma’s Knockout. The pattern is: composer require vendor/extension-hyva alongside the original vendor/extension, run setup:upgrade, and the storefront just works. Both packages are required — the original handles the backend and business logic, the Hyvä one re-skins the frontend.

A Partial verdict means the backend works perfectly under Hyvä but parts of the frontend — usually small AJAX widgets or PDP-block JS — are still in Knockout/RequireJS and render either broken or not at all. The fix is rewriting the frontend templates in Alpine.js + Tailwind. Typical port budget: 6 to 30 hours per extension, depending on how big the frontend surface is. A simple PDP info-block is 6h; a quote-cart UI or marketplace vendor-storefront can be 24–30h. The Partial-row description on the checker tells you which surface needs work.

Blockers can’t cohabit with Hyvä — they own a flow Hyvä also wants to own (most often the entire checkout). The fix is replacement, not bridging: remove the blocker, install the Hyvä native equivalent, migrate any custom config across. The most common case is a One-Step-Checkout extension — replaced by Hyvä Checkout (free, included in Hyvä 1.3+). For each Blocker the checker shows you what to swap to. Replacement effort is typically 1–3 weeks of dev time depending on how many custom payment/shipping integrations you had hooked into the old flow.

Exactly because Hyvä has its own checkout. Mageplaza, Amasty and IWD One-Step-Checkout extensions all rewrite Magento’s entire checkout in Knockout — which is the layer Hyvä replaces. Two checkouts can’t cohabit. Hyvä Checkout already does what those extensions do (one-page render, < 1 second, every major payment gateway, Klarna/Adyen/Stripe-element bridges) and ships free with Hyvä 1.3+. Removing the OSC extension also drops the licence fee — net win on cost, performance, and stability.

Every row was hand-verified by installing the extension on a Hyvä 1.3+ staging store and running real customer flows — not auto-scraped, not vendor-claimed. The database is updated every quarter, plus ad-hoc whenever a vendor ships a new Hyvä bridge. Last full sweep: Q2 2026. If you spot a row that looks out of date based on your own testing, drop me an email — I’ll re-verify and update for everyone.

Treat it as ? Unknown: assume it might need work until proved otherwise. The fastest way to lock the verdict is a 2-hour spike — install the extension on a Hyvä staging copy, click through the customer flows, screenshot any visual or functional gaps. That gives you the verdict, the porting effort, and the risk profile. If you have several unknowns, send the list via the audit form below and I’ll spike the lot in a single day.

Three steps:

1. Lock all Unknowns via 2-hour spikes — never start a migration with unknowns in scope.
2. Quote every Partial with a fixed-price port budget (use the per-extension hours estimate × your dev rate).
3. Plan replacements for every Blocker — spec the swap-out (e.g. Hyvä Checkout for OSC) before the migration kicks off.

Add the totals and you’ve got a realistic Hyvä migration scope before you sign anything. Most surprise-rework on Hyvä projects comes from skipping this audit and discovering Partials / Blockers mid-build.

Per-extension port costs (rule of thumb, freelance rates):

• Small frontend surface (one PDP block, one info-widget): 6–10 hours = $500–$1,200.
• Medium surface (multi-block, AJAX category filter, customer-account page): 12–20 hours = $1,200–$2,400.
• Large surface (quote-cart UI, vendor storefront, multi-step wizard): 24–30 hours = $3,000–$4,500.

Agency rates run 1.5–2× this. The numbers are based on Hyvä ports I’ve shipped 2024–2026 — not vendor estimates.

The checker covers third-party extensions only — in-house custom modules need a per-module audit. Same verdict scheme applies: read the module’s frontend code, check whether it uses Knockout / RequireJS, count the number of phtml templates that reference Magento’s frontend JS APIs, estimate the Alpine port effort. As a quick rule of thumb, a custom module with no frontend code is automatically Compatible; one with 2 or more phtml templates and AJAX is almost always Partial. Send the module list via the audit form for a written verdict per module.

Hyvä 1.3+ is the recommended baseline because it ships Hyvä Checkout natively (no separate licence) and unlocks the official Adobe Commerce 2.4.9 native-Hyvä integration. Hyvä 1.2.x is still supported by every vendor compat module here, but if you’re upgrading the theme anyway, jump to 1.3+. Hyvä 1.1.x and earlier — some compat modules may have minor regressions; treat anything older than 1.2 as legacy and budget a small upgrade tax.

Yes — almost always. Even with 5–10 Partials and 1–2 Blockers, the Hyvä migration cost is recovered within 3–9 months of going live for most stores: 8–25% conversion lift from speed alone, lower hosting bills (fewer JS dependencies), and faster future feature builds (Tailwind+Alpine is roughly 2× productivity for frontend work vs Knockout). The audit just makes sure you go in with eyes open and a fixed budget, not with surprise rework eating the savings. Every store I’ve migrated since 2024 broke even on the Hyvä investment within a year.

GrabPay is the regional dominant mobile wallet across SEA — if your SG store doesn’t accept it, you’re leaving 25–40% of mobile checkouts on the table. Two integration paths:

• Direct GrabPay Magento module — OAuth + redirect-flow checkout, native to Magento order grid. Best for pure SG / SEA stores.
• Via Stripe Singapore or Adyen — GrabPay surfaces as a payment method alongside cards / Apple Pay / Atome. One integration, one settlement, one reconciliation. Best for multi-rail stores.

We wire merchant credentials, sandbox + production, webhook listeners for payment_intent.succeeded, and refund / partial-refund flows. Reconciliation lands in your accounting software with SGD breakdown + GST 9% line item.

Pick by use case — most SG stores run two or three rails simultaneously:

• GrabPay — regional dominant, best for SEA cross-border (covers MY / ID / PH / TH too). Higher fees (2–3%) but huge demographic reach.
• PayLah! (DBS) — Singapore-first mobile rail, dominant with DBS / POSB customers (~5M users). Lower fees, instant settlement to DBS business accounts. Best for pure-SG stores.
• Stripe Singapore — best developer experience, multi-currency (SGD / USD / MYR / IDR), card + Apple Pay + Google Pay + Atome BNPL all unified. Slightly higher base rate.
• Adyen — enterprise / multi-region. One contract for SG + EU + APAC, unified reporting.

Most pure-SG DTC stores run Stripe SG + GrabPay + PayLah! as a three-rail stack. SEA hubs add Adyen for unified regional reporting.

The Personal Data Protection Act 2012 (revised 2021) is Singapore’s GDPR-equivalent. Three layers to wire into Magento:

1. Consent & notification — explicit opt-in for personal-data collection. Cookie banner with granular toggles (essential / analytics / marketing). We integrate Cookiebot / Usercentrics / Klaro with Magento’s native cookie API + GTM.
2. DNC (Do-Not-Call) registry — before any SMS / WhatsApp / call marketing, scrub against the SG DNC list. Wire via API on outbound campaigns.
3. DSAR / deletion / portability — customers can request access, correction, deletion of their data. We build admin tools + automated flows in customer + sales_order tables.

Plus Spam Control Act for unsolicited commercial email (opt-in + unsubscribe + sender ID), and MAS guidelines if you’re fintech-adjacent (BNPL, crypto-tangential, regulated payments).

GST in Singapore is now 9% (raised from 7% in two stages: 7% → 8% in Jan 2023, 8% → 9% in Jan 2024). Three scenarios:

• SG-registered seller — mandatory GST registration above S$1M turnover. Charge 9% on B2C, zero-rate exports. UEN + GST number visible on invoices.
• SG seller below S$1M — voluntary registration possible (good for input-tax claims). Otherwise no GST charged.
• Foreign seller (OVR) — Overseas Vendor Registration required if selling digital services + low-value goods (≤ S$400) into SG above S$100k turnover. Register with IRAS, charge 9% GST, file quarterly returns.

We rebuild Magento’s tax engine with these rules, validate UEN + GST numbers via IRAS API for B2B counterparties (zero-rate B2B exports), and wire MTD-equivalent reporting to Xero / QuickBooks SG.

Yes — this is the most common Singapore Magento pattern. Singapore is the natural SEA HQ for ecommerce: stable currency, English-primary, AWS / Azure / GCP all have SG regions, fintech-friendly regulation. Three architectures:

• Single-store, multi-currency — one storefront (SGD primary) with currency switcher (MYR / IDR / PHP / THB). Cheapest. Geo-IP suggests local currency. Good for < S$5M stores.
• Multi-storefront, shared catalogue — one Magento backend, separate storefronts per country (sg.example.com, my.example.com, id.example.com). Local payment methods per region (GrabPay covers most), local fulfilment, local language. Most popular for S$5M–S$50M.
• Multi-website, separate backends — legally separate Pte Ltd entities for tax / regulatory reasons. Best for enterprise / regulated verticals.

We’ve shipped all three. Lazada / Shopee storefront integration is layered on top — Magento as source-of-truth, marketplace listings synced via API.

UEN (Unique Entity Number) is Singapore’s business identifier — mandatory for every registered company, society, and government entity. For B2B Magento stores, UEN validation gates trade-account registration. Two approaches:

• Format validation — regex check on the UEN format (9-digit business, 10-digit local company, 10-digit foreign company, etc.). Catches typos but doesn’t verify existence.
• Live API validation — we wire to ACRA BizFile API (Singapore’s Companies Registry) to verify UEN + entity name + status (active / struck-off). Cached for 24h.

For Adobe Commerce B2B, this slots into company table as a custom attribute. Approval workflow: customer registers with UEN → auto-validate → admin approves → trade pricing unlocked. We also add GST-number validation for input-tax claim invoicing.

Depends on your volume + regulatory needs:

• AWS Singapore (ap-southeast-1) — gold standard. Auto-scaling, CloudFront edge, < 20ms latency to all SG postcodes. Multi-AZ failover. Best for S$5M+ stores. Costs S$800–S$5,000+ /mo depending on traffic.
• Microsoft Azure SG / Google Cloud SG — comparable to AWS, sometimes cheaper credits / commitment-tier pricing. Good if you’re already on those clouds for other workloads.
• Vodien — SG-based managed Magento hosting. Cheaper (S$300–S$800 /mo), excellent SG support in SGT hours, good for S$500k–S$5M stores. Less auto-scaling.
• Exabytes / DigitalOcean SG — mid-market, predictable billing, good for pre-launch and starter stores.
• Adobe Commerce Cloud (Sydney with SG edge via Fastly) — if you’re on Adobe Commerce already.

We help benchmark + migrate — the right answer depends on your traffic shape, peak events (CNY / Great Singapore Sale / 11.11), and PDPA data-residency preferences.

Depends on your audience — EN is enough for most SG DTC stores targeting CBD / Orchard professional segments. Add languages strategically:

• Mandarin (zh-Hans-SG) — recommended if you sell to older demographics, FMCG, traditional retail, or cross-border to MY / China. Adds ~20% addressable market in SG.
• Malay (ms-SG) — recommended if you serve halal / Islamic-finance / cross-border to MY / ID. Limited within SG itself but big regional lever.
• Tamil (ta-SG) — niche but valued for inclusion in some segments (services, government suppliers). Often a brand-positioning move.

Magento implementation: separate store_view per language, locale-aware structured data, hreflang per language code (en-SG, zh-Hans-SG, ms-SG, ta-SG). Per-store-view product attributes + URL-slug translations. We can phase this in — ship EN first, layer Mandarin in v2.

Atome is the SEA-native BNPL leader — Pay-in-3 for SG / MY / ID / PH / TH / VN / HK. Conversion lift on AOV > S$100 is typically 15–30% in SG fashion / lifestyle / electronics. Two integration paths:

• Direct Atome Magento module — native to order grid, supports Pay-in-3 + Pay-in-4 (Atome Plus). Best for pure-SG stores, faster settlement.
• Via Stripe Singapore — Atome surfaces alongside cards / Apple Pay / GrabPay. One integration, one settlement. Best for multi-rail stores.

We wire merchant credentials, sandbox / production, on-site widgets (PDP price-line: “or 3 × S$XX with Atome” + cart + checkout), MAS-required disclosure copy, and the affordability checkpoint that came in 2024 with the SG BNPL Code of Conduct. Refunds + partial refunds + dispute flows handled.

Real, daily, 5–7 hours of working overlap — one of the best of any country we work with:

• India Standard Time = UTC+5:30
• Singapore Standard Time = UTC+8 (no DST)
• Overlap window: 10 AM – 5 PM IST = 12:30 PM – 7:30 PM SGT.

That covers your full afternoon and end-of-day. Daily 5 PM SGT review on staging is the typical cadence — lands in the back-half of your working day, gives us the morning IST to ship fixes overnight (your time). Slack / WhatsApp async covers the rest. We’ve worked this way with Orchard luxury, CBD B2B, and Tampines DTC clients for years.

Almost certainly yes if you’re on Luma. SG mobile shoppers are demanding — Orchard luxury, Tampines lifestyle DTC, Bishan home + lifestyle — all convert dramatically better on fast Hyvä:

• Lighthouse 95+ on Hyvä vs typically 40–60 on Luma fashion / luxury themes. Google ranks fast pages higher for category / PDP queries.
• Hyvä Checkout loads in < 1s — 50% lower bounce vs Magento Luma checkout. Big lever for SG luxury where AOV > S$200 typical.
• GrabPay / PayLah! / Atome widgets render natively without the React/jQuery double-render Luma has. Mobile experience finally feels like an app.
• Multi-language EN / Mandarin / Malay — Hyvä multi-store ready out of the box. Cross-border SEA-hub friendly.

Typical migration timeline: 4–6 weeks. Conversion lift in the first 90 days post-launch is usually 8–25% from speed alone. See our Hyvä service page for fixed-price tiers.

Most SG stores need 2–3 carriers for cost optimisation + delivery promise:

• SingPost — cheapest for low-weight (< 2kg), local-Singapore mailboxes, postal-code-friendly. Better for non-urgent / standard delivery.
• Ninja Van — SEA leader, strong tracking + same-day urban (CBD / Orchard / Marina Bay). Native Magento module. Cross-border to MY / ID / PH built-in.
• J&T Express — cheapest 2–5kg in SEA, dominant in MY / ID. Good for cross-border SEA hub fulfilment.
• DHL Singapore / FedEx Singapore — international + premium next-day. Native Magento via DHL / FedEx APIs.
• Qxpress — good fallback for ecommerce parcel volume.

We integrate via ShipperHQ (rule engine) or direct carrier modules — rule-based routing by weight, postcode (HDB vs condo vs CBD), value, and delivery promise (same-day / next-day / 2-day). Booking labels auto-generated from Magento order grid; tracking webhooks update sales_order. Cross-border to MY / ID via Lazada / Shopee storefronts as a parallel channel.

Stripe’s global headquarters is in Dublin — founded by Patrick & John Collison, two Irish brothers from Limerick. So Irish merchants get first-class Stripe support, EUR-native processing, and the closest possible billing-entity match. We integrate Stripe in three ways:

• Stripe Payments — the official Magento 2 module covers cards, Apple Pay, Google Pay, SEPA Direct Debit, Bancontact, iDEAL, Klarna, Afterpay/Clearpay, Link, all under one Stripe account.
• Stripe Connect for marketplaces — if your Irish store has multi-vendor flows.
• Stripe Tax — auto-calculates Irish 23% VAT + EU OSS rates for cross-border, and files OSS returns directly.

Strong Customer Authentication (SCA / 3DS2) is built in. We’ve shipped Stripe-led Irish DTC stores in Dublin, Cork, and Galway.

Since 1 January 2021 the UK left the EU customs union, so every IE↔GB shipment now needs customs declarations and origin certificates:

• IE→GB B2C: commercial invoice with HS commodity codes, EORI numbers (both sides), and a UK VAT registration if you exceed £135 threshold per shipment.
• IE→GB B2B: reverse-charge VAT with valid GB VAT number; CN23 or commercial-invoice-only depending on value.
• GB→IE: EU import VAT collected at delivery (or via IOSS for < €150 orders).
• NI special status via the Windsor Framework — NI follows EU rules for goods, GB rules for VAT. We handle this with shipping_table_rate + customs-aware checkout.

We wire An Post + DPD Ireland + DHL Express for IE↔GB lanes with auto-generated commercial invoices and origin declarations.

The Windsor Framework (Feb 2023, replacing the NI Protocol) is the special trading arrangement for Northern Ireland. Practical impact for Magento:

• NI follows EU rules for goods — sell into NI like any other EU country (no customs declarations required from IE).
• NI follows UK rules for VAT — UK VAT applies, not Irish 23%.
• “Green lane” for trusted GB→NI movements (UKIMS scheme) — minimal checks for goods staying in NI.
• “Red lane” for goods at risk of moving onward into Ireland/EU — full EU customs procedures apply.

For Magento we configure separate tax zones (BT postcodes → UK VAT instead of EU VAT), wire a "destination = NI?" hook in checkout, and surface customs duties up-front for ROI→NI orders to avoid surprise charges.

The One-Stop Shop (OSS) scheme lets Irish merchants collect VAT for all 27 EU countries through one Irish-based registration with Revenue.ie — no need to register in 27 places. Magento setup:

• Tax zones: one per EU member state with destination-country VAT rates (DE 19%, FR 20%, NL 21%, etc.).
• Threshold logic: below €10,000 cross-border B2C/year you may charge Irish 23%; above, you must charge destination-country VAT.
• OSS quarterly return: Magento exports a quarterly VAT-by-country CSV for Revenue.ie filing.
• IOSS for < €150 imports from outside EU — collect VAT at checkout, file via IOSS.

We integrate Stripe Tax or Avalara for auto-calculation across all 27 destinations and the OSS / IOSS export.

The Irish Data Protection Commission (DPC) is one of the most active EU enforcement bodies — many global tech giants (Meta, Google, Apple, TikTok, Microsoft) are HQ’d in Ireland because they wanted DPC as their lead supervisory authority. Practical impact for Magento:

• Lawful basis documented per processing operation (orders, marketing, analytics).
• DSAR automation — one-click export of customer data + order history + cookie history within 30 days.
• Cookie consent via Cookiebot / Usercentrics / Klaro — DPC requires opt-in, no pre-ticked checkboxes, granular categories.
• Data Processor Agreements with every third party (Stripe, Mailchimp, hosting).
• Breach notification within 72 hrs — we wire a logging hook so your DPO gets paged on suspicious access.

Strict but predictable — if you do it right once, DPC tends not to revisit.

Both terminate in Dublin — the difference is operational:

• AWS Dublin (eu-west-1) — raw AWS account, you (or we) manage EC2 / RDS / ElastiCache / S3 / CloudFront. Cheapest at scale (€200–800 /mo for SMB), full control. Best for stores with a DevOps person or a managed-services partner.
• Adobe Commerce Cloud (Pro on AWS Dublin) — managed Magento hosting from Adobe, with Fastly CDN baked in, ECE-Tools deploy pipeline, 24/7 Adobe support. €25k+ /yr but no infrastructure-management overhead. Locks you to Adobe Commerce.
• Hyvä Cloud / Cloudways Dublin / Hetzner Helsinki — good middle ground for €500k–€5M stores at €200–800 /mo.

For Irish DTC under €5M revenue we usually recommend AWS Dublin + a managed-services retainer — you keep the cost low and the data inside the EU.

Yes — and Ireland is arguably the best EU base for global Magento:

• English-speaking — no localisation overhead for the team, English-language admin and ERP.
• EU VAT OSS hub — one Irish registration covers all 27 EU countries.
• Stripe HQ — first-class billing entity for global card processing, multi-currency settlement.
• Common-law jurisdiction — familiar for UK / US / AU customers and contracts.
• Low corporate tax (12.5%) — favourable for global IP holding.
• AWS Dublin / Microsoft Azure IE — best EU latency to most markets.

Architecture-wise we build a multi-website Magento: one Irish backend, separate storefronts (e.g. store.ie, store.co.uk, store.de, store.com), shared catalogue + customer base, region-specific tax / payment / shipping rules. We’ve shipped this for two Dublin-HQ’d DTC brands.

Revolut is a hugely popular Irish neo-bank (~2M Irish users out of ~5M population — the highest fintech penetration in Europe). Revolut Pay is the merchant gateway. Integration paths:

• Revolut Pay native module — Revolut publishes an official Magento 2 module (Composer-installable). Supports cards, Apple Pay, Google Pay, Revolut wallet (one-click for Revolut users).
• Stripe via Revolut — Stripe supports Revolut Pay as a payment method, so if you’re already on Stripe you get Revolut as a one-line config.
• Adyen via Revolut — same pattern for Adyen-hosted enterprise stores.

Conversion lift in Ireland: Revolut Pay typically adds 4–7% to checkout completion for under-35 demographics. We wire it as a wallet button alongside Apple Pay / Google Pay on the cart and PDP.

Almost certainly yes if you’re on Luma. Irish mobile shoppers are demanding — they convert dramatically better on fast experiences:

• Lighthouse 95+ on Hyvä vs 40–60 on Luma fashion themes — Google ranks faster pages higher for category/PDP queries.
• Hyvä Checkout loads in < 1s — 50% lower bounce vs Luma checkout, especially mobile-first Irish DTC.
• Stripe / Revolut Pay / Apple Pay widgets render natively without the React/jQuery double-render that Luma has.
• An Post / DPD Ireland shipping pickers render instantly, no spinner-on-spinner.

Typical migration timeline: 4–6 weeks. Conversion lift in the first 90 days post-launch is usually 8–25% from speed alone — then optimisation work compounds it. See our Hyvä service page for fixed-price tiers.

Real, daily, 4–6 hours of working overlap:

• India Standard Time = UTC+5:30
• Ireland = UTC+0 (GMT/IST winter) or UTC+1 (IST summer)
• Overlap window: 12 PM – 6 PM IST = 7:30 AM – 1:30 PM GMT (winter) or 8:30 AM – 2:30 PM IST (summer Irish).

That covers your Dublin morning standup, mid-morning review, and lunchtime hand-off. Daily 11 AM GMT review on staging is the typical cadence. If you need late-day overlap (post-3 PM GMT) we can flex 2–3 days/week. Slack / WhatsApp async covers the rest. We’ve worked this way with Dublin, Cork, Galway, and Limerick clients for years.

Most Irish stores need 2–3 carriers for cost and reach:

• An Post — the state operator, cheapest for low-weight (< 2kg) and best rural-ROI coverage. Track & Trace on premium services. Native Magento module via the An Post API.
• DPD Ireland — best 1-hour delivery slot, premium retail. Strong for Dublin / Cork / Galway / Limerick urban deliveries. Native module.
• Fastway / Evri Ireland — cheapest 2–5kg, weak tracking but excellent price for parcel-shop drop-offs.
• Nightline / GLS Ireland — backup / regional use, decent cross-border IE↔GB.
• DHL Express — for international + premium IE↔GB customs-handled.

We integrate via ShipperHQ (rule engine) or direct carrier modules — rule-based routing by weight, Eircode, value, and post-Brexit IE↔GB customs awareness.

Common scenario for Irish brands that grew on Shopify and now need customs-aware multi-region, OSS VAT, B2B account flows, and lower per-order costs. Migration plan:

1. Data export from Shopify — products, customers, orders, redirects via API.
2. Magento setup — multi-website (IE store + GB store), shared catalogue + customer base, region-specific tax / payment / shipping.
3. 301 redirects from Shopify URL patterns (/products/...) to Magento (/catalog/product/view/...) so SEO equity transfers.
4. Stripe migration — carry over Stripe customer IDs so saved cards keep working.
5. Cutover at off-peak (3 AM GMT) with DNS flip; old Shopify stays as a read-only fallback for 30 days.

Typical timeline: 6–10 weeks. Cost saving: per-order Shopify Plus fees (0.15–0.30%) disappear — offsets the licence cost within ~€1M annual revenue. Dublin reference store: Shopify → Magento at €3.4M revenue, paid back in 8 months.

Cartes Bancaires (CB) is the French national card scheme — it co-badges with Visa or Mastercard on virtually every French-issued debit/credit card. Without CB acceptance, ~70% of French cards bounce at checkout because the bank routes domestic transactions through CB by default for lower fees.

To accept CB in Magento 2, you need a PSP that supports the CB scheme natively:

• Stripe FR — CB enabled by default for FR-region accounts. Easiest route, official Magento module.
• PayPlug — French PSP, CB-first. Free Magento module.
• Adyen — CB supported via the unified card form.
• Worldline / Ingenico (Atos / Sips) — legacy bank-direct route, used by big French retailers.
• Mollie / Lemonway — CB supported.

We configure the PSP, enable CB in the card-network selector, and verify with French test cards (4970 10... BIN ranges issued by BNP / SG / CA).

Mondial Relay is the dominant pickup-point carrier in France — ~13,000 points-relais across FR + BE + LU + ES, often preferred over home delivery by French shoppers (cheaper for them, safer than leaving parcels at the door). Standard French e-commerce expectation: Mondial Relay must be in the carrier list.

Magento integration steps:

1. Install a Mondial Relay Magento 2 module (community modules from Wyomind, Mageplaza, or direct from Mondial Relay’s SDK).
2. Configure your Mondial Relay merchant code + private key in admin.
3. Add the pickup-point selector widget to checkout — renders a map + list of nearest points based on the customer’s postcode.
4. Save the chosen point-relais ID against the sales_order_address as a custom shipping address.
5. Generate Mondial Relay labels from the Magento order grid; tracking webhooks update sales_shipment.

For Hyvä we ship a custom Alpine.js / Tailwind selector since the legacy modules are jQuery / RequireJS-only.

RGPD is just France’s name for GDPR — same regulation. The difference is enforcement: the CNIL (Commission Nationale de l’Informatique et des Libertés) is one of the strictest GDPR enforcement bodies in the EU, with multi-million-euro fines against Google, Amazon, Facebook, TikTok, etc.

Concrete differences from a Magento perspective:

• Cookie consent — CNIL requires granular, per-purpose opt-in. No pre-ticked checkboxes. No “continued browsing = consent”. The “Reject all” button must be as prominent as “Accept all” (CNIL guidance, 2021+ enforced).
• Cookie wall ban — you cannot block content for users who refuse non-essential cookies (CNIL position, narrower than ICO).
• Data localisation — CNIL prefers EU-region hosting (Adobe Commerce Cloud Frankfurt, OVHcloud, Scaleway).
• Loi Informatique et Libertés — the French national law (1978, updated 2018 + 2024) layered on top of RGPD. Adds rules around health data, biometric data, and France-specific DSAR routing.

We ship Cookiebot / Axeptio / Didomi (French-native) wired into Magento’s cookie API, banner copy reviewed against CNIL guidance.

Factur-X is the Franco-German hybrid e-invoice format (PDF/A-3 with embedded XML). Chorus Pro is the French government’s mandatory e-invoicing platform for B2G (business-to-government) transactions — already required since 2017 if you sell to public bodies.

The B2B e-invoicing rollout is phased (deadlines have shifted, current 2024-2026 schedule):

• From 1 Sept 2026 — all French companies must receive electronic invoices.
• From 1 Sept 2026 — large companies (> €50M turnover) must issue e-invoices.
• From 1 Sept 2027 — SMEs and micro-entreprises must issue e-invoices.

Magento integration: order/invoice generation must produce a Factur-X PDF (PDF/A-3 + Factur-X XML) and route through a PDP (Plateforme de Dématérialisation Partenaire) — certified intermediaries that talk to Chorus Pro / PPF (Portail Public de Facturation). We integrate with PDPs like Pennylane, Esker, or Sage e-invoicing — Magento → PDP → PPF → recipient’s ERP.

Two French B2B identifiers, two different validators:

• SIRET (Système d’Identification du Répertoire des Etablissements) — 14-digit number identifying a specific establishment of a French company. Validated against the SIRENE database (free API from INSEE).
• TVA intracommunautaire (TVA intracom) — format FR + 2 check digits + 9-digit SIREN. Validated via the VIES VAT service (EU-wide).

For Magento B2B we:

1. Add SIRET + TVA intracom fields to the customer entity (or B2B company if you’re on Adobe Commerce).
2. Validate SIRET against the SIRENE API on registration — rejects invalid / closed companies, auto-fills company name + address.
3. Validate TVA intracom against VIES — required for cross-border zero-rated B2B sales (intra-EU).
4. Apply 0% TVA on B2B intra-EU sales with a valid VIES-validated TVA number (reverse charge); 20% on B2C and FR→FR B2B.
5. Cache validations 30 days, re-validate on any address change.

France has four standard TVA rates, applied per category:

• 20% — standard rate (most goods + services).
• 10% — reduced (restaurants, transport, some renovations, “non-improving” works).
• 5.5% — reduced (most food, books, water, energy improvements, female hygiene products since 2016).
• 2.1% — super-reduced (reimbursable medicines, press publications).

Magento configuration:

1. Create 4 tax classes in Stores → Tax Zones & Rates (TVA-20, TVA-10, TVA-5.5, TVA-2.1).
2. Create 4 tax rules per rate, scoped to FR (or EU + auto-detect via destination).
3. Assign each product’s tax class based on its category — we usually wire this via the category_id → tax_class mapping in a custom CategoryAttribute observer (so admins don’t need to set it per product).
4. For B2B intra-EU, override to 0% if a valid VIES-validated TVA intracom is on the customer.

Tax-inclusive prices on storefront (mandatory in EU B2C); tax-exclusive on B2B if explicitly opted-in.

Depends on your volume + budget + data-residency posture:

• Adobe Commerce Cloud (Frankfurt region) — best if you’re already on Adobe Commerce. Auto-scaling, Fastly CDN, 24/7 Adobe support, < 30ms latency to Paris / Lyon. Costs €25k+ /yr, locks you to Adobe. Frankfurt isn’t France — some CNIL-conscious clients prefer FR-based hosting for the optics, even though Frankfurt is GDPR-compliant.
• OVHcloud — French cloud giant (Roubaix / Strasbourg / Gravelines DCs). Strong on price, French support, sovereign-cloud option for public-sector. Less auto-scaling than Adobe Commerce Cloud; more DevOps work.
• Scaleway — younger French cloud (Iliad / Free), good for modern stacks, S3-compatible storage, Kubernetes. Great for Hyvä-headless or PWA setups.
• AWS Paris (eu-west-3) — if you want US-grade tooling but FR data residency.
• Hyvä Cloud / Cloudways Paris — managed Magento, €200–800 /mo, good middle ground for €500k–€5M stores.

We benchmark + migrate — the right answer depends on whether you need FR data residency or just FR low-latency.

Almost certainly yes if you’re on Luma. French luxury / fashion shoppers convert dramatically better on fast mobile experiences — and Paris-based luxury brands compete on UX polish:

• Lighthouse 95+ on Hyvä vs typically 40–60 on Luma luxury themes — Google ranks fast pages higher for category/PDP queries (huge for luxury SEO where competition is fierce).
• Hyvä Checkout loads in < 1s — 50% lower bounce vs Magento Luma checkout, especially mobile (which is now > 70% of FR luxury traffic).
• Cartes Bancaires + Alma BNPL widgets render natively without the React/jQuery double-render Luma has.
• Mondial Relay pickup-point selector renders instantly, no spinner-on-spinner on the map widget.
• Image-heavy luxury PDPs use modern <picture> + AVIF / WebP — image weights drop 60–80%.

Typical migration timeline: 4–6 weeks. Conversion lift in the first 90 days post-launch is usually 8–25% from speed alone.

Loi Hamon (2014, Loi n°2014-344 « relative à la consommation ») is the French consumer-protection law that strengthened EU directive rules around distance-selling. Key Magento checkout impacts:

• 14-day cooling-off period — B2C customers can return goods within 14 days, no reason needed. Standard EU rule but Loi Hamon extended it to digital goods + services.
• Pre-contractual information — customers must see, before paying, the total price (incl. TVA + shipping), seller identity (RCS / SIRET), delivery date, return policy. Magento’s checkout review step covers this if configured properly.
• Explicit confirm-button text — the final order button must say « Commande avec obligation de paiement » (or equivalent) — not just « Confirmer ». We override the Magento checkout button label in the FR view.
• Extended insurance / warranty disclosure — if you offer paid extras, Loi Hamon requires unticked-by-default checkboxes (similar to CNIL on cookies).
• Subscription cancellation — for subscription stores, customers can cancel via the same channel they signed up.

We audit + adjust checkout copy / flow for Loi Hamon compliance on every FR build.

Yes — Magento’s multi-store architecture handles FR + BE + LU cleanly because all three share French-language content, EUR currency, and similar (but not identical) tax rules:

• Single Magento backend, 3 stores — one for FR, one for BE (FR-language), one for LU. Shared catalogue, separate URLs (yourbrand.fr / yourbrand.be / yourbrand.lu) or one domain with country selector.
• Per-store TVA — FR 20%, BE 21%, LU 17%. Each with its own reduced rates. Magento tax_zone rules per store.
• Per-store payment methods — FR adds CB + PayPlug + Alma, BE adds Bancontact, LU keeps it lean. Configured per store.
• Per-store shipping — Mondial Relay for FR + BE, bpost for BE-only, POST Luxembourg for LU.
• Per-store legal pages — Mentions légales (FR), Conditions générales (BE), Conditions générales (LU). RGPD applies to all three but enforcement is via CNIL (FR), APD/GBA (BE), CNPD (LU).

For Belgian Dutch-speakers (Flanders), you’d add a 4th store with NL-language. Architecture decided in the audit step.

Real, daily, 4–6 hours of working overlap:

• India Standard Time = UTC+5:30
• France = UTC+1 (CET, winter) or UTC+2 (CEST, summer)
• Overlap window: 12 PM – 6 PM IST = 7:30 AM – 1:30 PM CET (winter) or 8:30 AM – 2:30 PM CEST (summer).

That covers your morning standup, mid-morning review, and lunchtime hand-off. Daily 4 PM CET review on staging is the typical cadence. If you need late-day overlap (post-3 PM CET) we can flex 2–3 days/week. Slack / WhatsApp async covers the rest. We’ve worked this way with Paris, Lyon, Marseille, and Bordeaux clients for years.

Both are common starting points in France — PrestaShop is French-founded (Paris, 2007) and dominant in the FR €100k–€5M segment, while Shopify wins early-stage DTC. Migration triggers are usually B2B requirements, multi-store needs, or Cartes Bancaires limitations.

• PrestaShop → Magento — same data shape (products, customers, orders), straightforward CSV / DB-level migration. PrestaShop modules don’t port; we rebuild the FR-specific ones (CB, Mondial Relay, Colissimo) on Magento. Typical timeline 4–8 weeks.
• Shopify → Magento — export via Shopify Admin API, transform into Magento catalog_product + customer entities. Pay attention to: variants ↔ configurables, Shopify Payments → CB-enabled PSP, app subscriptions cancelled. Typical timeline 6–12 weeks.

For both: 301-redirect every URL to preserve SEO ranking, preserve customer passwords via a one-shot hash-rewrap on first login, and preserve order history by importing as historical orders.

Klarna ships an official Magento 2 module (Klarna_Kp — Klarna Payments) that supports Pay Later, Pay Now, and Slice It in a single integration. Wire-up is a four-step job:

• Account & API keys — production + playground keys from the Klarna Merchant Portal
• Module install — composer require klarna/module-kp + setup:upgrade
• Configure regions — Germany defaults to EUR + DE locale, plus optional AT / CH if you ship DACH
• EPD (Express Payments) — one-tap checkout from PDP for repeat customers

We typically launch Klarna alongside Sofort (also Klarna-owned, same merchant account) plus SEPA Direct Debit so customers see three German-feeling payment methods at checkout. Settlement is daily into your Klarna account; payouts are weekly to your German IBAN.

DSGVO + TTDSG (Telekommunikation-Telemedien-Datenschutz-Gesetz) require opt-in before any non-essential cookie or tracker fires. Generic EU banners with a single “Accept all” button are not compliant in Germany — the regulator (LfDI) has issued fines for these.

Compliant Magento setup:

• Granular consent — separate categories for analytics, marketing, personalisation, with equal-prominence “Accept” and “Reject” buttons
• Trusted vendors — Cookiebot, Borlabs Cookie (German-built, popular with DE merchants), Tarteaucitron, or Usercentrics CMP
• Pre-consent block — GTM, Hotjar, Meta Pixel etc. all gated behind consent state
• Audit log — every consent state stored with timestamp + IP-hash for DSGVO Art. 7 evidence

We integrate the CMP at the storefront level so it works for both Luma and Hyvä themes, and configure DSAR / data-export endpoints in the customer account.

From 1 January 2025 onwards, all B2B invoices in Germany must be issued in a structured electronic format — either XRechnung (pure XML, EN 16931) or ZUGFeRD (hybrid PDF + embedded XML). PDF-only invoices are no longer compliant for B2B.

How we wire it for Magento:

• Invoice generator — use a vendor module (e.g. Mageworx, Magedelight, or a custom InvoiceRepository plugin) that emits ZUGFeRD on every B2B invoice
• USt-IdNr capture — required field on B2B checkout + customer account, validated against VIES
• ERP handoff — SAP / JTL / plentymarkets / Xentral / DATEV all consume ZUGFeRD natively for archive + reverse-charge handling
• GoBD retention — 10-year immutable retention of every emitted invoice (S3 + glacier or on-prem WORM)

For B2C the rules are unchanged — PDF is still fine. We typically dual-emit (XRechnung for B2B, PDF for B2C) so the storefront experience stays smooth.

USt-IdNr (VAT-ID) validation against the EU VIES service is mandatory for two reasons: (1) it lets you apply reverse-charge VAT (zero-rated B2B between EU member states), and (2) it’s a defence against fraud / refund-fraud audits.

Magento setup:

• Native VAT-ID validator — Magento ships a built-in VIES integration in Stores → Configuration → Customers → Customer Configuration → Create New Account Options. Toggle “VAT Number Validation” to Yes
• Customer-group auto-assign — valid USt-IdNr + non-DE country → reverse-charge group; valid + DE → standard 19% group; invalid → B2C group
• Cache the result — VIES is rate-limited; we cache valid responses for 7 days, invalid for 1 hour
• B2B portal gate — for module-based B2B (Adobe Commerce B2B), USt-IdNr is the primary trust signal for company onboarding

We also emit a per-invoice VIES validation receipt so your finance team can audit reverse-charge eligibility in retrospect.

GoBD = Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff. In plain English: the German rules for how digital business records (orders, invoices, customer master data) must be stored and retrieved for tax audits.

What it means for Magento:

• Immutability — once an invoice is issued, the source record cannot be silently edited. Magento’s order & invoice tables are append-only by design, but custom modules and refund flows must preserve audit trails
• 10-year retention — every order, invoice, credit memo, and shipment doc must be stored for 10 years in a tamper-evident way
• Audit access — on tax-authority request, you must be able to export Z3 (full data) format within a reasonable time
• Procedure documentation — Verfahrensdokumentation describing how data flows through Magento, your ERP, and your archive

We typically pair Magento with a GoBD-certified archive (e.g. d.velop, EASY Archiv, or a DATEV-DMS bridge) and emit invoices to the archive at order-paid event. The Magento DB stays the system of record; the archive is the audit-ready vault.

Depends entirely on revenue + headcount. Quick guide:

• Hetzner Cloud / dedicated — the price-performance king for DE merchants up to ~€5M revenue. Frankfurt + Falkenstein + Nürnberg datacenters, German-jurisdiction, €30–€200/month for Magento-sized boxes. Best for: bootstrapped DTC, B2C fashion, mid-market
• IONOS (formerly 1&1) — trusted German brand, decent prices, customer support in German. Best for: established mid-market DE shops, traditional businesses
• AWS Frankfurt (eu-central-1) — enterprise-grade, but you’ll need a DevOps engineer to run it. Best for: €5M+ revenue, multi-region, complex auto-scaling
• Adobe Commerce Cloud (Frankfurt) — Adobe-managed PaaS on AWS Frankfurt, expensive but zero-DevOps. Best for: Adobe Commerce licence holders, €10M+ revenue, headless / PWA
• Hyvä Cloud — opinionated for Hyvä-only stores, Frankfurt POPs. Best for: pure Hyvä storefronts

We have hands-on production experience with all five and can move you between them with zero downtime if your traffic outgrows the current tier.

DHL is the dominant DE carrier (~50% market share). Magento integration covers four flows:

• Live rate quoting — DHL Paket DE module exposes per-PLZ + per-Bundesland rates at checkout (no flat rates — DE customers expect carrier-accurate quotes)
• Label printing — one-click DHL label generation from the order grid via Versenden API, with auto-tracking-number-back-to-Magento
• Tracking emails — transactional email auto-injects DHL tracking link + ETA, native German copy
• DHL Wunschzustellung — Preferred-day / Preferred-neighbour / Preferred-location at checkout (huge UX win for DE customers, optional but highly recommended)

For DACH-region stores we typically pair DHL with DPD Germany (B2B fallback), GLS (parcel), and Hermes (now Evri-rebranding for DE) on lighter / lower-value items. ShipperHQ or Magento native multi-carrier matrix handles the routing logic.

For most DE stores: yes, but time it with another change. The DE market is particularly speed-sensitive (German shoppers abandon faster than UK/US averages on slow loads), and Hyvä ships Lighthouse 95+ out of the box with 5–10× faster page loads vs Luma.

DE-specific reasons to migrate:

• Klarna + Sofort + SEPA all have Hyvä-compat checkout integrations from day one
• DSGVO consent-banner load drops from ~600ms to ~80ms on Hyvä (the Tailwind+Alpine bundle is 10× smaller than Luma’s)
• Hyvä Checkout is one-page, < 1s render — DE customers love speed, and bounce rates drop ~50% on the checkout step alone
• SEO uplift — Core Web Vitals are a German-Google ranking factor; Hyvä takes you from ~“needs improvement” to ~“good” on LCP / CLS / INP

Reasons to wait: Magento extension deps that have no Hyvä compat module (we audit this in step 1), or a redesign you’re already planning — combine the two and save 30%.

DACH multi-language has three layers most teams underestimate:

• Storefronts & pricing — three separate Magento store-views (de_DE, de_AT, de_CH) with distinct catalogue prices (CH is typically +15–20% due to import + VAT), distinct currencies (EUR for DE/AT, CHF for CH), and distinct payment rails (Klarna for DE/AT, TWINT for CH)
• Tax — 19% MwSt for DE, 20% USt for AT, 8.1% MWST for CH. Cross-border B2B reverse-charge between DE↔AT (intra-EU); CH is non-EU so customs / DDP rules apply for cross-border to CH
• Compliance — DSGVO covers DE + AT (EU), but CH operates under revFADP (the Swiss equivalent, came into force Sept 2023). Cookie banners must respect both, but the CH text differs slightly

We recommend a shared catalogue, three store-views setup over three separate Magento installs — product / inventory / customer data stays in one DB, but pricing / tax / language / payments are per-store-view. Cuts your maintenance overhead in half.

Real overlap is 4–6 hours per day. Specifically:

• 12:00 PM IST = 7:30 AM CET (your morning coffee, our after-lunch sync)
• 3:00 PM IST = 10:30 AM CET (your mid-morning — our preferred standup slot)
• 6:00 PM IST = 1:30 PM CET (your post-lunch — our last possible live block)

That gives you at least 4 hours of guaranteed live overlap every weekday, no asymmetry, no “wait until tomorrow”. We schedule daily standups at 4 PM CET (7:30 PM IST) so they land squarely in your working day, and we use Loom + written briefs for the async hours.

For urgent production incidents we’re on-call 24/7 during the post-launch window (extra cost beyond Standard tier). German bank holidays are observed in addition to Indian ones, so no surprise “Tag der Deutschen Einheit” outages.

Both migrations are common in DE because of feature ceilings:

• Shopware → Magento typically driven by needing more flexible B2B (Adobe Commerce B2B), advanced multi-store, or customisation depth that Shopware 6 caps. Catalogue + customer + order export via API or DB-direct, then a Magento panth_import patch maps to Magento’s schema
• Shopify → Magento typically driven by Shopify Plus pricing pain, lack of true multi-store, or DSGVO/GoBD requirements Shopify can’t fully meet. Use Shopify’s GraphQL Admin API + orders.json + customers.json bulk export

Migration steps we run:

• Catalogue + media + URL-rewrite map (preserves SEO equity — we’ve never lost rankings on a migration)
• Customer + order history (with hashed-password import where supported)
• Payment-rail re-integration (Klarna, Sofort, SEPA — old gateway tokens migrate to new merchant account)
• 301-redirect map for every old URL
• Pre-launch crawl (Screaming Frog) + post-launch crawl 7 days later, diffed for any 404s

Typical timeline: 6–10 weeks depending on catalogue size and customisation.

Both are top-tier in DE, but they target different segments:

• Adyen — Dutch-founded, Amsterdam HQ, premium / enterprise pricing (interchange++ typical), unmatched local-method coverage (Klarna, Sofort, giropay, SEPA, iDEAL, Bancontact natively), strong B2B / marketplace feature set (Adyen MarketPay), excellent risk engine (RevenueProtect). Best for €5M+ revenue, multi-region DACH or DACH+Benelux, marketplaces.
• Stripe — US-founded, premium pricing (slightly higher than Adyen at scale, lower at small scale), best-in-class developer experience and dashboard, Klarna + Sofort + SEPA all supported, weaker on giropay (currently sun-setting anyway). Best for DTC, fast-moving teams, €500k–€10M revenue, single-region.

For most DE stores under €5M revenue we recommend Stripe + Klarna (Klarna covers the BNPL + Sofort + SEPA gap natively). Above €5M, Adyen pulls ahead on cost and local-rail breadth. We’ve integrated both extensively and can wire either — or a multi-rail setup with a fallback if one goes down.

Bill 96 (Loi sur la langue officielle et commune du Québec) strengthens the existing Charter of the French Language. From June 2025 onward, businesses operating in Quebec must offer products, services, and customer-facing content in French — with French at least as prominent as any other language.

For a Magento store this means:

• A dedicated FR-CA store view (not just an embedded language switcher) so URLs, page titles, meta tags, and structured data render in French
• French translations for product titles, descriptions, attribute labels, category names, CMS pages, transactional emails, and checkout copy — we wire Crowdin or Phrase for the translation pipeline
• Locale-aware hreflang (en-CA / fr-CA) so Google serves the right page to QC users
• French-first checkout if the ship-to address is in QC, with a one-click language toggle
• Privacy policy & cookie banner in both languages, with the French version equally prominent

We deliver Bill 96 readiness as a standard part of the Standard tier.

Canada has three layers of sales tax that vary by ship-to province:

• GST (5%) — Federal Goods & Services Tax. Applies everywhere.
• HST (13–15%) — Harmonized Sales Tax. Replaces GST + PST in Ontario (13%), Nova Scotia, New Brunswick, Newfoundland & Labrador, PEI (all 15%).
• PST — Provincial Sales Tax. Stacked on top of GST in BC (7%), Saskatchewan (6%), Manitoba (7%).
• QST (9.975%) — Quebec Sales Tax. Stacked on top of GST in Quebec for an effective 14.975%.
• Alberta & Territories — GST 5% only, no provincial layer.

In Magento we configure tax classes per product type, tax rules per ship-to province, and the point-of-supply rules (which determine which province’s rate applies). For multi-province stores we wire Vertex, Avalara, or TaxJar Canada so rates auto-update if the government changes them.

Interac e-Transfer is a uniquely Canadian rail — it’s effectively a bank-to-bank push payment with no card-network fees, and it’s especially popular for B2B and high-value transactions where credit-card surcharges hurt margins.

Magento doesn’t have a native Interac module, so the integration options are:

• Moneris bundles Interac Online (browser-redirect to bank login) into its checkout flow — easiest for B2C
• Bambora / Worldline supports Interac as a payment method in its Magento extension
• Manual Interac e-Transfer with a custom Magento payment method that emits an order in pending payment status, instructions on the success page, and a webhook from your bank to mark paid — we’ve built this several times for B2B accounts
• Helcim supports Interac via a hybrid card / e-Transfer flow

We recommend Moneris for B2C, custom + bank-webhook for B2B.