Migrating to Shopify from Miva

Product catalog and variants, product attributes and attribute templates, category tree, images, custom fields, price groups, customer records and business accounts, a prioritized window of order history, pages and blog content, navigation, and available SEO metadata. Exact fields and record counts are confirmed in Discovery and documented in the SOW.

Through Miva’s export modules, the JSON API and Provisioning API, and direct database extraction where the catalog structure warrants it. Miva stores a lot of business logic in custom fields and attribute templates that a standard product export flattens or drops, so we extract those deliberately rather than relying on a single CSV.

Simple attributes that drive SKU-level inventory map to Shopify variants. Attributes that add cost or configuration without generating a SKU (text personalization, upcharges, swatch selections, checkbox add-ons) map to metafields, metaobjects and theme logic, with a line-item property or custom app where the attribute needs to reach the order. Attribute templates that are shared across a family become reusable metaobject definitions.

It will, but not by mapping one-to-one. Shopify’s variant model has limits Miva’s attribute system doesn’t, so deep option trees are modeled as a metaobject-driven configurator on the product page rather than as thousands of variants. We prototype the most complex product family during Discovery so you see the behavior before scope is locked, not after.

Miva kits and grouped products map to Shopify bundles through native bundle functionality, Shopify Functions, or a vetted bundling app depending on how inventory needs to decrement. Made-to-order and build-to-spec flows are scoped individually. They’re usually the most business-critical logic in a Miva store, so they get prototyped early.

Customer-specific and dealer price groups map to Shopify Plus B2B Companies, Catalogs and price lists. Quantity break and volume pricing is handled with native B2B quantity rules or Shopify Functions. Availability groups, Miva’s mechanism for hiding products from certain customers, map to B2B catalog visibility.

Yes. Miva business accounts map to Shopify Plus B2B Companies with Locations and assigned contacts, so a dealer’s buyers land in the right account with the right catalog and terms. Manual dealer approval gates, net terms and role-based access are implemented within the agreed scope and documented in Discovery.

This is the highest-risk part of a Miva migration and we treat it that way. Miva sites typically carry a mix of merchant.mvc?Screen=PROD&Product_Code= query-string URLs and SEO short links, sometimes both pointing at the same product. We crawl and map every URL earning traffic or holding links, then implement a 301 plan covering both patterns, plus pre-launch and post-launch crawls to remediate 404s and confirm canonicals.

Product, category, customer and order custom fields map to Shopify metafields with defined types and, where they need to be editable structures rather than single values, to metaobjects. This matters more on Miva than most platforms, because custom fields are usually where spec data, fitment information and internal operational flags live.

Customer records migrate. Miva password hashes aren’t portable to Shopify, so we migrate accounts and trigger a secure password reset or login invitation flow. For B2B stores, we sequence that communication carefully so dealers aren’t locked out mid-order-cycle.

Order migration is scoped in Discovery. Clients commonly choose a rolling 12–24 month window, though longer ranges are supported. We plan for order number preservation, tax and accounting reconciliation, and returns mapping to avoid downstream operational issues.

MivaScript modules and .mvc customizations don’t transfer. We inventory them in Discovery and follow a native-first approach: Shopify native features or vetted Plus apps where they provide parity, custom Shopify apps where a genuine capability gap exists. A meaningful share of Miva custom code turns out to be solving problems Shopify handles natively.

The storefront is rebuilt as a Shopify Online Store 2.0 theme carrying your brand and UX rather than cloned template-for-template from MVT. Your merchandising team gains section-based editing without touching code, which for most Miva stores is the largest day-to-day operational change of the whole project.

No. Payment tokens don’t transfer between providers, MivaPay included. Payment methods are reconfigured on Shopify, and for stored-card B2B workflows we plan a re-authorization approach with your gateway. Any subscription or recurring billing is vendor-specific and assessed in Discovery.

Existing Miva integrations are re-pointed at Shopify through middleware, ETL tooling or custom connectors that synchronize inventory, pricing, orders and customer data. Reconciliation, logging and error-handling ownership are documented in the SOW. Miva-specific connectors are replaced with their Shopify equivalents where they exist.

Standard real-time carrier rates, negotiated rates and rules-based shipping map to Shopify’s native shipping configuration and Shopify Plus carrier rate access. Freight, LTL and dimensional-weight logic common in industrial catalogs is scoped explicitly, usually through a shipping app or custom rate endpoint, and confirmed against live quotes during UAT.

Shopify’s checkout is SaaS-managed. Branding, supported configuration and Checkout Extensibility are included; Miva’s template-level checkout modifications are scoped separately and implemented only where Shopify Plus allows extensibility. Unsupported customizations are identified in Discovery, not at UAT.

Timeline depends on catalog size, attribute complexity, B2B requirements and integrations. Straightforward stores migrate in a few months; high-SKU catalogs with deep attribute logic and dealer pricing commonly run longer. Simple replatforms start at mid-five figures, with larger programs requiring custom engineering running higher. Discovery produces a firm timeline and commercial proposal.

Phased delivery: Discovery, Design and Build, QA and UAT, Launch and hypercare. Launch readiness criteria, cutover steps and rollback plans are defined in the SOW. A hypercare window and operational training are included so your team can run the storefront post-launch.

Proprietary MivaScript code that can’t reasonably be replicated, unsupported checkout engine modifications, fully custom theme builds without separate agreement, and large-scale BI or data warehousing projects unless explicitly scoped. Out-of-scope items are documented and managed via Change Order.

Miva admin access or database exports, a list of installed modules and MivaScript customizations, sample product exports covering your most complex attribute templates, your price group and availability group structure, sitemap and analytics access, and a list of third-party systems to integrate.