Enterprise Ecommerce Platform Selection: Requirements Before Demos

Choosing an enterprise ecommerce platform goes wrong most often before the first demo, when nobody has written down what the business actually needs. Large retailers and distributors should finish four sets of requirements first: integrations, multi entity structure, data residency and order management. With those settled, vendor demos become tests of your requirements rather than showcases of theirs.

This guide sets out a requirements method for UAE and GCC businesses with several brands, legal entities or channels. It is written for the people who will sign off the decision: heads of ecommerce, IT, finance and operations. If you are still at the stage of comparing platform families, start with ecommerce platforms compared for UAE merchants and come back here once the shortlist is enterprise grade.

Why requirements must come before enterprise ecommerce platform demos

Vendor demos are designed to impress. They show a polished storefront, a fast admin and a few well rehearsed scenarios. They rarely show what happens when an order splits across two warehouses in different emirates, when a B2B customer needs its own price list, or when the ERP rejects a product because a tax code is missing.

Without written requirements, three things tend to happen:

• Each stakeholder judges the demo on the part they care about, and nobody tests the hard parts.
• The selection is driven by storefront look and feel, which is the easiest thing to change later.
• Integration and data questions surface during the build, when changing platform is no longer realistic.

A requirements document turns the demo around. You send vendors your scenarios in advance and ask them to show those scenarios working, on your data where possible.

Step 1: Map integrations before anything else

In enterprise ecommerce UAE projects, the storefront is often the simplest part. The difficulty sits in the connections between the platform and everything around it.

List every system the platform must talk to

Build an integration inventory with one row per system. Typical entries include:

• ERP for products, pricing, stock, orders, invoices and financial posting
• CRM for customer records, segments and service history
• Warehouse management and third party logistics providers
• Point of sale in physical stores
• Payment gateways, wallets and fraud tools
• Couriers and last mile delivery partners
• Marketplaces and social commerce channels
• Product information management and digital asset management
• Marketing automation, analytics and customer data platforms

Define direction, frequency and owner

For each connection, record which way data flows, how often it must move (real time, every few minutes, nightly) and which system is the master for each field. ERP integration usually fails not because of technology but because two systems both believe they own the price or the stock figure. The companion guide on connecting WooCommerce to ERP, CRM and shipping without duplicates walks through ownership rules in detail, and the same principles apply on any platform.

Check how each platform exposes its data

Ask vendors for API documentation, rate limits, webhook support and bulk import methods. On the ERP side, check what your system offers too. Microsoft Dynamics 365 Business Central, for example, publishes a documented API for resources such as sales orders, while Odoo provides an external API and has introduced a newer JSON based API to replace its older RPC endpoints. Version changes like these affect how long an integration will last before it needs rework.

Step 2: Describe your multi entity and multi store structure

Large UAE businesses rarely sell through one company and one website. A group might run companies licensed in different UAE jurisdictions, several brands, a B2B arm and stores in other GCC countries. The platform must reflect that structure without forcing workarounds.

Questions to answer internally first

• How many brands, storefronts and countries do you need now, and in three years?
• Which entities invoice which customers, and in which currencies?
• Do brands share a catalogue, a customer base or a warehouse, or are they separate?
• Which languages does each storefront need, and is Arabic required everywhere?
• Does each entity have its own tax registration and invoice format?

What to ask vendors

Ask how the platform models stores, websites, catalogues and price lists, and whether one admin can manage them all with role based permissions. A multi store setup that shares one product database but allows store level pricing and content is very different from running separate installations that must be kept in sync.

B2B commerce needs its own list

Distributors and wholesalers should write separate B2B commerce requirements: company accounts with several buyers, approval rules, customer specific catalogues and pricing, quotes, credit limits and payment on account, and quick reorder by SKU. Some platforms include these natively; Adobe Commerce's B2B features, for instance, cover company accounts, shared catalogues, negotiable quotes, purchase order approvals and requisition lists. Others rely on extensions or custom work. The comparison in WooCommerce or Adobe Commerce for a growing catalogue looks at this trade in more depth.

Step 3: Settle data residency and compliance questions

Where customer and order data is stored, and who can access it, is a board level question for many enterprises. It is far easier to answer before choosing a platform than after.

What to clarify

• Applicable law: the UAE Personal Data Protection Law, Federal Decree Law No. 45 of 2021, covers personal data processing and transfers outside the UAE. Entities in DIFC and ADGM fall under their own data protection regimes.
• Sector rules: health, financial and government related businesses may face additional requirements from their regulators.
• Hosting regions: ask each vendor which regions host your data, backups and logs, and whether you can choose.
• Sub processors: request the list of third parties that handle data on the vendor's behalf.
• Access and audit: confirm how staff access is logged and how you would respond to a data subject request.

Data residency requirements depend on your sector and structure, so confirm them with legal counsel or your regulator and record the answer in the requirements document. A vendor that cannot answer these questions in writing is a risk, however strong its demo.

Tax and invoicing

UAE VAT is administered by the Federal Tax Authority. Make sure the platform, or the ERP behind it, can produce compliant tax invoices for each entity, and ask how the vendor tracks regulatory changes to invoicing in the markets you sell to.

Step 4: Decide where order management lives

Order management is where enterprise complexity concentrates. An order is placed once but may be split, partly shipped, partly cancelled, returned to a store and refunded to a different payment method.

Order management capabilities to specify

Platform, ERP or separate order management system

Some businesses let the ecommerce platform manage orders and pass them to the ERP for fulfilment and finance. Others run order management in the ERP. Larger omnichannel retailers sometimes add a dedicated order management system between them. There is no single right answer, but there must be one clear owner for each order state, or customers will receive conflicting updates.

Non functional requirements that are easy to forget

Functional scenarios get most of the attention, but enterprise platforms often struggle on the requirements nobody demonstrates.

Peak trading and performance

Write down your busiest expected hour in orders and sessions, and ask each vendor how the platform scales for it. For hosted platforms, ask about limits on API calls and checkout throughput. For self hosted options, ask who is responsible for scaling servers and caching, and how that is tested before a campaign.

Search and catalogue scale

Large catalogues with many attributes need fast, accurate search and filtering in Arabic and English. Ask whether search is built in or supplied by a separate service, and how product updates from the ERP reach the search index.

Support, releases and roadmap

Ask how often the platform releases updates, how breaking changes are announced and what support hours cover the Gulf working week. A platform whose upgrades regularly break integrations will cost more in maintenance than its licence suggests.

Step 5: Choose an architecture: suite or composable commerce

With requirements written, the architecture question becomes clearer. A suite is one platform that handles catalogue, cart, checkout, promotions and often content. Composable commerce assembles separate services, such as a commerce engine, a content system, search and an order management system, connected through APIs and usually fronted by a headless storefront.

Composable is not automatically more modern or better. It moves complexity from the vendor to you. Choose it when your requirements genuinely exceed what a suite can do, and when you have, or can hire, the team to run it.

Step 6: Turn requirements into scripted demos

Once the four requirement sets are complete, convert the most important ones into demo scripts. Each script is a short scenario with expected results.

1. Select six to ten scenarios. Pick the ones that represent the hardest and most valuable parts of your operation.
2. Send scenarios and sample data in advance. Give every vendor the same pack and the same deadline.
3. Score live, against the script. Use a simple scale for each scenario: shown working, shown with workaround, not shown.
4. Ask for a technical session separately. Let your IT and integration leads question the vendor's architects without the sales team present.
5. Check references on your hardest requirement. Ask to speak to a customer with a similar integration or entity structure.

Hypothetical example: a UAE electronics distributor with retail stores, a B2B trade portal and an entity in Saudi Arabia prepares eight demo scenarios. One asks the vendor to place a trade order at a customer specific price, split it between Dubai and Riyadh warehouses, and post two invoices to two entities in the ERP. Two of four shortlisted vendors cannot show this without custom development, which narrows the decision before commercial negotiations begin.

A requirements checklist to complete before demos

• Integration inventory with direction, frequency and data owner for every field
• Entity, brand, store, currency and language map, current and planned
• B2B requirements, if any, written separately from retail
• Data residency, privacy and sector compliance answers confirmed with counsel
• Tax invoicing needs per entity
• Order management ownership and the six capabilities above
• Performance and availability expectations for peak trading such as Ramadan, White Friday and the Dubai Shopping Festival
• Internal team skills and the support model after launch
• Exit plan: how products, customers and orders would be exported if you leave

For businesses still deciding whether they need enterprise tooling at all, planning your first online store in the UAE covers the simpler path.

Bring your requirements to a team that builds integrations

Codeeo works across both sides of an enterprise ecommerce programme: the storefront, through ecommerce and headless commerce builds, and the business systems behind it, including Microsoft Dynamics 365 and CRM, Odoo and ERP and custom software. With 200+ projects delivered across the UAE and the US and a team of 80+ across Dubai, Riyadh and Karachi, Codeeo can help you write requirements, map integrations and prepare demo scripts before you speak to platform vendors.

The Dubai office means UAE teams can work through the requirements in person. Contact Codeeo to discuss your platform selection.