Hi everyone! It was around two weeks ago that we began the rollout of BigCommerce 7 for new stores. In that time, we’ve received incredible support and feedback from you, which is a testament to the planning, development and overall hard work by our engineering team.
In this post I’ll outline our rollout plan for BigCommerce 7 to existing stores and I’ll explain why we’re staggering the rollout over the next few weeks.
Facts About BigCommerce
- We host well over 10,000 active BigCommerce stores
- Each store varies in the number of products – from 20 to over 100,000
- Each product can have multiple variations (size, colour, style, etc)
- Stores currently range in size, from 0 to over 30 million variation combinations
We needed a plan that allowed us to manage risk every step of the way, but at the same time didn’t want to run a beta release. By staggering the release over time, we’re able to create a predictable upgrade process that upgrades hundreds of stores at a time. It also allows us to start by upgrading stores with fewer variations and then move on to those stores with thousands of variations.
Defining a Successful Rollout
Here’s the success criteria which helped shape the release strategy:
- Product variation data is accurately and automatically migrated to the new product options setup
- BigCommerce infrastructure is minimally impacted
- BigCommerce support is minimally impacted
What We’ve Done So Far
In addition to releasing BigCommerce 7 to new stores, we’ve been testing the upgrade process thoroughly over the last two months across many different use cases and across both simple and complicated product variation data sets. It’s important to remember that we regularly deal with huge data sets, and this is our speciality.
The development cycle for BigCommerce 7 took 18 weeks before it moved to quality assurance. What we plan to do is continue running the quality assurance process during the upgrade period, allowing us to better triage issues and proactively catch any edge cases that may arise. Our motto is to test and QA as effectively as possible, but we also understand that edge cases can and do arise, and so we have to be prepared.
The following diagram represents our approach and commitment to the rollout, ramping up the upgrades to stores with larger variation data sets as time progresses:
Here’s a summary of some of the datasets we used during the quality assurance process to make sure the upgrade process runs as smoothly as possible:
- Test Store A – Zero product combinations
- Test Store B – 10 million product combinations
- Test Store C – 30 million product combinations
- Test Store D – 400,000 product combinations on 1 product
- Test Store E – 300,000 product combinations with SKUs
- Test Store F – 100,000 product combinations for 700 products, all of which have SKUs
The Plan Over the Coming Weeks
- Stage 1 Rollout – Opt-in upgrade for simple stores with no or very few product variations
- Stage 2 Rollout – Opt-in upgrades for stores with hundreds/thousands of product variations
- Continuous QA during the BigCommerce 7 rollout process (in addition to 8 weeks prior QA)
- Preparing the next release of BigCommerce (more enhancements, bug fixes)
So there you have it – a technical explanation showing an insider’s view of how we prepare, stage and rollout a major software upgrade. Over the next few weeks you’ll see a link at the top of your control panel allowing you to schedule an upgrade to BigCommerce 7. Keep in mind that as well as zero impact to your store’s variations, we also aim for zero impact on your store’s template – including customized HTML and CSS.
P.S. For those who are interested, two of our senior software engineers will put together a technical blog post detailing the complexities behind the version 6 to version 7 upgrades in the coming week or two, so stay tuned for that!