Which fits: BigCommerce or Medusa for your store?
BigCommerce fits a team that wants a managed store, with the vendor handling hosting, platform upgrades and day-to-day operations, plus an app marketplace and a storefront built on Catalyst. Catalyst is an MIT-licensed Next.js frontend, but it still runs against a BigCommerce account, so it does not remove the dependency. If a renewal or plan change is the main pressure and your team has no appetite for running servers, staying hosted and negotiating the contract is usually the lower-effort path. Before you renew, confirm your current plan's Catalog API rate limits, list the apps your store depends on, and read what the contract says about data export and term length, since those set how hard an exit would be later.
Medusa fits a team with engineering capacity that wants to own the backend, the data and the commerce logic. Its core is MIT licensed and built on Node.js, TypeScript and PostgreSQL, with modules for carts, orders, product catalogs, pricing and inventory. Custom checkout or pricing rules become code in your repository that your team can test and version. The cost is operational: a self-hosted deployment needs PostgreSQL, a Redis database, a server instance and a worker instance, plus secrets such as COOKIE_SECRET and JWT_SECRET. Role-based access control features in the Enterprise Edition need a commercial agreement with MedusaJS, Inc., so confirm which access controls you require before assuming open-source coverage. Share the Medusa deployment documentation with your platform team early in the evaluation.
The decision turns on three things. First, in-house engineering skill: can your team build and maintain a storefront, write modules and run database migrations, which Medusa applies through a predeploy script before each startup? Second, hosting responsibility: BigCommerce carries platform operations, while a self-hosted Medusa makes your team accountable for uptime, backups, patching and the payment and search services you connect. Third, how much custom commerce logic you need: if the store relies mainly on standard apps, a managed platform is usually less work to run, while bespoke pricing, B2B rules or data residency requirements favor Medusa's modules. Write down your answers to all three, then ask both vendors and any implementation partner for a quote against that same written scope.
Which platform fits which scenario
This table matches common merchant situations to the platform that usually fits better, based on hosting responsibility, customization effort and day-to-day operating load. Read each row against your own team, data rules and storefront plans, and treat the reasons as starting points to confirm rather than final answers.
| Scenario | Better fit | Reason |
|---|---|---|
| Small team with no in-house developers | BigCommerce | BigCommerce hosts the platform, handles upgrades and offers apps for common needs. Self-hosted Medusa needs PostgreSQL, Redis, a server instance and a worker instance run and patched by someone on your side or a partner. |
| Headless build with a custom storefront | Medusa | Medusa exposes its commerce modules for carts, orders, pricing and inventory to your own storefront, so customization happens in code you own. With BigCommerce, Catalyst can sit in front of the platform, but the backend stays a BigCommerce account. |
| Data residency in your own cloud or data center | Medusa | A self-hosted Medusa deployment runs inside your accounts, with your database, cache and S3-compatible file storage. Confirm with your compliance team which data categories and regions your requirements cover before deciding. |
| Business relies heavily on BigCommerce apps | BigCommerce | Many business functions may already be covered by BigCommerce apps. Medusa replaces those with modules and custom integrations you build or commission, so inventory every app in use and confirm an equivalent exists or is planned before moving. |
| Team wants to own the rate limits and integration pace | Medusa | BigCommerce API limits depend on plan and affect bulk extraction and sync jobs. A self-hosted Medusa instance has no vendor-set API quota, though your own infrastructure and database capacity then set the ceiling. |
| Operations team needs a hosted SLA and vendor-managed upgrades | BigCommerce | BigCommerce operates the service and its upgrades. With self-hosted Medusa, you plan migrations, run the predeploy migration step and monitor the /health endpoint yourself or through a support retainer. |
| B2B pricing, quotes or marketplace requirements | Confirm first | Medusa's documented modules cover carts, orders, pricing and inventory, and it supports B2B stores and marketplaces. Check your specific B2B pricing, approval and marketplace rules against the modules and extensions available before choosing, and confirm which Enterprise Edition features need a commercial agreement with MedusaJS, Inc. |
| Licensing predictability and lock-in concerns | Medusa | The core Medusa framework is MIT licensed, so the code remains available to you. Enterprise Edition features based on role-based access control need a commercial agreement, so confirm which of your needs fall into that group. |
What running Medusa involves: PostgreSQL, Redis and two instances
A self-hosted Medusa deployment is not a single application process. It needs a PostgreSQL database, a Redis database, and two Medusa instances: one running in server mode to serve the API and admin dashboard, and one running in worker mode to handle background tasks. Plan for all four components from the start, because the BigCommerce store you are leaving handles these concerns inside SaaS infrastructure that you do not see today. Each component needs its own backup, monitoring, access control and upgrade path. The production setup also changes which modules you run. The development defaults are replaced with Redis-based caching, an event bus, the workflow engine and locking, and S3 for file storage, so product images and other uploads go to object storage rather than the local disk. Decide early which S3-compatible store you will use, since it affects where product images from the BigCommerce export land. Medusa also runs database migrations through a predeploy script before each startup, so your release process must run migrations in a controlled order, and you should rehearse rollback on a copy of the database before go-live.
Configuration is the other practical gap. Both the server and the worker need database credentials, plus COOKIE_SECRET and JWT_SECRET values. Generate these per environment, store them in your secrets manager, and never reuse them between staging and production. A deployment is verified through the /health endpoint, which should be wired into your load balancer and monitoring checks rather than checked by hand.
Your team will need working Node.js and TypeScript skills to operate and customize this stack. Confirm the supported Node.js version, the PostgreSQL and Redis versions, and the required environment variables against the current Medusa deployment docs before you size the environment, because these requirements change between releases. Ask your implementation partner to document the exact versions they tested, and to show the two-instance layout running in your own infrastructure.
Where your customer and order data lives
Moving from BigCommerce to Medusa changes who runs the servers, who holds the database and who answers when something breaks. Each card below covers one decision that follows from that shift, and each one should be settled before a migration plan is signed off.
Hosting responsibility
BigCommerce runs the store, its infrastructure and its uptime on your behalf. Medusa is open source, so you choose between Medusa Cloud managed hosting and a self-hosted deployment in your own cloud account or data center. Either way, the Node.js application, PostgreSQL, Redis and storage become components your team or partner must operate, monitor and scale. Ask who carries the on-call duty for checkout and what uptime target you will write into internal runbooks.
Data location and residency
With BigCommerce, customer, order and payment records sit in the vendor's hosted environment, and your contract defines where they can be stored. With self-hosted Medusa, you decide the region, the cloud account and the database location for the PostgreSQL database and the S3 bucket holding product files. Confirm where backups, logs and analytics copies are written, since those copies often leave the primary region without anyone noticing.
Identity and access control
Medusa's core framework is MIT licensed, but role-based access control features in its Enterprise Edition require a commercial agreement with MedusaJS, Inc. Without that agreement, plan how admin users, staff roles and store-level permissions will be handled in the open-core version, and document who can change prices, refunds and customer records. Map these roles against the BigCommerce user permissions you use today before the cutover.
PCI scope by payment setup
PCI DSS scope depends on how card data flows, not on the storefront platform alone. A hosted payment page or tokenized payment provider keeps card numbers out of your servers, while a setup that handles raw card data widens your assessment. BigCommerce's checkout and Medusa's payment provider integrations are separate decisions, so document each data path in a diagram. DeployOpen can prepare that scope documentation and the supporting evidence, but qualified assessors determine the outcome.
Backup and patch ownership
On BigCommerce, the vendor applies platform patches and manages infrastructure backups. On self-hosted Medusa, you own backups of PostgreSQL and the file store, tested restore procedures, and timely updates to the Medusa release line and its dependencies. Medusa runs database migrations through a predeploy step before each startup, so every upgrade needs a rehearsed backup first. Ask for a written restore test result and a named owner for each patch cycle.
Medusa Cloud or self-hosted
Medusa Cloud shifts infrastructure operation to a managed service, which keeps your team closer to the BigCommerce operating model. Self-hosting gives full control over location, network boundaries and secrets, but it adds the work of provisioning two Medusa instances, Redis, PostgreSQL and monitoring. Compare both options against your data residency rules and your in-house platform skills, and confirm with the vendor which regions and support terms apply to Medusa Cloud before choosing.
Customization through apps and APIs versus Medusa modules
On BigCommerce, most extensions come from apps in the BigCommerce marketplace, which the merchant installs and configures. Custom behavior is written against the platform APIs, usually by an agency or an in-house developer working within the limits of each API. On Medusa, customization is code in your own repository. You extend the commerce modules for carts, orders, product catalogs, pricing and inventory, and your team or implementation partner owns every line. No vendor marketplace sits between a business rule and the running store.
- App-based features: Marketplace apps are vendor-built software. You depend on the vendor's roadmap, data handling and support terms for each one.
- API-based features: Custom functionality calls the BigCommerce REST APIs from a separate service or app that you build and host.
- Module-based features: Medusa logic lives in custom modules, workflows and API routes under your version control and code review.
- Skills required: Medusa work requires Node.js and TypeScript skills, and BigCommerce integrations require whatever stack your app or service uses.
- Ownership of defects: A bug in a marketplace app goes to its vendor. A bug in your Medusa module is fixed by your team.
List every current app, mark the ones with no equivalent you can build yourself, and confirm which vendors you would need to replace.
On BigCommerce, the platform is maintained by BigCommerce, but your apps and custom API integrations can break when APIs or app requirements change, and each app vendor sets its own release schedule. On Medusa, you decide when to upgrade the framework and you test the result against your own modules and storefront. Medusa runs database migrations through a predeploy script before each startup, so schema changes ship with the code and a failed migration becomes a deployment problem your team must plan for. The Medusa deployment documentation describes this startup sequence.
- Platform updates: BigCommerce changes its own software on its schedule. Your exposure lies mainly in the apps and integrations you have installed.
- App compatibility: Each marketplace app depends on its vendor shipping a compatible version, so confirm this for every app before planning an upgrade.
- Framework upgrades: Medusa upgrades arrive as versioned releases you pull into your codebase, then test against your custom code.
- Schema changes: Predeploy migrations run before each startup, so staging should follow the same migration path as production.
- License checks: Confirm that any Enterprise Edition feature you rely on, such as role-based access control, remains covered by your commercial agreement after an upgrade.
Ask BigCommerce and each app vendor for their upgrade and deprecation notice practices in writing.
Checkout is where customization is hardest to move. On BigCommerce, checkout behavior is shaped through the extension points the platform exposes and the checkout and storefront options available on your plan. Verify those in current documentation before you design anything around them. On Medusa, cart, pricing, promotion and order logic are code you own, so a custom checkout rule becomes a workflow change in your repository. The payment, tax and checkout interface still need explicit integration, and your team must build or connect them.
- Platform-defined hooks: Confirm which checkout scripts or extension points your BigCommerce plan and storefront support for the checkout you intend to run.
- Rule location: On Medusa, a shipping, discount or B2B pricing rule sits in a module or workflow that you can test in continuous integration.
- Payment and tax integrations: On either platform, payment providers and tax calculation need explicit integration, so list the ones you require.
- Storefront ownership: With Medusa, the checkout interface is part of your storefront build, which makes accessibility, performance and PCI DSS scope decisions your responsibility.
- Testing: Build end-to-end checkout tests before migration so that each rule change can be verified on every release.
Map each checkout rule in your current store to a named owner, a platform location and a test before you estimate effort.
Extensions also depend on how data moves in and out of the platform. BigCommerce's Catalog API manages products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields, so external systems can read and write catalog data through the Catalog products API documentation. Each call counts against the rate limits set by your plan. On Medusa, the server instance serves the API and admin dashboard, so integration throughput depends on how you size PostgreSQL, Redis and the server and worker instances.
- Catalog access: The Catalog API covers products, variants, images, custom fields and metafields, which lets integrations sync catalog data.
- Rate limits: Bulk syncs must fit within your plan's rate limits, so check the current limits and schedule batch jobs around them.
- Self-hosted throughput: Medusa throughput depends on your infrastructure sizing, and you should load test it before go-live.
- Background jobs: The Medusa worker instance runs background tasks, so integrations that react to orders or inventory changes need a plan for those jobs.
- Monitoring: On your own infrastructure, you monitor the
/healthendpoint, the job queues and the database yourself, because no vendor watches them for you.
Ask for a written list of the API endpoints and rate limits your current apps use, then match each one to a Medusa module or custom route.
How API rate limits shape a catalog extraction
The Catalog API is the programmatic route for pulling a BigCommerce catalog into Medusa, and its rate limits decide how long the extraction takes. The Catalog API covers products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields, so one script can read the full product model rather than a flat export. Before you write that script, confirm the current request limits for your plan in the BigCommerce developer documentation, because limits differ by plan and can change. Then design the job around them: request products in pages, pull variants and images per product, and checkpoint progress so a throttled or failed run resumes where it stopped instead of restarting from zero.
Plan the import in batches that match the Medusa data model. Categories and brands should load before products so that references resolve, and bulk pricing rules need mapping to Medusa price lists or promotions before they are loaded. Custom fields and metafields usually need a decision: map each to a Medusa product attribute, a metadata entry or a custom module, and record which choice you made for each field. Image handling deserves a precaution. Shopify's documentation notes that its CSV export omits product images and advises keeping the original store live until the new store has imported images from their public URLs. The same pattern applies here: keep the BigCommerce store running and its image URLs reachable until every image in Medusa has been verified, because a redirect or a closed store breaks both the images and the SEO paths that reference them.
Treat the extraction as a dry run first. Run it against a copy of a representative category, count the records returned by the API, and compare them with the admin counts. Ask your implementation team to write the rate limit handling, retry policy and checkpoint format into the scope, so the schedule reflects the real throughput of your plan rather than an assumed one. Ask BigCommerce, through your account team if you have one, how limits apply to bulk endpoints and whether a higher tier changes them. Those answers determine how many extraction windows you need and whether the cutover can happen in one night.
What drives the cost of each option
What does a BigCommerce plan fee cover, and what drives it up?
BigCommerce charges a recurring subscription for the hosted store, and the plan tier you need is shaped by catalog size, traffic, API usage and the features you rely on. Ask BigCommerce for current plan pricing and the rate limits attached to each tier, because those limits affect how quickly you can extract data during a migration. Plan fees recur for as long as the store stays on the platform, and add-on apps often bill separately on top of the base plan. Check the terms that apply to your account, including any transaction or payment fees that depend on your payment provider.
What does it cost to host PostgreSQL, Redis and the Medusa instances?
Self-hosted Medusa needs a PostgreSQL database, a Redis database, and two Medusa instances: one in server mode for the API and admin dashboard and one in worker mode for background tasks. Each of these is a running component with compute, storage, backups, monitoring and patching, and the cost depends on your cloud or data center rates, how many environments you run (staging and production at minimum), and how highly available you need them to be. Most of this is recurring infrastructure spend. Ask for a quote that lists each component, its sizing assumptions and who maintains it.
Is the storefront build a one-time cost or an ongoing one?
The storefront build is mostly one-time, but it does not stay finished. Medusa is a headless backend, so you need a storefront that replaces what BigCommerce's theme and checkout provide today, unless you already run a Catalyst storefront and keep it on the BigCommerce backend. Build cost depends on the number of templates, the checkout flow, localization and any custom functionality. Ongoing work includes dependency updates and design changes. Ask for the storefront scope to be written out as separate deliverables so you can see what is one-time and what is maintenance.
What one-time costs come with migrating from BigCommerce to Medusa?
Migration costs are one-time and include extracting products, variants, images and custom fields through the Catalog API within plan rate limits, importing customers and orders, mapping data to Medusa's modules, and setting up redirects so SEO URLs survive. The effort rises with catalog size, the number of custom fields and metafields, the volume of historical orders you keep, and how many integrations must be re-pointed. Ask the provider to state which data is in scope, how the cutover will run in parallel with the live store, and what acceptance testing is included.
How do payment and search services change the total cost?
Payment processing and search are separate services with their own fees, and they do not disappear when you leave BigCommerce. You will still pay a payment provider per transaction and a fee structure set by that provider, and you may need a hosted or self-hosted search service such as Meilisearch, Typesense or OpenSearch, which adds hosting and tuning effort. Check which gateways you can connect to Medusa, what each charges, and whether any BigCommerce-specific payment arrangement will end at migration. Ask for these items as separate lines in the quote.
Who pays for upgrades and security patches in a self-hosted Medusa store?
You do, either directly through your own staff or indirectly through a provider retainer. BigCommerce applies platform updates as part of the subscription, while with Medusa you schedule upgrades, run database migrations through the predeploy step before each startup, test the storefront against the new version, and apply security patches to the operating system, Node.js, PostgreSQL and Redis. Upgrade cost recurs and grows with the number of custom modules and integrations you have. Ask whether the quote includes ongoing upgrades, testing and patch cycles, and on what cadence.
What support costs should I expect after launch?
Support is a recurring cost that you either staff internally or buy as a retainer. With BigCommerce you pay for the platform's support tiers and rely on its vendor channels, while a self-hosted Medusa store depends on the Medusa community, your own engineers, your hosting provider and any commercial agreement you hold. Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc., so check whether any feature you need falls under that agreement. Ask for response expectations, on-call coverage and what is excluded before you compare totals.
Can DeployOpen give me a price for this migration?
DeployOpen does not publish a price list. Most engagements are fixed-scope, so a quote follows from a written scope that lists deliverables, what is excluded, the timeline and the assumptions behind each item, including catalog size, data volume, integrations and the storefront approach. The same scope also determines the one-time and recurring split. Ask for the quote to separate migration, storefront, infrastructure setup, and any retainer for ongoing support, upgrades and continuous testing.
How a move from BigCommerce to Medusa runs
The sequence moves the catalog, customers and orders out of BigCommerce, puts a Medusa backend and storefront in place, and cuts over only after the new store is verified against the live one.
Confirm scope and inventory the store
Agree in writing which data moves: products, variants, images, categories, custom fields, bulk pricing rules, customers, open orders and order history, plus the apps and integrations that touch them. Check the BigCommerce plan and its API rate limits, because they set how fast extraction can run. Your DeployOpen scope, or your internal team, produces a field-by-field mapping document. The step is done when the business owner and the engineering lead have signed off on that mapping and on what will not migrate.
Extract the catalog and customers through the Catalog API
Pull products, variants, categories, brands, images, custom fields and metafields through the BigCommerce Catalog API, pacing requests to stay within the rate limits of your plan. Store raw exports unchanged in a staging area so each run can be repeated. Image files are fetched from their source URLs and stored in your own object storage. Customers are exported separately and checked for missing emails and duplicate records. The step is done when record counts in staging match BigCommerce counts for each entity type.
Map data to the Medusa product and pricing model
Translate BigCommerce variants, option sets, custom fields and bulk pricing rules into Medusa products, product variants, options, price lists and any custom module fields you decide to keep. Decide how each BigCommerce app's data is represented, since Medusa extends behavior through modules and its own API rather than through marketplace apps. Write the transformation as scripts so the same run can be repeated before cutover. The step is done when a sample set of products loads into a test Medusa instance and reviewers confirm the variants, prices and images match the source.
Stand up PostgreSQL, Redis and the Medusa instances
Provision a PostgreSQL database and a Redis database, then run one Medusa instance in server mode for the API and admin dashboard and one in worker mode for background tasks. Production settings replace development modules with Redis-based caching, event bus, workflow engine and locking, and S3 for file storage. Set the database credentials, COOKIE_SECRET and JWT_SECRET values as secrets in your environment. Migrations run through the predeploy script before each startup. The step is done when both instances pass the /health check and a test order can be placed and seen in the admin.
Import customers and orders into the new store
Load customers first, then historical orders linked to those customers, using the import scripts written in the mapping step. Confirm which order history must be queryable, and whether payment tokens can move at all. Most processors do not allow card data to be transferred, so plan for customers to re-enter payment details or for payment to be reconnected through the new processor. Reconcile order totals, tax lines and fulfillment status against BigCommerce. The step is done when reconciliation reports show no unexplained differences in counts or totals.
Rebuild the storefront and map SEO redirects
Build the storefront on Medusa's commerce APIs, reproducing the templates, checkout flow and any headless components your team already uses. Build a redirect table that maps every indexed BigCommerce URL, including product, category and brand pages, to its new address, and deploy it with the storefront. Test templates, search and checkout on staging. The step is done when a crawl of the old URL list returns a redirect or a live page for every entry, and checkout completes end to end on staging.
Run parallel testing before cutover
Operate the new store against a copy of current data while BigCommerce continues to take live orders. Test pricing, tax, shipping, promotions, inventory sync, email notifications, payment capture and refunds, and the admin workflows your staff use every day. Run a dated delta export to capture changes made after the first load. The step is done when a defined test checklist passes, the delta load is repeatable, and the business owner has signed the go-live criteria.
Cut over and keep BigCommerce live until verified
Switch DNS, payment and integration endpoints to the Medusa stack during a window agreed in advance, with the final delta load run just before the switch. Keep the BigCommerce store live and readable as a fallback until the new store has been verified in production, including order flow, redirects and search indexing. Only then decide when to cancel the BigCommerce plan. The step is done when production orders are flowing through Medusa, redirects are serving traffic, and the rollback procedure has been confirmed in writing.
Questions buyers ask before choosing Medusa over BigCommerce
How much effort does moving from BigCommerce to Medusa actually take?
The effort depends mainly on catalog size, how many BigCommerce apps your store relies on, how much custom checkout logic you run, and whether you rebuild the storefront or keep an existing one. Medusa replaces the commerce backend, but it does not include the storefront, payment connections, search or tax logic that BigCommerce now supplies through apps and built-in features. Ask for an inventory of every app, integration, custom field and checkout rule before anyone estimates work. That inventory is the input that turns a vague project into a scoped one.
Can an internal team run a self-hosted Medusa store on its own?
A team can run Medusa alone if it already operates Node.js services, PostgreSQL and Redis in production and has people who can own upgrades and incident response. The deployment has several moving parts: a server instance for the API and admin dashboard, a worker instance for background tasks, Redis, PostgreSQL and file storage. Check whether your team can staff on-call coverage, patching and backup restore testing. If any of those are missing, plan for outside help or a retainer for ongoing support and upgrades.
What skills do our engineers need for a Medusa migration?
Your engineers need working knowledge of TypeScript, Node.js, PostgreSQL and Redis, plus enough API experience to write an extraction script against the BigCommerce Catalog API and load the results into Medusa. Storefront work requires frontend engineers who can rebuild product pages, cart and checkout flows. Someone must also own DNS changes, redirects for existing URLs and environment secrets. Confirm these skills with your engineering leads before committing to a schedule, because gaps in any one area tend to surface late.
How long does a move from BigCommerce to Medusa take?
The timeline depends on scope, and no fixed duration applies to every store. The main drivers are catalog size, the number of integrations to replace, the storefront rebuild, testing of orders and payments, and how much SEO redirect mapping is required. DeployOpen agrees a timeline in a written plan before work starts, based on the scope your team confirms. Ask any provider for a written plan that lists phases, deliverables, owners and the testing gates before cutover.
Can we keep the Catalyst storefront if we move to Medusa?
Catalyst is an MIT-licensed Next.js storefront that connects to a BigCommerce backend, so it does not run against Medusa as delivered. Keeping the front end means rebuilding its data layer to call Medusa's APIs instead of BigCommerce's, and checking that the page templates, search and checkout still behave as expected. Reusing the component code can reduce rebuild work, but the integration layer must change. Confirm the exact effort with an engineer who reviews your Catalyst version against the Medusa APIs you plan to use.
How does Medusa's licensing and Enterprise Edition affect the decision?
The core commerce framework is MIT licensed, so you can self-host it without a license fee for that code. Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. Before you choose, list the admin permissions your organization needs and confirm with the vendor whether those features fall under Enterprise Edition. Also confirm whether you will use Medusa Cloud managed hosting or run the deployment yourself, because that choice changes who owns hosting, upgrades and operations.
Who is responsible for hosting, security patches and uptime after the move?
With self-hosted Medusa, your organization or its hosting provider owns the servers, PostgreSQL, Redis, storage, TLS, backups and security patches, which BigCommerce handles today as a hosted service. Ask for a responsibility matrix that assigns each layer to a named owner, along with the patch cadence and the backup restore test schedule. DeployOpen plans, hardens, backs up and supports self-hosted platforms inside your own cloud accounts or data centers, and ongoing support is available as a retainer.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, whether that is your cloud accounts, your data center or an air-gapped network. For a Medusa move, that means the scope covers the PostgreSQL and Redis databases, the two Medusa instances (one in server mode for the API and admin dashboard, one in worker mode for background tasks), the S3 file storage, the storefront build and the cutover plan. Before any work starts, you and DeployOpen can agree which of these are in scope, who owns each one after handover, and which BigCommerce data (catalog, customers, orders, redirects) must be proven in the new store before the old one is switched off.
Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work begins. Ask for a written scope that names each deliverable, for example the migration script for the Catalog API extraction, the environment configuration including the COOKIE_SECRET and JWT_SECRET values handling, the /health check procedure, the backup and restore test, and the handover documentation. Ask the same of a quote: it should follow from that written scope, and DeployOpen does not publish a price list. Ongoing support, upgrades and continuous testing are available as retainers, which matter because Medusa releases and the Node.js and database versions they depend on will change after go-live. Confirm with DeployOpen which of these items sit inside a fixed-scope project and which move to a retainer.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. If your payment or privacy obligations require independent assessment of the new platform, confirm the assessor's requirements early and ask DeployOpen to produce the configuration records, access reviews and backup evidence that the assessor will request. Before signing, ask for a reference to a comparable self-hosted deployment that you can verify with your own team, and confirm the named engineers, their responsibilities and how incidents will be handled after handover.
