Ecommerce platform RFP questions

Magento Open Source fits stores with large catalogs, complex pricing and a team that can run PHP applications over years, not months. Ask the partner to tie the recommendation to your catalog size, the number of store views and channels, the integrations you need, and the in-house or retained skills to operate it. Expect the answer to name the cost of that skill set: Magento needs PHP, Composer, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx, and Adobe supports only listed combinations. Ask which of those components your team already runs and which would be new. A credible answer also covers the trade-off: Magento gives broad built-in commerce features, but customizations and extensions carry upgrade work that grows with the store.

WooCommerce usually suits smaller catalogs, content-led stores and teams already running WordPress, while Saleor suits API-first builds with a custom storefront. Ask the partner to describe the two or three situations where its recommendation would change. For WooCommerce, the answer should cover plugin dependence and how each plugin is maintained. For Saleor, it should cover the cost of building and running a separate storefront, its GraphQL API, and infrastructure made of the API, Dashboard, PostgreSQL, Valkey or Redis, and Celery workers. Good answers name what each platform does poorly for your case, not only what it does well.

A credible partner names specific conditions that rule its own recommendation out. Ask for those conditions in writing before you shortlist. Typical examples include a need for role-based admin controls in an open-core product, a storefront team that wants to stay on one framework, a requirement for in-process plugins where the platform extends through webhooks and apps instead, or a catalog and order volume that needs more caching and search capacity than your team can operate. Ask the partner to rank these risks by likelihood for your business and to say which would trigger a platform change. This question reveals whether the recommendation was tested against alternatives or written to fit a preferred stack.

Licenses differ in what you may modify, redistribute and host, so ask for a written license review before selection. Magento Open Source is licensed under OSL-3.0, with AFL 3.0 also included in its distribution. WooCommerce is licensed under GPL version 2 or later. Saleor is licensed under BSD-3-Clause. Medusa's core is MIT licensed, but Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. Ask the partner to confirm which features your requirements depend on, whether any of them sit in a commercial edition, and whether any extensions you plan to use carry different terms. License questions also affect who pays for what, so ask how the partner handles them in scope.

Ask for the support dates of the exact release line proposed, and for the plan to move to the next line before support ends. For Magento Open Source, Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. Magento 2.4.9 has end of regular support on May 31, 2029, and 2.4.8 on May 31, 2028, while 2.4.6 ended on August 11, 2026. For Medusa, the GitHub releases page lists v2.21.2 as released on September 28, 2026, so ask how the partner will track minor and major upgrades. Also ask who applies security patches between releases, how long they are committed, and what happens if a platform component reaches end of life during the engagement.

A useful comparison starts from your requirements, not from the partner's preferred stack. Ask for a written scoring model covering catalog size, channels and currencies, B2B needs, checkout and payment providers, PCI DSS scope, ERP and PIM integration, search, performance, accessibility and upgrade cadence. Ask the partner to name the alternatives it considered, the ones it rejected and why, and whether it would run a short proof of concept on the top two options. Also ask who on the partner side has operated each platform in production, because the comparison should reflect operating experience as well as feature lists. Finally, ask what your own team would need to learn and how much of that the partner will cover in the handover.

Each platform needs a different operating skill set, and the partner should state it per option. Magento requires PHP and Composer administration, database and search tuning, and experience with full-page caching and queue workers. WooCommerce requires WordPress administration and disciplined plugin management. Saleor needs Python, Django and GraphQL skills plus Docker or Kubernetes operations and PostgreSQL. Medusa needs Node.js and TypeScript, PostgreSQL and Redis, and a deployment that runs separate server and worker instances. Ask the partner which of these skills you have, which you must hire or contract, and whether ongoing support, upgrades and testing are offered as a retainer. Most engagements are fixed-scope, so ask what remains after handover and who owns it.

Start with a short approval list, not an open marketplace. For each extension, check the license, the vendor's release history, the platform version it supports, whether it touches checkout or payment pages, and how many other extensions it depends on. Ask the vendor which upgrade path they follow and how they publish breaking changes. Reject extensions that inject scripts into checkout without a clear purpose, and record each approved extension with an owner and a reason. The review should be repeated at every platform upgrade, because a module that was fine on one release line can be abandoned or incompatible on the next.

Custom code should live in the platform's supported extension points, such as modules, plugins, webhooks, apps or API extensions, and never in edited core files. Each platform has its own boundary: Magento Open Source uses modules and plugins, Saleor extends through webhooks, apps and metadata rather than in-process plugins, and Medusa uses its module and workflow system. Keep a written boundary document that lists every override, its reason and the test that proves it still works. Core edits are the most common cause of failed upgrades, so treat any proposed core change as an exception that needs sign-off.

Run every upgrade on a staging copy built from a recent production backup, with the same database engine, search, cache, queue and payment sandbox settings as production. Use a repeatable script to apply the platform update, run the extension compatibility checks, then run automated tests for checkout, account login, search, pricing and promotions. Compare results with the last known good build and record the defects. Ask a partner to show the upgrade runbook, the staging refresh process and the test evidence kept for each release. For Magento Open Source, confirm the target version's system requirements before scheduling, because Adobe supports only the listed combinations.

A catalog migration moves products, categories, attributes, images, prices, stock and channel or store assignments into the new platform through a mapped, scripted import. Run at least one full rehearsal on a copy, then compare record counts per entity type, check price and stock totals against the source, and sample product pages for attribute accuracy. Keep the mapping file under version control so each rehearsal is identical. Ask the partner how they handle product variants, media files and multi-currency prices, since these are the usual sources of silent loss.

Customers, orders and URLs each need their own migration plan. Move customer accounts with a clear rule for passwords, since most platforms cannot export hashed passwords in a compatible form, so ask how reset flows will work. Migrate historical orders read-only with reconciliation totals by day, status and currency. Build a URL map from every indexed page to its new address, and test redirects in staging with a crawl. For rollback, keep the old store in read-only mode, freeze content during cutover, and define the exact step that returns traffic to the old platform. Ask for the written rollback criteria and the time window in which it can be used.

A reconciliation report shows that the number of records and the financial totals in the new platform match the source, within agreed tolerances. It should list counts of products, customers, open and closed orders, and redirects, plus sums of order value, tax and stock by location. Any difference must be explained and either fixed or accepted in writing before go-live. Run the same report after the final delta sync, not only after the first rehearsal. Ask the partner to show a sample report from a previous rehearsal so you know what the output looks like.

A cutover plan names the freeze window, the order of steps, the owner of each step, the go and no-go checks, the rollback trigger and the communications to staff and customers. It should cover DNS or load balancer changes, final data sync, payment provider configuration, cache warming and monitoring after launch. Sign-off normally sits with the business owner for commerce, the security lead for payment and personal data handling, and the engineering lead for technical readiness. Ask the partner to rehearse the plan end to end at least once before the live date.

A team with ecommerce engineering experience can run upgrades and migrations, provided it has staging environments, documented runbooks, test coverage and time for rehearsals. A partner adds the most value when the team lacks that depth or cannot free people for repeated rehearsals. Cost depends on the number of extensions, custom modules, data volume, the number of channels and the test coverage you already have. Most engagements with DeployOpen are fixed-scope, so ask for the scope, deliverables and timeline in writing before work starts, and ask which parts are one-time (the first migration) and which recur (each upgrade cycle, or a retainer for ongoing support and upgrades).

The cost follows the written scope, and the largest drivers are the number of integrations, the extensions you need, the payment page design, the testing you require and the upgrade commitment. Hosting is a separate recurring cost paid to your cloud or data center provider, and the implementation partner is paid for planning, build, migration and documentation. Ask each bidder to price these components separately so you can see what is one-time and what recurs. Platform licenses differ by product: Magento Open Source is licensed under OSL-3.0, WooCommerce under GPL version 2 or later, and Saleor under BSD-3-Clause, so the license itself is usually not the main cost. Ask for the quote to list every extension, integration and environment it covers.

Duration depends on catalog size, the number of channels and currencies, integrations with ERP or PIM systems, payment provider setup and how much custom theme or checkout work is in scope. No duration is set by a general rule, so ask each partner for a timeline tied to the written scope and to named milestones such as migration rehearsal, load testing and cutover. Timing also depends on your own review cycles and on the platform release schedule. For example, Adobe documents that each 2.4.x Magento release has three years of standard support, so a project that starts on an older line may need an upgrade plan before go-live. Ask the partner which platform version they will build on and when its support ends.

Your team must make decisions and supply access. Expect to name a product owner who can approve catalog rules, tax and pricing logic and checkout flows, and to provide a technical contact for cloud accounts, DNS, certificates, identity provider and ERP interfaces. Finance and operations staff need to confirm order statuses, returns, and stock sources. Someone from security or compliance should review the payment page design and the hosting controls. Ask the partner to list these roles in the proposal with an estimated number of review sessions, and to state who signs off each stage in writing before work begins.

Some teams can, but the answer depends on skills you already have and on how much change you expect after launch. Running a store involves Linux hosting, database and cache services, search, queues, backups, security patches and platform upgrades. Magento Open Source, for example, requires a specific combination of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx, and Adobe supports only the listed combinations. Saleor needs its API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers. Assess honestly whether your staff can maintain that stack, watch it and respond to incidents. Many buyers split the work, keeping day-to-day operations in-house and buying design, migration or testing as fixed-scope projects.

A useful quote lists the scope in writing, the deliverables and the acceptance criteria for each. Ask it to cover the platform setup and version, theme or storefront work, each integration with its interface and data direction, extensions with their upgrade path, the payment provider setup and the PCI DSS work, catalog and order migration with rehearsal runs, performance and load testing, security testing, documentation, training and handover. Also ask which items are one-time and which recur, such as hosting, monitoring, patch application, platform upgrades and support. Request the assumptions the price depends on, the change request process and the exclusions. DeployOpen works from a written scope with agreed deliverables and timelines, and it does not publish a price list, so a quote follows from that scope.

Payment page work adds cost because the checkout design decides how much validation your organization must complete. A redirect or hosted payment page usually reduces the scope of your own card data environment compared with a self-built card form, but it still requires controls for any script that runs on the page. PCI DSS 6.4.3 concerns managing payment page scripts, and 11.6.1 concerns detecting changes to those pages. Ask the partner to state which self-assessment questionnaire they expect your checkout to fall under, which scripts will run, how they will be authorized and monitored, and who prepares the evidence. Your acquirer or qualified assessor makes the formal determination.

The organization that operates the store pays for patches and upgrades, either through its own staff or through a retainer with a partner. Patching includes the platform core, extensions, the operating system, the database and the cache services. Adobe states that security patches are released at least annually for all supported Magento release lines, and that a full patch for the 2.4.x LTS line ships annually in May, so plan a recurring upgrade window. WordPress.org notes that only the most recent release in a series is actively maintained, which applies similarly to other platforms. Ask each bidder for its patch response process, its upgrade effort per cycle and whether support retainers are offered.

Start with how the partner plans to keep your store upgradable, how it will test performance and how it documents the platform. Ask for examples of similar work described in general terms, since specific client names should be verified through references under confidentiality. Check whether the partner can explain the platform choice against your catalog, channels, integrations and team skills. Ask who performs security testing and whether it is independent of the build team. Confirm that the proposal names the hosting environment, your ownership of accounts and data, and the exit terms. Make the final choice on the written scope, not on general claims.