Nobody replatforms because they're bored. They replatform because something has become intolerable. A checkout that drops 8% of sessions. A dev shop that quoted six weeks for a shipping rule change. A Magento 2 instance whose hosting bill is bigger than the marketing budget. A homegrown Rails app that only one person understands, and that person just gave notice.

We've been a BigCommerce-only shop for over twelve years, and migrations are a big chunk of what we do. The pattern is consistent: the technical work is rarely what sinks a replatform. What sinks it is the stuff nobody scoped. Product data that turns out to live in three systems. 40,000 URLs with no mapping strategy. An ERP integration that everyone assumed was an "API thing" and turns out to be a nightly CSV dropped on an FTP server by a script written in 2014.

This is the playbook we run. It's written for the person who has to defend the project internally, not for the developer who'll implement it.

First, be honest about why you're moving

Before scoping anything, write down the three things that must be measurably better after launch. Not "modernize our stack." Real things: mobile conversion rate, time to publish a new landing page, cost per order, hours your ops team spends on manual order entry.

This matters because it's the only defense against scope creep. Halfway through every migration, someone asks for a feature that has nothing to do with why you started. If your three reasons are written down and agreed to, that request becomes a phase two item instead of a two-week delay.

A few reasons that hold up well:

• Total cost of ownership. Moving off self-hosted open source to SaaS usually eliminates hosting, PCI scope, patching, and a category of emergency you currently budget for.
• Speed of change. If your merchandising team can't launch a promotion without a developer, that's a revenue tax, and it compounds.
• B2B and wholesale requirements. Company accounts, customer-specific price lists, quotes, and punchout integrations are dramatically cheaper to deliver on BigCommerce B2B Edition than to build from scratch.
• Multi-brand or multi-region. Multi-Storefront lets you run several storefronts against one catalog and one admin, which is a structurally different cost curve than maintaining separate installs.

Reasons that don't hold up: a competitor did it, the platform looks dated in the admin, or a salesperson showed you a nice demo.

The four phases

Most mid-market migrations we run break into four phases. The shape is more useful than the calendar, because the calendar depends entirely on your catalog complexity and integration count.

Discovery is where the money is saved. This is the phase merchants want to compress and the one you should protect. In discovery you inventory every integration, export a real sample of your product data, pull your top 500 URLs by organic traffic, and identify every business rule that lives in someone's head. The output should be a written scope that a stranger could implement.

The single best predictor of a migration going sideways is a discovery phase that got skipped to hit a launch date.

Build runs in parallel tracks. Theme and front end, data migration, integrations, and content. These have different dependencies, and the mistake is sequencing them. Data can start loading into a sandbox store while design is still in review.

UAT is not a demo. It's your team placing real orders with real payment methods, your warehouse pulling those orders into the ERP, your accountant reconciling them, and your customer service rep processing a return. If nobody outside the project team has touched the site before launch, you have not tested it.

Launch is a DNS change and a redirect file. By the time you get here, it should be boring. If launch week feels dramatic, something got skipped in UAT.

Your data will not move cleanly, and that's fine

This is the conversation we have on every project, so let's have it here. Migration tools and CSV imports handle a lot. They do not handle everything, and the gaps are predictable.

Products, categories, and customers move well. BigCommerce's catalog imports and V3 APIs are good. Where it gets interesting is variant structure. If your current platform models variants as separate SKUs and you want real variant options on BigCommerce, that's a data transformation project, not an import. Same story with configurable products, bundles, and anything with dependent option logic.

Order history imports, but it isn't your old order history. You can bring historical orders in through the API so customer service has context and customers see their past purchases. Those records won't support refunds, captures, or reprocessing against the original payment transaction. Plan to keep read access to your old system for a while. Most merchants keep the legacy database available for a year.

Customer passwords do not transfer. They're hashed with a different algorithm, and no honest migration path exists. Your customers will need to reset. This is a communications task, not a technical one, and it's worth real attention: a well-timed email sequence explaining the new site and walking people through a one-click reset protects a surprising amount of repeat revenue. Skipping it produces a support queue.

Reviews, coupons, and CMS content need decisions, not imports. Reviews can usually be brought over or handled by whichever review app you're using. Coupons are almost always worth rebuilding, since promotion logic differs between platforms and stale codes are a liability. Blog and content pages are a judgment call: migrate what earns traffic, archive the rest with redirects.

The practical move here is to treat data migration as a series of dry runs. Load, validate, fix the mapping, reload. We typically do three full passes before UAT, with the last one running the day before launch to capture new orders and customers.

SEO is the risk that shows up 30 days late

Here's the thing about replatforming SEO damage: you don't feel it on launch day. You feel it four to six weeks later when a quarter of your organic traffic is gone and nobody can point to the cause. By then the diagnosis is expensive.

The fix is unglamorous. You need a URL map.

Pull every URL that has ever earned a click. Your sitemap, Search Console's full performance export, your analytics, your backlink profile. Deduplicate, then sort by value. Every one of those URLs needs a destination on the new site, and every destination needs to be a single 301 to a live page that returns a 200.

Two failure modes cause most of the damage:

• Redirect chains. Old URL redirects to an interim URL which redirects again. Each hop leaks authority and slows the crawl. Map old directly to final.
• Redirects to category or home. Sending a discontinued product to your homepage tells Google that page is gone and its equity should evaporate. Send it to the closest live product or a relevant category, and if nothing fits, let it 404 deliberately rather than soft-404 into the homepage.

BigCommerce handles this well once you have the map. You can bulk import redirects by CSV or push them through the Redirects API, which is what we do for anything over a few thousand rows. On Multi-Storefront, redirects are managed per storefront, which is a detail worth catching in planning rather than during launch week.

The other half of the job is preserving on-page signals: title tags, meta descriptions, structured data, canonical logic, and your heading hierarchy. Export it all before you start. It's much easier to carry forward existing metadata than to regenerate it, and pattern-based rules in your theme will cover the long tail.

Then benchmark. Capture your Core Web Vitals, indexed page count, and organic sessions by template type in the two weeks before launch, so that if something does move you can tell the difference between a migration problem and a Google update.

Integrations are what actually blow up scope

Catalog and theme work is estimable. Integrations are where projects go over, and it's almost always for the same reason: the integration everyone described as simple turns out to be carrying business logic nobody documented.

Ask these questions about every system that touches your store:

1. What data moves, in which direction, and how often?
2. Is it real time or batched? If batched, what happens when a batch fails?
3. Who owns the mapping between your systems' identifiers?
4. Is there a modern API, or is this file drops and screen scraping?
5. What business rules live inside this integration rather than in either system?

That last one is the killer. Tax logic, shipping rules, customer tiering, and inventory allocation rules have a habit of living inside middleware, and they surface at UAT when a rep says "that price is wrong" and can't explain why.

Our recommendation: for standard needs, use the marketplace. BigCommerce's app ecosystem covers ERP connectors, tax, shipping, reviews, subscriptions, and search well enough that building custom is usually the wrong call. Reserve custom development for the things that are genuinely specific to how your business makes money. That's where it pays for itself.

For B2B specifically, this is where BigCommerce has gotten notably strong. Company accounts with buyer hierarchies, customer-specific price lists, quoting, and punchout catalog integrations to procurement systems like BirchStreet, Coupa, and Ariba are all achievable without a bespoke portal. If you're a distributor or manufacturer currently maintaining a custom-built ordering portal, that's the comparison worth running.

Stencil or Catalyst

The front end question comes up on every project, so here's our straight answer.

Choose Stencil if your storefront needs are conventional, your team wants a well-understood theme layer, and speed to launch matters more than front-end flexibility. It's mature, the ecosystem is deep, and most merchants are well served by it. There is no shame in a fast, clean, conventional storefront.

Choose Catalyst if you have real front-end ambitions and either in-house React capability or a partner committed for the long haul. It's BigCommerce's Next.js and React framework running on the GraphQL Storefront API, with Makeswift for visual editing. The performance ceiling is higher and the composability is real. The tradeoff is that you now own a front-end application, with the maintenance and hosting decisions that come with it.

The mistake we see is picking headless for reasons that are actually about the theme, not the architecture. If the real complaint is "our site looks dated," that's a design project. Headless solves a different problem, and it solves it at a higher operating cost.

How to scope it so it doesn't slip

Three things do most of the work here.

Fix the scope in writing before anyone builds. Fixed-bid, milestone-based structure aligns everyone: you know what launch costs, and your partner has every incentive to be precise in discovery rather than discovering revenue later. Ambiguity is what gets expensive.

Name one decision maker. Migrations generate dozens of small judgment calls a week. If each one needs a committee, the calendar becomes fiction. One person with authority, one weekly review with everyone else.

Freeze the old site's roadmap. Every change to the current site during a migration is a change that has to be reimplemented and retested. Announce a freeze on new features and non-critical content, and hold it.

And set the launch date deliberately. Not during your peak season, not the week before a trade show, and not the Friday before a holiday. Tuesday morning is boring, and boring is the objective.

What good looks like 90 days out

If the migration worked, here's what you should be able to say three months later:

Organic traffic is at or above pre-launch levels. Conversion rate is up, most visibly on mobile. Your merchandising team has shipped several campaigns without filing a dev ticket. Your ops team is spending less time on manual order handling than before. And you have a written list of phase two items, because the good ideas that surfaced during the project got captured rather than jammed into scope.

That last point is the sign of a healthy project. A replatform isn't the finish line, it's the point where improving your store stops being expensive.

Thinking about a move to BigCommerce? We've spent over twelve years doing nothing but BigCommerce, and migrations off Magento, Shopify Plus, NetSuite SuiteCommerce, WooCommerce, and custom-built platforms are a good share of that work. If you want a candid read on scope, timeline, and what your specific data and integrations will actually require, book a time and we'll walk through it with you.