TIL Thursday: Migrating from SiteBuilder to SuiteCommerce Advanced

So we've covered migrating between SCA releases and from pre-Denali to Mont Blanc, so here's the big one. This time around, we're talking about migrating from SiteBuilder to SCA.

Making this move is probably the most drastic overhaul you can make to your web store. It represents a complete change in software while still wishing to maintain so many of the elements associated with your brand, web store and item data.

For such a daunting task, one of our customers engaged Intente to take them through this journey. To find out more, I joined Kerrie Kennedy, president and creative director to find out how it went.


SG: Hi there. First things first — what site did you migrate?

Intente: DiscTech. They serve consumers and commercial customers with an assortment of over 8,000 technology parts and components including hard drives, server components and networking equipment. Purchases made from the web store are typically time-sensitive as items are available for same day shipment.

DiscTech has been a long-term NetSuite customer and had a reliable SiteBuilder web store for over 10 years. However, it had a dated look, was text heavy and, given the number of items in the assortment, had grown difficult to shop. Given the web store serves both consumer and commercial customers, making the web store more visually appealing and easier to shop was an overarching objective of the project.

How did you prepare for the migration?

We have a straightforward approach we call 'Define/Design', which is followed by 'Develop/Deliver'.

In the define phase we gather information to understand the client’s industry, audience and products. We also look at their specific web store goals and functional requirements, including the use of out-of-the-box NetSuite features as well as any desired customizations. The readiness of NetSuite backend configurations is assessed (ie, categories, items, facets and search fields).

The deliverable of this phase is a document that identifies the web store's features and functions that need to be designed and developed, along with backend issues that must be addressed. This document is known by some as a business requirements document (BRD).

Drawing from the information gathered in the define phase, which is focused on determining the look and feel of the site.

Wireframes are the first step in exploring the site’s structural layout and functionality. Then we flesh out complete designs, considering all elements such as logos, branding, color, typography, hierarchies, image direction, messaging and visual rules. The deliverable of this phase is a design document that describes and depicts what the web store will look like when completed.

So, in terms of defining, designing, developing and delivering the site, the whole project lifecycle was about 22 weeks: 6 weeks on the first two phases, and 16 weeks on the other two.

So DiscTech was a mature SiteBuilder site, what did you find out when you began migrating them?

The first thing we noticed was that we needed to change the item images naming convention in SCA. In SiteBuilder, any item image naming convention works as you simply attach item images to item records. In SCA we don't attach item images to item records. Instead, item images are associated to item records automatically using a standardized image naming convention. Therefore, it is important to decide on a naming convention that includes an item identifier.

We also noticed that the switch to SCA has significant SEO implications. URL strings in SCA are very different from SiteBuilder. When creating 301 redirects, you must pay special attention to the creation of maps for 'from' URLs and 'to' URLs — note that that SCA URLs are case sensitive and SiteBuilder URLs are not.

Finally, do not underestimate the time and effort that needs to go into defining and building the item taxonomy that will support faceted search. SiteBuilder clients, who are unaccustomed to thinking about faceted navigation, need to spend the time to think this through. This is a client task: they are closest to the products they sell and the customers they sell to. The client needs to do this work early on in the project.

So what did you do?

First, Intente's design addressed the "more visually appealing" objective. In addition to colors and typography that are easy on the shopper's eye, our use of iconography provides visual cues to aid item category selection.

Our use of progressive reveals on product detail pages (item description, specifications, condition, warranties) reduced the noisy text presented to shoppers while at the same time making the detailed specification available when needed for a technical item's sale.

And last, our use of tooltips with rollover pop-up bubbles helps shoppers understand what a particular web store feature is trying to communicate, but only when the shopper chooses to get more information. The net effect of the design and its application lightened the heavy text burden the SiteBulder web store suffered from.

How did you make it easier to shop?

SCA delivered on two important out-of-the-box features DiscTech knew were important in a current generation web store.

First, they recognized the need to have a mobile friendly web store having seen a significant increase in mobile traffic to their web store.

Second, with a product assortment of 8,000+ technical items, DiscTech needed to give their customers a simpler way to search, narrow and shop the many item available in their product assortment. SCA’s powerful search and faceted navigation helps to guide customers to the products that will meet their specific technical challenge.

You've mentioned item data quite a bit. Knowing what data you're going to work with in advance must be a good thing?

It's a double-edged sword.

The upside to working with an existing SiteBuilder site is that item data is present in the NetSuite inventory management module and is ready to use.

The downside is that over time, small customizations to SiteBuilder were made to expose custom fields and tags to the web store. These fields and tags needed to be reviewed and in some cases removed or updated. Any field or tag that is going to be carried over to the SCA needs to be mapped and exposed in SCA category list pages and product detail pages. This is a time consuming task and requires an understanding of how elements are exposed in an SCA store, and an understanding of how items are configured or customized in the inventory management module of NetSuite.

Here is an image showing an example of how we map item content to an SCA deisgn. Again, this takes time and requires our designer and developer working closely with the client to focus on the details to be exposed.

What are your best practices for handling customizations?

We never modify any files within the suitecommerce module folder. We have our own folder where we place all our files and name space the folders accordingly.

If the customization is to modify or extend existing functionality, for example to add to the context of a view or change the functionality of an existing module, we will create extension files for the JavaScript, and override Sass and template files.

For completely new functionality, we create a new module and with a folder/file structure similar to the other modules but with our new JS/Sass/templates etc.

What did you find challenging?

Getting used to the modular code and how it all fits together is a big challenge. We are coming up the curve working with new framework and understanding NetSuite's logic.

The most difficult challenge is bumping in to a problem and working out whether it is an issue with our code or if it is an underlying bug. The product is still young so there are still some rough edges and dark corners.

So, overall, how would you rate the experience of migrating and developing on SCA?

For Intente's designers and developers, SCA is a giant step ahead in terms of the tools we are using (eg Gulp and Node) to develop and build out a NetSuite web store, particularly using an agile team approach.

Clients like the site management tools, which is built into SCA. What clients will struggle with is learning to use the development tools and how to manage deployment of the SCA store. For traditional SiteBuilder administrators this can be a steep learning curve.


Like upgrading from a pre-Denali version of SCA to a post-Denali one, moving from SB to SCA presents significant challenges. Unlike merely migrating from one version to SCA to another, these moves require a change of the fundamentals of the web store. This is, after all, not so much an update or an upgrade but a wholesale re-architecture change.

For me, the most illuminating insights are about item data. Perhaps DiscTech is in a rather extreme position compared to some, with over 8,000 inventory items, but the underlying points are still true. While we may spend a lot of time thinking about code and frontend functionality, it is very important to consider how the items sold on the site affect that functionality.

A migration like this is certainly a good opportunity to go through site data and see what's there. Can you get rid of something? Is there a better way to implement a solution? Going through data and changing it is certainly long and tiresome work, but now is the perfect opportunity to undo all of those 'quick fixes' and cheeky little hacks you (or a predecessor!) implemented.

Another part, which is perhaps more useful for agencies working on a client site, is the level of planning and design that goes into it before a single keystroke is made. We've talked about this a bit in the previous discussions around migration, but Intente were clear to emphasize the importance of it. When you combine this with a good understanding of the item data, then you're able to ensure all designers, developers and clients have a solid foundation for doing their work.

Thanks to Intente for agreeing to the interview. They are a web design company who specialize in building and extending NetSuite SuiteCommerce web stores.