Why a BigCommerce Catalyst alternative starts with the backend
The storefront can be kept, but the backend decides what you are locked into. Picture a team that has spent months building its storefront in Catalyst, the Next.js frontend BigCommerce publishes under the MIT license. The components, pages and styling belong to that team and can be read, changed and moved. Yet every cart, price calculation, order, customer record and inventory check still runs on a BigCommerce store. The code is portable; the transactions are not. Before any migration plan is written, the team should list which data and rules live only in the BigCommerce admin and API, because those are the items that decide lock-in, where personal data sits and what the platform costs each year.
Catalyst's MIT license covers the storefront source it contains. It does not cover the commerce service behind that storefront, which BigCommerce operates and bills for, and it does not change where orders or customer data are stored. A self-hosted replacement therefore has to take over the commerce service itself. Medusa and Saleor are the two self-hosted options in this comparison that do that: Medusa is built on Node.js, TypeScript and PostgreSQL, and Saleor on Python, Django, GraphQL and PostgreSQL. Either one moves the backend into your own infrastructure, and the Catalyst code can then be adapted to call a different API rather than being thrown away.
The practical decision is therefore about the backend first. Ask who will run the database, cache, workers and upgrades after launch, which controls must hold for payment and personal data, and which BigCommerce apps and integrations your operations depend on. Confirm the licensing terms for any paid features you expect to need, since Medusa's role-based access control features sit under a commercial agreement. Those answers determine whether keeping BigCommerce as the backend, or replacing it with Medusa or Saleor, is the better path, and they should be settled before the storefront work is scoped.
What a control-focused headless constraint requires
Moving from a hosted BigCommerce backend to a self-hosted headless stack changes who holds the data, which license applies and what the bill contains. Each card below is a point where the organization must be able to show or change something, whichever backend it chooses.
Where catalog, customer and order data lives
With BigCommerce, catalog, customer and order records sit in BigCommerce's hosted service and you reach them through its APIs. With Medusa or Saleor, the same records sit in a PostgreSQL database you operate, in the region and network you choose. Ask which systems hold personal data, where backups are kept and who can read the database directly. Confirm how each export path, including the Catalog API, returns customer and order fields, because some fields may need a separate call or may not be exported at all.
License governing each layer
Catalyst is MIT licensed, but the commerce engine behind it is a separate product under its own terms. Medusa's core is MIT licensed, while its Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. Saleor is BSD-3-Clause. Map each layer (storefront, commerce engine, admin, plugins, hosting image) to its license and list any feature your team needs that sits behind a commercial agreement before you commit.
Portability of the storefront code
Catalyst code is written against BigCommerce's storefront APIs, so swapping the backend means rewriting data access in every component that calls them. A headless stack built around GraphQL (Saleor) or a Node.js service layer (Medusa) needs a new data adapter, while page structure and styling can often be reused. Ask engineering to list every call to the BigCommerce API in the storefront, then estimate which pages depend on fields that the new backend will shape differently.
Itemized run costs
A BigCommerce subscription bundles hosting, uptime and platform upgrades into one recurring fee. A self-hosted stack splits that into the database, cache, application instances, object storage, storefront hosting, payment and search services, monitoring and the staff hours for upgrades. Medusa, for example, needs PostgreSQL, Redis and two Medusa instances, one for the API and one for background workers. Request a line-item model from any implementation partner that shows which costs are one-time, which recur and which scale with traffic or catalog size.
What Catalyst keeps for you and what it leaves on BigCommerce
The storefront code is the part of a Catalyst build that a team can keep outright. Catalyst is MIT licensed and built on Next.js and React, so the team can fork the repository, change templates, components and data-fetching logic, and host the result on infrastructure it controls. That code carries over to a fully open-source stack only as a starting point. Before planning a move, check which of its data calls go to the Catalog API and which go to the storefront APIs, since those calls define what must be replaced. Confirm the current MIT notice and the dependency licenses in the fork, and record the Next.js version the team will run, because the storefront will need upgrades on its own schedule after the move.
Several things stay on BigCommerce unless the team moves them. The Catalog API is the programmatic source of products, categories, brands, variants, images, custom fields and metafields, and it is also the first technical step in any move, because the catalog has to be extracted before a new backend can be populated. The store also holds carts, checkout, orders and customer records, and these are not replaced by forking the storefront. Ask BigCommerce and your implementation partner which of these records can be exported in full, which need custom export work, and how image files will be fetched and rehosted. Plan for a period where the live store and the new backend both hold data, and decide early which system is the source of truth for orders and customers.
The practical question for the team is who will run the replacement for each of these responsibilities. Catalyst keeps the storefront on the team's side, but a Medusa or Saleor backend adds a database, a cache, background workers and a checkout integration that someone must operate. Identify the payment provider, tax and shipping integrations currently wired through BigCommerce, and confirm each one has a route in the new stack. Draft a written scope that names the catalog extraction, the mapping of custom fields, the order and customer import, and the storefront changes. A clear scope makes the cost comparison with keeping BigCommerce as the backend much easier to read.
Keep BigCommerce behind Catalyst or move the backend to Medusa or Saleor
This table compares keeping BigCommerce as the commerce backend under Catalyst with self-hosting Medusa or Saleor as the backend. Read each row as a decision point: who holds the data, who operates the stack, and how much customization you can do without a vendor's app marketplace. The main takeaway is that Catalyst removes storefront build work but not the SaaS dependency, while Medusa and Saleor remove the dependency but move hosting, upgrades and security into your team.
| Dimension | Catalyst on BigCommerce | Self-hosted Medusa or Saleor |
|---|---|---|
| License and commercial terms | Catalyst storefront code is MIT licensed, but the BigCommerce platform is a paid SaaS subscription under BigCommerce's own terms | Medusa core is MIT licensed, and Enterprise Edition role-based access control requires a commercial agreement with MedusaJS, Inc. Saleor is BSD-3-Clause |
| Where commerce data is stored | In BigCommerce's hosted environment, so catalog, customers and orders stay in the vendor's infrastructure | In your own PostgreSQL database and cloud accounts, so you choose region, backups and retention |
| What the team operates | The Next.js storefront build and hosting, plus BigCommerce store configuration and API integrations | Application servers, PostgreSQL, Redis or Valkey, background workers, file storage, upgrades and security patching |
| How customization works | BigCommerce apps and the Catalog and Storefront APIs, within the limits of each plan | Medusa modules and workflows, or Saleor webhooks, apps and metadata extensions, built and owned by your team |
| Catalog extraction effort | Low, because the catalog stays in place and the storefront reads it through the API | Moderate to high, because products, variants, images and custom fields must be extracted and imported |
| Main trade-off | Fastest path to a modern storefront, but you keep paying for the platform and stay tied to its API rules | Full control of data and code, in exchange for owning hosting, uptime and upgrades yourself |
How Medusa and Saleor differ for a team replacing BigCommerce
Medusa is a Node.js and TypeScript commerce framework on PostgreSQL. Its commerce logic is split into modules for carts, orders, product catalogs, pricing and inventory, and the project documents use in B2B stores, marketplaces and point of sale. The core is MIT licensed, but Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc. Confirm early whether your admin permission model depends on those features.
- Stack: Node.js, TypeScript and PostgreSQL. Production replaces development modules with Redis-based caching, event bus, workflow engine and locking, and uses S3 for file storage, so Redis and object storage are part of the run cost.
- Processes: two Medusa instances, one in server mode for the API and admin dashboard and one in worker mode for background tasks. Database migrations run through a predeploy script before each startup, so a failed migration blocks the release.
- Secrets and checks: the server and worker each need database credentials plus COOKIE_SECRET and JWT_SECRET values, and a deployment is verified through the /health endpoint. Your platform team owns rotation and monitoring of these values.
- Extension model: customization is written in code inside your project, through modules and workflows. Your developers own those changes through every upgrade.
- Storefront: a separate frontend build that calls the Medusa API. Existing BigCommerce storefront code should not be assumed to carry over, so budget a rebuild.
Check the Medusa deployment documentation and compare its modules against your catalog, pricing, promotion and tax needs before you commit.
Saleor is a BSD-3-Clause commerce platform built on Python, Django, GraphQL and PostgreSQL. Everything is exposed through a GraphQL API, and the core supports per-channel pricing, currencies, stock and products across multiple warehouses. Its built-in commerce features include split payments, returns, multi-warehouse fulfillment, multi-gateway payment support and a promotion engine covering sales, vouchers, cart rules and gift cards.
- Stack: Python and Django on PostgreSQL, with the API, the Dashboard, Valkey or Redis, and Celery workers. Your team needs Python and Django operations skills alongside your frontend developers.
- Resources: the Docker Compose setup asks for at least 5 GB of memory for Docker, which is a minimum for evaluation rather than a production sizing guide. Ask your platform team to size production separately.
- Extension model: Saleor extends through webhooks, apps, metadata and API extensions, so custom logic runs outside the core process and can be upgraded with less coupling to the core code.
- Configuration: settings are supplied as environment variables following 12-factor app principles, which suits container platforms and secrets managers.
- Storefront: a separate build that consumes the GraphQL API. Channel and attribute design should be settled before the frontend is built, because it shapes every query.
Review the Saleor Docker Compose documentation and map your BigCommerce customizations to channels, metadata and apps before you choose a path.
Both platforms need a storefront built and hosted by your team or a partner, so the storefront is a separate project in either case. The choice depends on which BigCommerce features your business relies on, and on whether your team wants to run Node.js or Python in production. Write that feature list before comparing platforms, because most migration problems come from features nobody listed.
- Catalog model: list your variants, custom fields, metafields, bulk pricing rules and category structure, then check how each option represents them in its catalog and pricing modules or attributes and channels.
- Multi-storefront and B2B: if you run several storefronts, currencies or customer-specific pricing, confirm the channel or module design in each vendor's documentation with a proof of concept.
- Search and checkout: confirm whether faceted search, tax calculation, shipping rules and payment gateways are included or need separate services, and who operates them.
- Licensing and support: ask for the written terms behind any Enterprise Edition or cloud offering, and get a quote based on a written scope before committing.
If a feature is not documented in either platform, treat it as a gap to test, not as a given.
How to deploy Medusa or Saleor under your own control
This sequence takes a team from empty infrastructure to a running Medusa or Saleor back end that they operate, with the database, cache, file storage and health checks in place before any catalog data moves. It ends with a storefront cutover plan that protects existing URLs and search rankings.
Provision PostgreSQL and Redis in your environment
Your platform or infrastructure team creates a PostgreSQL database and a Redis instance inside your own cloud account, data center or private network, with access limited to the application hosts. Medusa requires both, and Saleor uses PostgreSQL with Valkey or Redis. Record the connection strings in your secrets store and confirm that each service accepts connections from the hosts that will run the application. The step is done when a test client can connect to both from the intended subnet and nowhere else.
Deploy the Medusa server and worker as separate processes
Medusa's self-hosted setup runs two instances of the same application: one in server mode that serves the API and admin dashboard, and one in worker mode that handles background tasks. Your platform engineers deploy each as its own process or container so they can be scaled and restarted independently. Set the database credentials on both, then confirm the server instance starts and the worker instance reports that it is consuming jobs. Do not treat the worker as optional, because queued work such as order and event processing depends on it.
Set the COOKIE_SECRET and JWT_SECRET values
Generate distinct, high-entropy values for COOKIE_SECRET and JWT_SECRET and store them in your secrets manager, not in source control. The server and worker each need these values, so inject the same settings into both processes through your deployment tooling. Document who can rotate them and how a rotation would invalidate existing sessions and tokens. The step is complete when both processes start with the values loaded from the secrets store and a login to the admin dashboard succeeds.
Configure S3 for file storage
Medusa's production setup replaces the development file module with S3 storage, so product images and other uploads are kept outside the application host. Create a bucket in the same region as your application or in an S3-compatible store you run, such as Ceph RADOS Gateway, SeaweedFS or Garage, and grant the application a scoped access key. Confirm the bucket policy blocks public listing and that an image uploaded through the admin returns a URL the storefront can load. Confirm with your storage team which encryption and retention settings your policy requires.
Run migrations through the predeploy script
Medusa runs database migrations through a predeploy script before each startup, so the schema is updated as part of every deployment. Run the deployment pipeline against a staging copy of the database first and review the migration output for errors before promoting to production. Keep a verified database backup taken immediately before each production migration. The step is done when the predeploy script exits cleanly and the server reports the expected schema version.
Confirm health through the /health endpoint
Point your load balancer or uptime monitor at the Medusa /health endpoint and confirm it returns a healthy response from each server instance. Check the worker through its logs or your process monitor, since it does not serve the same endpoint. Add an alert for repeated health failures and record who receives it. The step is complete when a deliberate restart of one server instance is detected by monitoring and recovers without manual database changes.
Deploy Saleor's API, Dashboard and Celery workers
For Saleor, your team deploys the API, the Dashboard, PostgreSQL, Valkey or Redis and Celery workers, using the Docker Compose setup as the reference for how the pieces connect. The Docker Compose documentation asks for at least 5 GB of memory for Docker, so size the host with headroom above that minimum for your own traffic. Configure every setting as an environment variable following 12-factor principles, and keep those values in your secrets store. The step is done when the API responds, the Dashboard loads and a Celery worker picks up a test task.
Plan the storefront cutover and redirects
Before switching DNS or storefront traffic, your team maps every live BigCommerce URL to its new path, including product, category, brand and content pages, and loads those redirects into the new storefront or the edge layer. Keep the BigCommerce store live until catalog images have been imported and checked against their original URLs. Run the new storefront against the new back end on a staging domain, compare key pages, and agree a rollback decision point with the business owner. The step is complete when the redirect map has been tested on staging and signed off.
What reviewers ask to see after the move
Once a BigCommerce Catalyst storefront runs on Medusa or Saleor, auditors, security reviewers and internal risk teams will ask for records rather than descriptions. The four evidence sets below cover what the stack is made of, how its secrets are handled, whether data can be restored, and whether the migrated data matches what was exported.
License and dependency inventory
List every component in the new stack: the Catalyst storefront, the Medusa or Saleor backend, each plugin or module, and the transitive packages beneath them. Record the license and the source for each item. Medusa's core is MIT licensed, but Enterprise Edition features based on role-based access control need a commercial agreement, so confirm which edition each feature depends on. Saleor is BSD-3-Clause. Keep the inventory current as versions change, and confirm the license of any extension a reviewer may question.
Secrets storage and rotation records
Document where each credential lives, who can read it, and how often it changes. A self-hosted Medusa server and worker each need database credentials plus COOKIE_SECRET and JWT_SECRET values, and Saleor is configured through environment variables. Reviewers will check that these values sit in a secrets store rather than in source control, that the BigCommerce API credentials used for extraction were revoked after the move, and that rotation was tested. Ask your team to show the dated change log.
Backup and restore test results
A backup policy is only evidence once a restore has been performed. Keep dated results for PostgreSQL, which holds carts, orders and catalog data, and for the object store that holds product images once Medusa's S3 file storage or Saleor's media storage is in use. Record the restore time, the row or object counts after restore, and the person who signed off. Also confirm that Redis is treated as rebuildable cache or is backed up on purpose, since its role differs between the two platforms.
Migration reconciliation reports
Compare counts and sample records between the BigCommerce export and what the new platform holds. Products, variants, categories, customers and orders should each have a matching report, with exceptions listed by ID. Image migration needs its own check, because product images may not travel with a catalog export and must be fetched from their public URLs. Keep the reports with the cutover record so that any later discrepancy can be traced to a specific import run.
What does it cost and take to replace BigCommerce behind Catalyst?
What drives the cost of keeping BigCommerce behind Catalyst versus moving to Medusa or Saleor?
The main difference is who pays for the platform. With BigCommerce, you pay a subscription for the hosted commerce backend, and Catalyst is an MIT-licensed Next.js storefront you still host and build yourself. With Medusa or Saleor, the software is open source, so the recurring costs shift to infrastructure and people: a PostgreSQL database, a Redis database, server and worker instances for Medusa or the API, Dashboard, Celery workers and PostgreSQL for Saleor, plus payment, search and email services you contract separately. Recurring costs also include upgrades, security patching and support, which BigCommerce handles as part of its plan. One-time costs include the catalog extraction, data mapping, storefront adaptation and cutover testing. Ask any partner to split these into one-time and recurring lines so you can compare them with your current invoice.
Can our in-house team replace the BigCommerce backend without an outside partner?
It depends on whether your engineers have run Node.js and TypeScript services in production (for Medusa) or Python, Django and GraphQL services (for Saleor). Both platforms need a managed database, a cache or event layer, background workers, environment-based configuration, migrations on every deploy and monitoring. Medusa's deployment docs describe a server instance, a worker instance, secrets such as COOKIE_SECRET and JWT_SECRET, and a health check endpoint, so an experienced platform team can follow them. The harder part is usually the data move and storefront rework, which need someone who knows both systems. Many teams handle hosting in-house and bring in outside help for the migration. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own environment under a written, fixed scope, so you can compare that with an internal estimate.
How long does a move from BigCommerce to a self-hosted headless stack take?
No timeline is fixed in the research behind this page, so treat any duration as something to confirm in writing. The length of the move is driven by catalog size, the number of variants, custom fields and metafields, how many bulk pricing rules must be mapped, the number of customers and orders to carry over, how many integrations and apps you depend on, and how much of the Catalyst storefront you keep. Your plan limits also matter, because the Catalog API is subject to rate limits set by plan, which lengthens large extractions. Parallel running, SEO redirects and payment gateway testing add time before cutover. Ask for a timeline broken into discovery, extraction, build, test and cutover phases.
What does the migration need from our team in staff time and system access?
Plan for a product owner who decides on catalog, pricing and checkout rules, an engineer who can run the extraction and import, a storefront developer, someone who owns DNS and hosting accounts, and a finance or operations contact for tax, payments and invoicing. Access requirements include a BigCommerce API account with scoped credentials for the Catalog API, export access for orders and customers, administrator rights in your cloud account to create the database, cache, object storage and compute, and access to your payment gateway and search provider. Your security team should review where customer and order data is stored during the move and who can read the extraction files. Confirm each role and access grant in the written scope before work begins.
Can we keep the Catalyst storefront code if we move the backend?
Partly, and this is the question to settle early. Catalyst is MIT licensed, so you can keep and modify its code. However, it is built to read data from BigCommerce, so its data calls, product and cart logic, checkout integration and any BigCommerce-specific components must be rewritten or redirected to the new backend's API. Medusa exposes its storefront data through its own APIs and Saleor exposes everything through GraphQL, so the layout, components and styling are often reusable while the data layer changes. Ask your partner to map each Catalyst module as kept, adapted or replaced, and to confirm the decision with a working prototype against the new API.
What should a quote for replacing BigCommerce itemize?
A useful quote separates work and recurring costs so you can compare it with your current BigCommerce invoice. Ask for these lines:
- Discovery and written scope, including the list of features you must match
- Catalog extraction through the Catalog API, data mapping and import, with customers and orders handled separately
- Storefront adaptation of Catalyst, including checkout, payments and search integration
- Hosting setup for the database, cache, workers, object storage and environments, and the infrastructure you will pay for each month
- Payment, search and email services you must contract separately
- Testing, cutover, SEO redirects and rollback plan
- Upgrades, security patching, backups and support, with whether they are a retainer or an add-on
- Documentation and handover to your team
Also ask which items are fixed in scope and which depend on catalog size, so any change request is priced in advance.
What ongoing work does a self-hosted headless stack add after go-live?
After go-live, your team or partner takes on upgrades, security patches, backups, monitoring and capacity planning that BigCommerce currently handles. For Medusa, each release can add database migrations, which run through a predeploy script before each startup, so upgrades need a staging test. For Saleor, the API, Dashboard, Celery workers and PostgreSQL all need version management. Both need secrets rotation, log retention and an incident process. Budget for a regular upgrade cycle, a monitored staging environment and a support arrangement. Retainers for ongoing support, upgrades and continuous testing are available from DeployOpen, and the recurring scope should be written down alongside the migration scope.
How DeployOpen scopes a self-hosted headless commerce move
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a BigCommerce Catalyst decision, we start by agreeing in writing which backend, storefront and hosting path the work covers, so the cost and lock-in questions are answered before any build begins.
How we scope
- Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states whether BigCommerce stays as the backend or moves to Medusa or Saleor.
- We list which Catalyst storefront code is reused, which is rebuilt, and which BigCommerce apps need replacements.
- A quote follows from the written scope, so ask for the components priced separately.
How we build
- We deploy the chosen backend in your environment, including its database, cache and worker components.
- We map catalog data, custom fields and metafields from the BigCommerce Catalog API to the target data model.
- We test storefront behavior, checkout flows, redirects and integrations against the agreed deliverables before cutover.
- We run security testing of applications and APIs as part of the build where the scope includes it.
How we hand over
- You receive documentation covering deployment, configuration, secrets handling and the migration record.
- We document backup and recovery procedures for the self-hosted stack and walk your team through them.
- Compliance readiness work produces systems, controls and evidence; independent auditors issue any formal assessment.
- Handover material names what your own team must operate, patch and monitor after go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover platform upgrades, dependency updates and periodic security testing of the storefront.
- Ask any provider which upgrade and patching responsibilities stay with your team under each option.
- Confirm response expectations in the written agreement rather than relying on general statements.
