Migrate from BigCommerce to Medusa: what the move involves
This is a headless rebuild, not a file import. Merchants usually arrive here because of a renewal, a licensing or pricing change, a data residency requirement, or pressure from lock-in. The catalog and customers can be extracted, but the storefront, checkout flow and integrations are new code that your team or a partner must write and test. The effort is real but bounded: it is set by the number of storefront pages, custom fields, installed apps and payment and shipping integrations you need to replace, so inventory those before you ask anyone for a quote. Medusa is open core. Its core commerce framework is MIT licensed, while Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc., so confirm which features your admin roles depend on before you design permissions.
Most teams do this work with an internal platform team supported by an implementation partner. The internal team owns the business rules, product data model and sign-off on the storefront, while the partner typically handles the extraction scripts, the Medusa deployment, the storefront build and load testing. Ask each bidder to name who writes the storefront code, who runs the data import, and who is accountable for the cutover. Agree in writing which parts are fixed scope and which are retained support after launch, since the storefront will need ongoing upgrades that BigCommerce previously handled for you.
Plan the decision and the staffing before the technical work starts. Confirm with your BigCommerce account team which API rate limits apply to your plan, because they set how long the catalog extraction takes. Then confirm with your Medusa hosting provider or internal operations group who will run the PostgreSQL and Redis services, and who will rotate the COOKIE_SECRET and JWT_SECRET values. Keep the BigCommerce store live until the new storefront has passed acceptance testing, since the source system is also your only fallback.
Which BigCommerce capabilities map to Medusa, and which need rework
This table maps the main BigCommerce capabilities to Medusa modules, the admin dashboard and the storefront you will build. Read each row as clean (a native Medusa module covers it), needs rework (possible, but you configure, extend or rebuild it) or gap (confirm before committing). Use it to scope the migration before pulling any data from the Catalog API.
| Capability | Medusa mapping | Status |
|---|---|---|
| Products and variants | Product catalog module with product options and variants, loaded through the Admin API or import scripts | Clean |
| Images | Product media uploaded to file storage, with S3 used in production; fetch image URLs from the Catalog API and re-upload | Needs rework |
| Categories and brands | Product categories and collections exist; brands usually need a custom field, module or product tag model | Needs rework |
| Custom fields and metafields | Map to product metadata or a custom data model in a Medusa module; plan the schema before import | Needs rework |
| Bulk pricing rules | Pricing module covers price lists and tiered prices; confirm each BigCommerce rule type maps before rebuilding | Needs rework |
| Customers and addresses | Customer module; passwords generally cannot be exported, so plan a reset or re-registration flow | Needs rework |
| Orders and history | Order module holds imported records; historical order data is often better kept in an archive than re-created as live orders | Needs rework |
| Checkout and payments | Cart and checkout workflows are provided, but payment providers and tax logic must be configured and tested | Needs rework |
| Apps and integrations | No direct equivalent to BigCommerce apps; replace each with a Medusa module, subscriber or external service | Gap |
| Storefront | Medusa has no bundled storefront; you build one, often on Next.js, against the Store API | Gap |
| Admin dashboard and role-based access | Admin dashboard ships with Medusa; fine-grained role-based access control is an Enterprise Edition feature requiring a commercial agreement with MedusaJS, Inc. | Gap |
| B2B, marketplace and POS | Medusa supports these store types; confirm each specific feature against the Medusa repository before scoping | Gap |
What data can be exported and what integrations must be rebuilt
A BigCommerce move is two jobs: moving records and rebuilding the services around the store. The catalog can be pulled programmatically, while customers, orders and third-party integrations each need their own mapping, verification and replacement plan before cutover.
Catalog through the Catalog API
The Catalog API is the programmatic path for products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields. Extraction must stay within the rate limits of your BigCommerce plan, so plan paginated, throttled jobs and run them more than once. Confirm which product fields your storefront needs, and map variants and custom fields to Medusa product and variant structures before writing any import code. BigCommerce's own export templates and WebDAV route are covered on the sibling export page.
Product images and media files
Image files do not come along with a product record, so you must fetch each image from its public URL and upload it to your own storage. Medusa production setups commonly use S3 for file storage, so decide that bucket layout early. Check that every image URL still resolves after cutover, and keep the original store live until the new store has imported its images.
Customer records and accounts
Customer exports carry contact details, tags and metafields, but password hashes and login sessions are the parts you should confirm with BigCommerce before you plan account continuity. Map customer groups and addresses to Medusa customer records, then import a sample batch and reconcile counts and email addresses against the source. Decide early whether customers will reset passwords on first login.
Order history and financial records
Orders link customers, line items, payments, refunds, tax lines and shipments, so they cannot be moved as flat rows. Map order statuses and line item references to Medusa orders, and keep a read-only archive of BigCommerce orders for returns, disputes and accounting. Verify totals, tax amounts and currency for a sample of orders before you trust the import.
Payment and tax integrations
Payment gateways, stored card tokens and tax calculation are tied to BigCommerce and do not transfer as data. Confirm with each gateway whether card tokens can be migrated, and plan the Medusa payment provider configuration and tax rules before launch. Check how PCI DSS scope changes if card data passes through your own environment, and confirm that with your assessor.
Shipping, search and third-party apps
Shipping rates and carrier accounts, search indexing, transactional email and any installed BigCommerce apps must each be replaced by a Medusa module, a plugin or a custom service. List every app and webhook in use, then assign each one an owner, a replacement and a test. Costs for these services are set by each vendor, so request current pricing from them directly.
How to pull the catalog through the Catalog API within plan rate limits
Catalog extraction is a script you write and run against the BigCommerce Catalog API, not a single export. The script pages through products and then requests each product's child resources: variants, images, custom fields, metafields, bulk pricing rules, categories and brands. The BigCommerce catalog products documentation lists the endpoints and the fields each returns, so map them to Medusa's product, variant, price and inventory modules before writing code. Confirm in your own account which endpoints your API account can read, because the scopes granted to the access token determine what the script can extract.
Rate limits are set by your BigCommerce plan, so check the limits that apply to your store before you size the job. Read the limit headers on responses, back off when the store signals it is throttling, and set the request concurrency low enough that the extraction does not compete with your live storefront traffic. Image files are a separate step: download each image from its public URL, store it in your own S3 bucket and keep the new URL in a mapping table. This matters because Medusa's production setup uses S3 for file storage, so images must be re-hosted there before the Medusa product records point to them.
Make the extraction job resumable and logged. Write each page cursor, product ID and image download result to a state table in your PostgreSQL database or a local file, and mark each record as complete only after the Medusa write succeeds. If the run stops because of a rate limit, a network fault or a server restart, the job can resume from the last completed page without creating duplicate products. Use the BigCommerce product ID or SKU as the external key on the Medusa side so that re-runs update existing records instead of inserting new ones. Keep the logs with timestamps and error codes, because they become the evidence that every product, variant and image was moved and that the counts match the source.
The migration sequence from inventory to decommission
This sequence moves the BigCommerce catalog, customers, orders and SEO URLs to a self-hosted Medusa store without losing trading history or search visibility. Each step produces a written record that the next step depends on, so the cutover happens only after the data has been checked.
Inventory apps, integrations and SEO URLs
List every BigCommerce app, payment gateway, shipping rule, tax setting, email flow, webhook and third-party integration, and note which ones the storefront or back office depends on. Export the current URL structure for products, categories, brands and content pages from a crawl and from search console data, so every indexed address has a known owner. The output is a written inventory that maps each function to a Medusa module, a replacement service or a deliberate retirement, and the owner who signed off on it.
Build a Medusa pilot with a product subset
Stand up a non-production Medusa environment with PostgreSQL, Redis, a server instance and a worker instance, and confirm the deployment passes the /health check. Import a representative subset of products, including several variants, custom fields and images stored in S3, and run one test cart through checkout and one order through fulfillment. The output is a pilot report that records which fields mapped cleanly, which required transformation, and which Medusa features still need custom modules or a third-party service.
Extract the full catalog through the Catalog API
Script the full extraction against the BigCommerce Catalog API for products, variants, categories, brands, bulk pricing rules, images and custom fields, and pace requests within the rate limits of your plan. Store raw responses unchanged so the transformation can be rerun if a mapping changes. The job is complete when every extracted record is logged with its source identifier and any failed pages are retried and accounted for.
Import customers and orders with reconciliation
Load customers and historical orders into Medusa, then compare record counts, totals, tax amounts and currency codes against BigCommerce for the same period. Decide in advance how bulk pricing rules become Medusa price lists or promotions, and document any rule that cannot be carried over. The output is a reconciliation report signed by the store owner, listing every difference and its resolution.
Run a parallel period with BigCommerce still live
Keep BigCommerce as the live storefront while the Medusa catalog, customers and images are refreshed and checked against it. Repeat extraction for changes made during the period and confirm that product images load from their stored locations, not from links that expire with the old store. Ask your storefront developer to confirm the rebuilt storefront renders the same pricing, stock status and variant selection before anything goes live.
Cut over with redirects and DNS
Prepare a cutover runbook that lists the final data sync, the DNS change, the redirect rules from every mapped BigCommerce URL to its Medusa equivalent, the payment and webhook reconfiguration, and the rollback steps with the person who can trigger them. Test the redirect map against the inventory from the first step, then run the cutover in the agreed window. The output is the executed runbook with timestamps and a list of any URLs that still return errors.
Decommission BigCommerce after retention
Keep the BigCommerce store and an archived export for a retention period set by your legal, tax and finance requirements, and confirm the period with them in writing before the cutover. After that period, cancel the subscription, revoke API credentials and remove any stored exports from shared locations. The output is a retired-system record that names the archive location, the date access ended and the person who approved the closure.
What running Medusa yourself requires
Running Medusa yourself means operating more than a storefront. A self-hosted deployment needs a PostgreSQL database and a Redis database, plus two Medusa instances: one in server mode, which serves the API and admin dashboard, and one in worker mode, which handles background tasks. Each instance needs database credentials along with COOKIE_SECRET and JWT_SECRET values, so your secrets management process has to cover both. Before you choose this path, confirm with your platform team who will provision, patch and monitor these four components, and how each one will be backed up and restored.
Production settings differ from local development. Medusa's production setup replaces the development modules with Redis-based caching, event bus, workflow engine and locking, and stores files in S3, so you will need a Redis service that is shared by the server and worker and an S3 bucket or S3-compatible store with access policies. Database migrations run through a predeploy script before each startup, which means a release can change the schema before the new code runs. Plan a rollback path and a database backup taken immediately before every deployment, and test both in a staging environment that mirrors production.
Check each deployment through the /health endpoint on the server, and wire that check into your monitoring and load balancer health probes. If you prefer not to operate this footprint, Medusa is also available as Medusa Cloud, a managed hosting option from the same project. Ask the vendor which infrastructure, backups and upgrade windows that option includes, and compare the answer with the in-house staffing, on-call and infrastructure costs of the self-hosted route before you commit to either one. The Medusa deployment documentation lists the current production requirements and should be your reference for the final setup.
How the move differs by catalog size and team capability
A small catalog with a single developer usually means a few hundred products at most, a handful of variants per product and limited custom fields. Extraction can often be scripted against the Catalog API in one pass, and the main effort shifts to building a Medusa storefront that the developer can maintain alongside the backend. Because the team is small, the decision on whether to self-host the Medusa server, worker, PostgreSQL and Redis, or use Medusa Cloud, matters more than it would for a larger team.
- Extraction: a short script that reads products, variants and images through the Catalog API, checked against plan rate limits before the run.
- Mapping: a simple mapping of BigCommerce fields to Medusa product, variant and price data, with few exceptions to document.
- Storefront: one storefront codebase, often built on a starter, with the developer owning checkout and templates.
- Operations: one person handling database migrations on each deploy, secrets, backups and upgrades, which is a recurring load even at small scale.
- Hosting choice: self-hosting versus Medusa Cloud, weighed against the team's capacity to run PostgreSQL, Redis and two Medusa instances.
Before scoping, confirm your BigCommerce plan's API rate limits, the number of products and variants you actually need to move, and the Medusa release you will deploy against.",
A mid-size catalog with several custom fields and bulk pricing rules needs more deliberate mapping. Custom fields and metafields in BigCommerce have to be assigned to Medusa product or variant data in a documented way, and bulk pricing rules must be translated into Medusa price lists or equivalent pricing logic, which is often where the migration takes the most design time. Extraction runs in batches across more requests, so rate limits and retry handling need to be built into the script rather than added later.
- Extraction: paginated, retry-aware pulls of products, variants, images and custom fields, logged so partial runs can resume.
- Mapping: a written field map covering each custom field, every bulk pricing tier and category or brand relationships.
- Verification: sample comparisons of prices and variant options between the two stores before cutover.
- Storefront: more templates, filters and category pages to rebuild, with URL structure carried into redirects.
- Team: usually a developer plus an application owner who signs off on pricing and catalog rules.
Before scoping, list every custom field and bulk pricing rule in use, and confirm the Catalog API endpoints and rate limits that apply to your plan. Ask the implementation partner how they will test pricing parity.",
A large catalog with multiple currencies, customer-group pricing or B2B terms changes the scope from a data move into a commerce design project. Pricing, tax, currency and customer-group rules need to be modeled in Medusa's pricing and region concepts before any data is loaded, and the extraction must cover large volumes within the API limits of your BigCommerce plan. Orders, customers and B2B account data also have to be reconciled, and the storefront or B2B portal usually needs custom work.
- Extraction: a longer, staged export across catalog, price lists and customer groups, planned around rate limits and time windows for parallel jobs.
- Mapping: explicit rules for currencies, regions, tax and customer-group pricing, reviewed by finance and sales owners.
- Storefront and B2B: custom components for account-specific pricing, quotes or approvals, built on Medusa modules and the storefront framework you choose.
- Operations: higher availability needs, a tested rollback and a predeploy migration plan for each release.
- Governance: change control, access roles and records that compliance or audit teams may ask for.
Before scoping, confirm which Medusa features you need, including whether any Enterprise Edition role-based access controls require a commercial agreement with MedusaJS, Inc., and confirm the release you will run.
What usually goes wrong in a BigCommerce to Medusa move
Most failed storefront migrations break at the edges: data that stopped flowing, URLs that changed without redirects, and a self-hosted stack nobody owns after launch. The cards below cover the failures we see most often in this kind of move, with a prevention step for each.
Extraction stalls on rate limits
Pulling a full catalog through the Catalog API counts against the rate limits set by your BigCommerce plan. A script that does not back off or resume will stop partway through, leaving half the variants and images in a state no one tracks. Build the extractor to page through products, write checkpoints, retry on throttling responses, and log every record it could not fetch. Run a full dry extraction and compare record counts against the admin before you plan the cutover.
Image URLs lost at switch-off
Product images are usually served from BigCommerce-hosted URLs. When the store is switched off or the plan lapses, those links can stop resolving, and the new Medusa storefront shows empty product pages. Download every image into your S3-compatible file storage before cutover, keep the original filenames or a mapping table, and rewrite image references in the Medusa product records. Check a sample of image URLs from the new storefront after the final import.
Custom field and bulk pricing mismatches
BigCommerce custom fields, metafields and bulk pricing rules do not map one to one onto Medusa's product and price models. Tiered prices can be flattened, dropped or attached to the wrong currency or customer group. Write a field-by-field mapping document before coding, decide where each custom field lives in Medusa, and verify sample products in the new store against the old price tiers for each currency and customer group.
Customer password handling
BigCommerce does not export customer password hashes in a form you can reuse directly, so customers may be unable to sign in after the move. Plan the path before launch: either send a password reset flow to every migrated account, or confirm with BigCommerce and your identity design exactly what credential data can be carried over. Test a login for each customer type, including guest-to-account conversions, in a staging environment first.
Missing 301 redirects
Every product, category and brand URL that changes without a permanent redirect hands search engines a 404 and passes no ranking signals to the new address. Export the full list of indexed URLs from your analytics and search console, map each old path to its Medusa equivalent, and load the redirects at the web server or CDN before DNS changes. Crawl both the old and new sites after launch and review the 404 report weekly for the first months.
Unnoticed app functions
BigCommerce apps often do quiet work: tax calculation, shipping rules, reviews, loyalty points, email triggers or ERP sync. Nobody lists them because they never appear on a product page. Inventory every installed app and every webhook or scheduled integration, record what each one does and who depends on it, and assign an owner for each replacement, whether a Medusa module, a plugin or a third-party service. Do not switch off the BigCommerce store until that inventory is signed off.
Unpatched self-hosted stack
Once Medusa runs in your environment, you own the server and worker instances, PostgreSQL, Redis, the storefront build and the dependency tree. Security fixes, Node.js updates and framework upgrades will not arrive on their own. Assign a named owner, subscribe to Medusa release notes, schedule patch windows, and run migrations through the predeploy process on staging before each production upgrade. Confirm who is accountable for each layer in writing before launch.
What drives the cost and duration of the migration
This table lists the factors that move the cost and schedule of a BigCommerce to Medusa migration, why each one matters, and how to keep it manageable. Use it to scope your own store before asking for a quote, and to check that each driver is priced in the written scope.
| Driver | Why it changes cost or effort | How to keep it down, and what to ask for in a quote |
|---|---|---|
| Catalog size and variant count | Every product, variant and image must be extracted through the Catalog API within plan rate limits, transformed and loaded into Medusa product and variant records. Large catalogs with many option combinations lengthen extraction and validation. | Trim discontinued SKUs before extraction and confirm the variant count. Ask the quote to state the product, variant and image totals it covers and how rate-limited extraction is scheduled. |
| Custom fields and metafields | Each BigCommerce custom field or metafield needs a mapping decision: a Medusa product field, metadata entry, or a custom module. Undocumented fields usually need a review with the merchant team. | Inventory every field in the Catalog API and in the admin before work starts. Ask for a field-by-field mapping table as a written deliverable. |
| Bulk pricing rules | BigCommerce bulk pricing and price lists must be re-expressed through Medusa pricing modules and price rules. Tiered rules across customer groups or currencies add modelling and testing work. | List every bulk pricing rule, customer group and currency. Ask the quote to name how each rule is tested against live BigCommerce prices before cutover. |
| Storefront design scope | A Medusa store has no built-in theme, so the storefront is built from scratch or from a starter. Page count, templates, navigation depth and custom components drive build time more than any other front-end factor. | Reuse existing design assets and limit the first release to core templates. Ask for the page templates, components and responsive breakpoints included in the fixed scope. |
| Payment and tax integrations | Each gateway and tax service needs a connection, sandbox testing, webhook handling and reconciliation of orders. Regional tax rules add configuration and verification steps. | Name the gateways and tax services in use and confirm which ones have Medusa modules. Ask the quote to list the sandbox tests and reconciliation checks included. |
| SEO URL count | Every product, category and content URL that ranks needs a redirect plan to the new paths. Large URL sets require mapping, testing and crawl review after launch. | Export the full URL list from the live store and decide which URLs keep their paths. Ask for the redirect map, the crawl test and the post-launch monitoring period as defined deliverables. |
| B2B requirements | Company accounts, negotiated prices, quotes, approval flows and customer-specific catalogs are not standard storefront features. Medusa B2B capabilities depend on the modules and extensions chosen, so custom work can grow quickly. | Separate B2B features from the launch scope and phase them. Confirm with the vendor which B2B functions your Medusa version supports, and ask the quote to name each B2B workflow it builds. |
| Hosting model: self-hosted or Medusa Cloud | Self-hosting means provisioning PostgreSQL, Redis, S3 storage and two Medusa instances (server and worker), plus monitoring and backups. Medusa Cloud shifts infrastructure operation to a managed service under its own terms. | Compare the infrastructure work of each option against your team's skills. Ask the quote to separate one-time setup from recurring hosting, and to state who operates the server, worker and databases after launch. |
| Ongoing upgrades and support | Medusa releases new versions, and the database migrations run through a predeploy script before each startup. Each upgrade needs a staging test, a backup and a rollback plan, and this effort recurs for the life of the store. | Pin a supported version, test upgrades in staging, and keep a tested backup. Ask whether upgrades, security patches and support hours are included in the migration fee or sold as a separate retainer. |
Questions buyers ask before moving from BigCommerce to Medusa
What drives the cost of moving from BigCommerce to a self-hosted Medusa store?
The biggest drivers are the size and shape of the catalog, how many custom fields and bulk pricing rules must be remapped, how many BigCommerce apps your store depends on, and how much of the storefront must be rebuilt. Costs fall into one-time work (extraction, data mapping, storefront build, testing, cutover) and recurring work (hosting for PostgreSQL, Redis, the server and worker instances, storage, payment and search services, upgrades and support). Ask any quote to split these two groups and to show who is paid for each component, including whether storefront design is in scope.
How long does a BigCommerce to Medusa migration usually take?
Duration depends on the same drivers as cost: catalog size, custom data, integrations, storefront complexity and how many environments must be verified before cutover. No duration is set by this page, so ask for a phased timeline in the written scope with a named milestone for each phase: extraction, data import, storefront build, testing and go-live. A fixed-scope engagement agrees these phases, deliverables and dates in writing before work starts.
What must our team provide before the migration starts?
Expect to supply API credentials for the BigCommerce store with read access to the Catalog API, a current export of products, customers and orders, a list of installed apps and integrations, the payment and shipping providers in use, and the URL structure of the live site. You also need someone who can approve data mapping decisions, such as how custom fields and metafields become Medusa attributes or metadata. Confirm the exact access and approvals in the written scope, since they vary with each store.
Can our internal team migrate to Medusa without an implementation partner?
An internal team can do it if it has engineers comfortable with Node.js, TypeScript and PostgreSQL, and if it can run a Medusa server and worker, Redis, S3-compatible file storage and a storefront build. The main risk is underestimating the one-time work: extracting the catalog within BigCommerce rate limits, mapping variants and customers, and testing the storefront against live data. Weigh that against the team's capacity for ongoing operations and upgrades. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope.
What data moves cleanly from BigCommerce to Medusa, and what needs rework?
Core product records, categories, variants and images can usually be extracted through the Catalog API, which manages products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields. Customers and orders need separate extraction and mapping, and historical order data often needs a decision about how much to import. Items that depend on BigCommerce apps, checkout customizations or theme-specific logic will need rebuilding rather than copying. Ask for a field-by-field mapping document before any import runs.
How do we protect SEO and existing URLs during the move?
Protect SEO by inventorying every indexed URL from the live BigCommerce store, mapping each one to its Medusa storefront route, and setting up permanent redirects for any path that changes. Keep the original store live until the new store has its data and redirects verified, following the same caution Shopify advises for image imports from public URLs. Also plan for product image URLs, canonical tags, sitemaps and structured data. Confirm the redirect plan and crawl checks as named deliverables in the written scope.
Does the Medusa license create costs for us, and which features need a commercial agreement?
The core Medusa commerce framework is MIT licensed, so running it does not require a license fee. Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc. If your store needs granular admin permissions, confirm early whether those features are in your requirements, because they change the licensing line in your total cost. Medusa is also available as Medusa Cloud managed hosting, which is a different cost model from self-hosting.
Primary sources for the Medusa and BigCommerce migration
Before you scope this migration, confirm the Medusa features, versions and deployment requirements you plan to rely on directly from the vendor's own sources, because those details change between releases. Start with the Medusa repository to confirm the license split. The core commerce framework is MIT licensed, while Enterprise Edition features based on role-based access control need a commercial agreement with MedusaJS, Inc. If your team expects RBAC for store staff, put that requirement in writing and check it against the edition terms before you commit to a design. The repository also shows which modules ship for carts, orders, product catalogs, pricing and inventory, which tells you how much of your catalog model maps to stock Medusa modules and how much needs custom work.
The Medusa releases page is where you confirm the exact version you will pin and the changelog entries that touch product, variant or pricing data. The release history is also the place to check breaking changes before an upgrade, since a migration script written against one version may need changes on the next. Pair that with the Medusa general deployment docs, which set out the components your environment must provide: a PostgreSQL database, a Redis database, a server instance for the API and admin dashboard, and a worker instance for background tasks. Ask your platform team to confirm the required environment variables, including the database credentials and the secrets used for cookies and JWTs, and how the /health endpoint is used in your deployment checks. These items drive your hosting and operations estimate more than any feature list does.
For the source side, read the BigCommerce Catalog products API documentation before you write any extraction code. Confirm the endpoints for variants, images, custom fields and bulk pricing rules, and confirm the rate limits that apply to your store's plan, since those limits set how long a full catalog pull takes. Treat any throughput figure you find in a blog post as unverified until your own test run confirms it. Ask BigCommerce or your partner to confirm which data is only reachable through the API and not through CSV exports. Those answers decide your extraction schedule, your cutover window and whether you can keep the old store running in parallel while you verify the new data.
How DeployOpen scopes, runs and supports the Medusa migration
DeployOpen plans and delivers the BigCommerce to Medusa move as a fixed-scope engagement inside your own cloud accounts or data centers. The written scope sets out the catalog extraction, the Medusa deployment, the storefront rebuild and the redirect plan before any build work starts.
How we scope
- Inventory the BigCommerce catalog, customer and order data, custom fields and installed apps before any extraction begins.
- Agree in writing which products, variants, images, customers and historical orders move, and which stay on BigCommerce.
- Define the Medusa target architecture, including PostgreSQL, Redis, S3 file storage and the separate server and worker instances.
How we build
- Write Catalog API extraction scripts that respect the rate limits of your BigCommerce plan and resume safely after interruptions.
- Map variants, bulk pricing rules and custom fields to Medusa product, price and metadata structures, then test the mapping on sample data.
- Configure the Medusa deployment with the predeploy migration step, the health check endpoint and secrets managed outside source code.
How we hand over
- Deliver a redirect map from every BigCommerce URL to its new Medusa storefront route, tested before the DNS cutover.
- Document the deployment, data mapping, runbooks and rollback steps so your own team can operate the store after handover.
- Provide a cutover checklist covering catalog, customer, order and redirect validation, with each check recorded as evidence.
How we support
- Run upgrades to new Medusa releases in a staging copy of your store first, with the migration steps tested before production.
- Back up the PostgreSQL database and file storage on a schedule agreed in the written scope, with restore tests documented.
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live, scoped separately from the migration.
