Product
Is my BigCommerce store compatible for this migration?
Yes, any V2 store is compatible for this migration. Our app is built to handle complex and high volume catalogs. Additionally, for any rare use cases we can offer a customized solution. Contact us for a free discovery session.
Which V2 catalog elements are migrated?
We migrate products, options, option images, option sets, SKUs, product rules, option set rules and configurable fields. Rest of data like product images, categories, brands, categories, bulk pricing, pricelists, custom fields etc. is retained as is.
Which V2 catalog elements are not migrated?
The below mention rules are not migrated during the migration automatically. Must be handled by the client manually.
- Different image rules applied option set level
- Stop processing rules
- Complex rules (A rule that involves both options with SKUs & options without SKUs to generate a value)
How are V2 option types migrated?
Option types like multiple choice (drop down, radio buttons, rectangles, swatches) and pick lists involved in SKUs generation will be migrated as a Variant Options. If not involved in SKU generation, these are migrated as Modifier Options.
Other options like checkbox, file upload, text fields, etc. are migrated as Modifier Options by default.
Note: If you have different use case, we can customize to support that.
How are product rules migrated?
- Rules (price, weight, different image, and disable purchasing) applied to options with SKUs will be processed to generate a calculated value and applied Variant Option SKUs accordingly.
- Rules (price and weight) applied to options without SKUs will be created as modifier rules and applied to Modifier Options.
- Complex rules, applied to both options with SKUs and without SKUs, will be flagged as exceptions in our reports. They require a manual assessment by the client to determine adjustments for Variant Options vs Modifier Options.
Note: BigCommerce only allows you to create rules for Modifier Options in V3.
How are option set rules migrated?
Rules applied at the option set level are transformed into product rules and are processed to all products linked to the option set with the same logic as product rules.
How are complex rule migrated?
Products using complex rules will be identified upfront as an exception in our reports for your review and to rebuild such products manually to comply with BigCommerce V3.
How are configurable fields migrated?
We delete any existing configurable fields and re-create them as Modifier Option in V3.
Do you provide a report that identifies products that are not compatible with V3?
Yes, we identify any data that is incompatible and guide you through the reconciliation process. Below are a few scenarios that are identified as exceptions:
- Products with unequal SKU options
- Products with potentially 600+ SKUs
- Products with complex rules
- Products with “Stop processing” rules
- Products with “Different image” rules at an option set level
- Products with duplicate option set names
- Products with missing SKUs
Additional audit reports:
- List of option sets and options
- Products, SKUs, and options used to generate SKUs
- Products, rules, and options involved in rules
- Products with configurable fields
How are V2 option (e.g., “add insurance?”) that doesn’t represent a unique physical SKU migrated?
Assuming “Add Insurance” is a checkbox option with no SKU, it will get migrated as a Modifier Option.
How are option sets with more than one option type migrated? (e.g., radio button, drop down, checkbox, pick list)
Assuming the option set is linked to multiple products, all options within the set are created as individual options for applicable product. Options involved in SKU generation are create as Variant Options and rest are created as Modifier Options.
How do you migrate option that are reused by multiple option sets when active option values are a subset of the original option?
Our approach involves identifying the active option values for the option and creating only those values per option for the products linked to the option set. (e.g., Optionset-1 is using the Option: Size with values S,M, L and Optionset-2 is reusing the Option: Size with values S, L then all products associated with Optionset-2 will have the Size option only with S, L as values)
Do you migrate rules applied to the options without SKUs?
Yes, rules (price & weight) applied to options without SKUs will get created as Modifier rules.
Assumption: Options without SKUs need to be migrated as Modifier Options.
Can you migrate a product that uses an unequal number of options to generate a SKU? (e.g., SKU1: color, size, SKU2: color, SKU3: size)
No, we identify this product as an exception in our reports. BigCommerce V3 expects all your Variant Options to participate in the SKU generation, hence this product setup is not compatible with V3.
You can rebuild this product pre/post migration.
Can you migrate option without SKU as Variant Option?
No. V3 requires you to have a SKU created for all options that need to be migrated as Variant Option. If you do not have SKUs, we will identify this products with such options as exception in our reports.
Can you migrate products with 600+ SKUs?
In BigCommerce V3, you must create explicit SKUs (i.e., variant options). BigCommerce allows you to create a maximum of 600 SKUs. V2 did not have the restriction as it did not require you to create explicit SKUs. Our app reports which of your V2 products have 600+ options so you can rebuild them manually in V3 to comply with the 600 variants limit.
Can you migrate V2 options as Shared Variants or Shared Modifiers?
No, it’s not possible to migrate V2 options as Shared Variants or Shared Modifiers. All options will be created as individual options on the products.
Can you migrate customers, orders, themes, etc.?
No. Considering that the app is used to upgrade products to V3 experience in the same store, it does not migrate customers, orders, themes, etc. If you want to migrate your catalog to a separate V3 store, you will then need to migrate customers, orders, themes, etc. Please contact Our professional services team at [email protected] to help you.
Can you transfer my V2 catalog to a separate V3 or MSF (Multi-Storefront) store?
Yes. Please contact Our professional services team at [email protected] to help you.
Pricing
Do I have to sign an ongoing subscription or services contract to migrate to V3?
No, we charge a one-time fee for the migration.
Process
How does this migration work?
It is a white-glove, 5 step app-enabled service to automate the migration of your BigCommerce V2 store to V3. Our team will operate the migration, and engage you if we identify any exception products that needs your attention.
- Step 1: Migrate products to V3 sandbox for review and identify product exceptions (no downtime required)
- Step 2: Convert option set rules to product rules
- Step 3: Unlink option sets if applicable (options, SKUs, rules) and delete configurable fields from the V2 main store
- Step 4: Update current V2 user interface to V3 Experience
- Step 5: Rebuild V2 products, options, SKUs, and rules in V3 formats
What do I need to do during the migration?
- Step 1: Preview results, address product exceptions (if any), and provide an approval to proceed further
- Step 2 to Step 5: Backup your V2 store, and enable maintenance mode
How long does the overall migration process take?
Most upgrades complete the same day. However, some projects may take between 2-5 days depending on the clients time zones, availability , and review/approval process.
How long will my store be down for?
Depending on your catalog size, the store downtime could be 15 minutes to a few hours. Our team will share the estimated downtime before hand.
Can I schedule this migration according to my business needs?
Yes, absolutely. You can schedule this migration anytime, our teams are available 24/7.
Can I preview the migration results upfront?
Yes, you can preview and audit the results in a V3 sandbox as a first step. We convert your V2 catalog to V3 formats and transfer it to a V3 sandbox only for your audit & review. You can audit products, variant options, variants SKUs, variant images, modifier options, and modifier rules. Additionally, you can install your theme pack in the sandbox store to view V3 products on the front-end.
Can I preview custom fields in the sandbox store?
No. As we retain the custom fields as is during the migration, we do not sync them over to V3 sandbox for review.
When migrating products from V2 to V3, do you retain the same Product ID?
Yes. your product IDs are retained. However, your SKU IDs (system created) will be regenerated as we are deleting V2 options/SKUs and recreating them in V3 formats.
Do you provide a report that contains my old option IDs vs new option IDs?
We will provide the V2 product export and the V3 product export. You can easily compare the old IDs vs new using Vlookup.
Will my category URLs or product URLs change during the migration?
No, we do not make any changes to the URLs.
Is it required to put my store in maintenance mode during migration?
Yes, we recommend you put your store in maintenance mode during the migration to minimize the risk of data loss or corruption, avoid customer interactions on products with missing data, and ensure that the migration is performed accurately and efficiently.
Once I address the product exceptions after Step 1, do I have to restart the process?
Yes, we will rerun Step 1 to make sure there are no product exceptions.
Do we need to contact BigCommerce support during the migration?
Hopefully not. In some cases, BigCommerce database can have some abandoned IDs that needs to be flushed out and due to which the prompt required to update the UI to V3 experience does not show up. As BigCommerce is aware of this issue, they clean this quickly to make the upgrade.
After migrating to the V3 product experience, can I switch back to V2 again?
You will need to reach out to BigCommerce Support for this request.
Do I need to disable Google Shopping in order to upgrade to BigCommerce V3?
No, disabling Google Shopping is no longer a prerequisite for upgrading your store to BigCommerce V3.
For how long will StrikeTru hold on to V2 store data?
Your product data will be stored for a period of 1 month in JSON formats.
Other
Why should I migrate my BigCommerce products from V2 to V3 experience?
Here is why you should migrate from V2 to V3:
- Modernizing Tech Stack: Merchants implementing new systems (ERP, OMS, PIM, Marketplace Listing Tools like Feedonomics and ChannelAdvisor, etc.) want to avoid integrating those systems with BigCommerce APIs twice, once with V2 and then later with V3.
- Migrating to MSF: Merchants consolidating V2 store(s) to multi-storefront that requires V3 product experience.
- Adding New Store(s): New stores come with V3 only. Merchants may want to upgrade existing V2 stores to standardize all store product experiences for efficiency.
- Better Features: For faster APIs, metafield visibility, ability to attach options and modifiers directly to products (i.e., no need to create Option Sets thus simplifying new product setups), new V3 only API resources like Cart API, Payments API, & Widgets.
- Migrate before V2 support ends: Merchants want to migrate to V3 now and not be caught by surprise if BigCommerce sunsets V2. That may happen eventually.
- Skills / Knowhow: Hiring talent that is familiar with V2 to maintain BC stores may become more difficult. If you’re referring to just the V3 UI layout vs V2 UI layout, I guess it is what it is. I know it takes fewer clicks to set up a product in V3 UI compared with V2.
Will V2 be deprecated in the future?
As far as we know, BigCommerce has not set any date to sunset V2. However, they are actively encouraging merchants to migrate to V3.
