Plexi develops Magento and Adobe Commerce stores for large Dubai retailers, multi-brand groups, and B2B suppliers operating in the UAE — where catalogue complexity, pricing logic, or multi-store requirements exceed what Shopify or WooCommerce handle cost-effectively.
Our wider e-commerce development practice weighs Shopify, WooCommerce, and Magento against each other and picks the platform your catalogue actually needs. This page assumes that decision has landed on Magento, and goes deep on what that build involves in the UAE: the edition choice, the frontend stack, the infrastructure that keeps it fast under load, migration off a legacy store, and the patch discipline the platform demands after launch.
What Magento solves that other platforms struggle with
Magento (now Adobe Commerce in its enterprise tier) was built for scale and complexity. The platform’s architecture handles what high-volume UAE merchants genuinely need:
Large catalogues with complex attributes. A UAE electronics distributor or industrial supplier with 30,000 SKUs and multi-dimensional attributes (voltage, origin, certification standard) needs a proper catalogue engine — not a workaround in a hosted SaaS.
Multi-store from one admin. A retail group operating separate brands or country-specific stores (UAE, KSA, Kuwait) can manage all storefronts from a single Magento instance with shared inventory, separate catalogues, and independent checkout configurations.
B2B commerce features. Shared company accounts, negotiated pricing, requisition lists, purchase order payment, and credit limits are first-class features in Adobe Commerce B2B — built for the supplier and distribution models common in JAFZA and DIC.
Custom promotional logic. Magento’s promotion engine handles rules that Shopify’s discount system cannot: buy X of category A, get Y from category B at Z% off, only on orders above AED 500, only for account tier Gold.
Adobe Commerce or Magento Open Source: choosing the edition
Magento ships in three forms that share a common core but diverge sharply on licence, hosting, and enterprise features. Choosing wrong is expensive in both directions — paying an enterprise licence for modules you never switch on, or hitting a wall on Open Source that forces a mid-project edition change. We settle this before any code is written.
| Capability | Magento Open Source | Adobe Commerce | Adobe Commerce on Cloud |
|---|---|---|---|
| Licence model | Free to license; you fund build and hosting | Annual licence scaled to GMV | Annual licence, managed hosting included |
| Hosting | You provision (AWS, GCP, Azure) | You provision | Adobe-managed on AWS / Azure |
| B2B module (company accounts, quotes, requisition lists) | Custom build or extension | Built-in | Built-in |
| Customer segmentation and targeting | Extension | Built-in | Built-in |
| Content staging, preview, and Page Builder | Basic Page Builder only | Full staging and preview | Full staging and preview |
| Advanced reporting / BI | External tools | Built-in | Built-in |
| Fastly CDN and WAF | Self-configured | Self-configured | Included and managed |
| Best fit | Regional retail, mid-to-large catalogues, cost-sensitive | Complex B2B, segmentation, enterprise reporting | Enterprise wanting managed infra and an SLA |
For most UAE retailers, Magento Open Source on well-architected cloud hosting covers the requirement completely. Adobe Commerce earns its licence when native B2B, customer segmentation, content staging, or Adobe Analytics integration are genuinely on the roadmap — not bought as insurance. If your catalogue is small and your logic simple, we will say so and point you at Shopify or WooCommerce, where total cost of ownership is usually lower.
Frontend architecture: Luma, Hyvä, or headless
Magento’s single biggest performance lever is the frontend layer, and it is the decision regional builds most often get wrong by defaulting to the legacy Luma theme. The choice sets your Core Web Vitals ceiling, your build cost, and your long-term maintenance load.
| Luma (default) | Hyvä | Headless / PWA Studio | |
|---|---|---|---|
| Stack | Knockout.js, RequireJS, LESS | Tailwind CSS, Alpine.js | React or Vue front end over GraphQL |
| Mobile Lighthouse ceiling | Mid-range, hard to lift | 90+ achievable | 90+ achievable |
| Build effort and cost | Lowest | Moderate | Highest |
| Ongoing maintenance | Heaviest JS bundle | Lean, few dependencies | Two codebases to keep in sync |
| Best for | Legacy parity, tightest budgets | New UAE builds wanting speed without headless cost | Brands where storefront UX is the differentiator |
We do not reskin Luma with a theme-market template. For most new UAE projects we build on Hyvä — its lean Tailwind and Alpine.js stack reliably clears a 90 mobile Lighthouse score where Luma’s Knockout and RequireJS bundle cannot, at a fraction of a full headless budget. The one thing to check early is extension compatibility: modules with heavy Luma frontends need a Hyvä-compatible version or a compatibility module, so we vet the extension list against Hyvä before committing. Whichever route we take, the theme is designed in Figma first across the full page set — homepage, category, product detail, cart, and checkout — on mobile and desktop.
Performance engineering for high-volume UAE catalogues
Magento’s reputation is made or ruined on infrastructure, not features. The application is fast when its supporting services are configured correctly and slow when they are not — so we design the stack before build rather than tuning it after a sale falls over.
- Full-page cache via Varnish in front of Magento, so most page loads never touch PHP.
- Redis for session storage and the default cache, separated so a session spike does not evict catalogue cache.
- OpenSearch or Elasticsearch for catalogue and search queries — mandatory from Magento 2.4 and the difference between instant and lagging faceted navigation on a deep catalogue.
- On-schedule indexing with cron, never on-save, so bulk price or stock updates do not lock the storefront.
- Message queue (RabbitMQ) on Adobe Commerce to push order emails, exports, and reindexing off the request path.
- Tuned MySQL / MariaDB, with the split-database option available on Adobe Commerce for very high order volumes.
- CDN with a GCC edge and image optimisation, lazy loading, and critical CSS to protect mobile load times.
Cloud regions now sit close to the market — AWS and Microsoft each operate UAE regions — which cuts latency and helps with data-residency expectations for local enterprises. Before any peak trading window (White Friday, DSF, Ramadan), we load-test against your projected concurrent-user target and fix the bottleneck we find, rather than discovering it live at checkout.
UAE payments, tax, and multi-store configuration
Payment gateways
Magento’s payment gateway API supports the full UAE stack, wired the way local shoppers expect to pay. Our payment gateway integration team handles the build and PCI-aware checkout hardening:
- PayTabs and Telr: native Magento extensions with 3DS2 support
- Network International: extension-based integration widely used by larger UAE retailers
- Tabby and Tamara: both publish official Magento modules; their catalogue and cart widgets surface instalment pricing through the storefront theme rather than only at the payment step
- COD with deposit: configurable via Magento’s native cash-on-delivery method plus custom deposit logic for higher-value orders
Multi-store, Arabic RTL, and VAT
Magento’s multi-store architecture runs Arabic and English as separate storefront views over one catalogue — each carrying its own store-view locale, RTL theme configuration, and independent metadata and URLs, so the Arabic view is first-class rather than a bolt-on. The Arabic keyword and hreflang strategy that makes those views rank is e-commerce SEO work. UAE VAT (5%) is set at the tax-class level with correct display logic for B2C and B2B scenarios, and zero-rated exports handled as their own class so invoices stay compliant from the first order.
ERP, PIM, and logistics integrations
- ERP and OMS: SAP, Oracle NetSuite, and Microsoft Dynamics via REST or SOAP API
- Logistics: Aramex, Fetchr, and Noon fulfilment warehouse integrations with tracking write-back
- PIM: Akeneo integration to keep product data clean at high SKU volume
- Analytics: Adobe Analytics or GA4 enhanced e-commerce with a custom event layer
Migrating to Magento 2 or Adobe Commerce
Two migration paths land on Magento. The first is a legacy Magento 1 store: Magento 1 reached end of life in June 2020 and receives no further security patches, which makes it a PCI liability every day it stays live. Moving to Magento 2 is a rebuild, not an in-place upgrade — the architecture, themes, and extensions all changed — but the official Data Migration Tool carries settings, catalogue, and order data across, with delta runs to capture orders placed during the build.
The second path is re-platforming from Shopify, WooCommerce, or a bespoke system. Here we migrate three data sets — catalogue, customer records, and order history — through the REST API or a scripted import, and re-evaluate every extension against a Magento equivalent because add-ons do not carry over between platforms.
On both paths the redirect strategy is what protects organic traffic, and it is owned end to end by our e-commerce SEO team — Magento’s own URL rewrites and the legacy store’s paths get reconciled into a single 301 map, staged and tested before cutover. Cutover then runs against a reconciled staging environment — order counts, customer totals, and revenue figures checked against the source — before DNS is switched.
SEO for large Magento catalogues
Deep catalogues create SEO problems smaller stores never see: faceted navigation generating thousands of thin, near-duplicate URLs, duplicate content across colour and size variants, and crawl budget burned on filtered parameter combinations. We implement a canonical strategy, robots and meta-robots rules for facets, parameter handling, and segmented XML sitemaps before launch — not after Google has indexed the wrong pages and diluted the ones that matter. This is set at the architecture phase on every Magento project, not retrofitted once rankings disappoint.
Ongoing support, security patches, and upgrades
A Magento store is a self-hosted application, which means someone owns its security — and on Open Source, that someone is you or your agency. Adobe releases security patches on a regular cadence; unpatched Magento installs are a standing target for Magecart-style card-skimming attacks that inject themselves into checkout. Falling behind on patches is the single most common route to a compromised store.
We keep stores current on a defined cycle: security patches applied and regression-tested, minor version upgrades, and PHP and Composer dependency currency. Every change is tested on staging first, because extension conflicts — not the core upgrade itself — are the usual cause of an upgrade breaking a storefront. Alongside patching, we run scheduled backups, uptime and error monitoring, and checkout hardening against the bot and card-testing traffic UAE stores routinely attract.
Magento projects need a detailed scoping phase before any meaningful timeline or cost — the edition, the frontend stack, the integration list, and the peak-traffic target each move the number. Send us that brief — catalogue size, the ERP, OMS, and logistics systems to connect, your edition leaning, and projected peak load — through the contact form and we will come back with a structured scoping proposal. The pricing guide gives ranges for smaller builds; an enterprise Magento engagement is quoted only against that scope.