Global Brands: How to Use Sitecore to Roll Out a Redesign by Market

Things move rapidly in the digital world, and for brands to keep up, they need to be able to react just as quickly. Something that worked years ago may not be effective anymore, as customers’ tastes change, and new generations come online. 

Iterative changes can go a long way, but eventually websites will need to be rebuilt for a number of reasons. Perhaps a site is lagging behind in mobile support, or it needs to be fully integrated with Sitecore's Experience Editor in order to implement personalization. The most common reason for a rebuild is a full redesign, which is often spearheaded by branding and marketing departments. This in turn sparks a rebuild, which is when technology teams typically get involved.

Now, we'll examine a scenario in which a business chooses to roll out a site redesign, but only for one market within a multilingual implementation in Sitecore. We'll walk through the challenges, a strategy, and a solution for this scenario. 

The Challenge: Roll Out a Redesign for One Market in a Multilingual Implementation

In our scenario, a global brand is trying to roll out a redesign for just the US market at this time. Their current implementation leverages Sitecore’s language fallback features. US-English is the default language version, and this just happens to be the market that is targeted for the redesign. Retrofitting the existing site is not possible, since the new design calls for a different content structure, and there is no direct mapping of components from the current design to the new one. A rebuild is the best option. 

Rebuilding the US-English site (the default language used for fallback), has repercussions on every other market. Content marketing teams are often distributed regionally across time zones and localize a lot of content and imagery. Coordinating these marketing teams, getting buy-in on the project goals, and gathering the localized creative assets is a huge, time-consuming endeavor, not to mention the technical effort necessary in a world-wide website rollout, which is considerable.

With all of these considerations, a full redesign can take a year or longer to complete, and that means the brand refresh is already a year old before a customer ever sees it. The organization needs a rapid turnaround for this project and can’t afford to wait for branding exercises in each of their regional markets across the world. They’ve invested a lot of money in the current solution, and they want to continue to utilize their investment in the other markets and allow those teams to rebuild on the new design at their own pace.

To add another wrinkle, the redesign is targeted at a subset of pages. Certain pages, such as pages that integrate with their inventory and ordering systems, will remain unchanged, and need to retain the old functionality. So, what are our options?

The Break Up: Isolate the Site of Choice Without Affecting Related Global Market Sites 

We need to build the new US-English site without affecting the global market sites, or their fallback values. This means we need to utilize a split tree architecture. Essentially, we’ll be creating a new site home node for the redesigned site, and leaving all the current content exactly where it is. The advantages to this approach are three-fold: 

1. We’re free to reorganize the tree, alter fields, and create new components as if we were building a new site (because, essentially, we are).
2. The global sites are completely unaffected. The current tree remains in place, and all fallback values and shared presentation details are still available.
3. Other markets can migrate their versions of the site to the new design piecemeal. There’s no need for coordinating teams around the world; they can build out their redesigned sites at their own pace.

The new tree can be re-organized to accommodate a new sitemap strategy, without impacting the existing regional sites not yet adopting the new design.

This is all nice in theory, so how can we execute it? 

A Solution: Separate Content & Resolve the Language Version 

The first thing we need to do is separate our content from the existing tree. If we’re creating an entirely new tree with a new information architecture, this isn’t a problem; we just start creating items. In our situation, we have some pages that aren’t included in this branding refresh, and they need to be preserved, so content duplication is necessary. This can be done in a number of ways, from a marketplace module (https://marketplace.sitecore.net/Modules/S/Smart_Tools_Add_Version_and_Copy_Content.aspx?sc_lang=en), utilizing Sitecore Powershell, or writing custom scripts. Whatever the method, we need this to be repeatable for other regions when the time comes to migrate them to the new design.

Now that we have our duplicated tree, how do we get Sitecore to resolve this language version to the new site? Again, a small customization can help us here. We can create a settings item with a multilist field that allows us to select which language versions have migrated to the new design. Then, a custom step in the SiteResolver pipeline can point the correct start item depending on the language requested by the visitor. Finally, we’re faced with the challenge of supporting the legacy components in the new design. All of our pages will adopt the redesigned header and footer, for consistency in design and navigation experiences. Assuming the site was built according to best practices, it's possible to leverage standard values on the templates to “swap out” the header and footer. The content team can now target their efforts on high-impact pages first, and roll out ancillary pages at their own pace.

What about the legacy components? How can they co-exist with the new design? This will be primarily a challenge for front end developers. If the original site was built with atomic design principles, retrofitting the front end assets to slot between the newly-designed header and footer should not be too difficult. Otherwise, it's necessary to assess the cost of reworking the front end to support the legacy components versus just starting over on those as well.

Next Steps: Roll Out Redesigns of Remaining Global Market Sites as Needed

If all went well, our rebranding effort is live now for our target market, and the other regional sites are continuing to work well using the legacy design and original content tree. What does the process look like for another region trying to migrate to the new design?

Each region’s content team is free to create language versions in the new tree using the new IA or leverage the migration tool we used for the first market; they can then start building out their rebranded site at their own pace. They can also edit, preview, and refine their new site while the old site continues to receive updates and serve their customers.

Each specific situation will likely differ in some, or many ways from the approach described here. Throughout this process, the key to this approach is enabling flexibility and quickly getting things to market. Keep those principles in mind as a guiding light as you conceptualize your approach and execute your plan. As always, if you need help with your Sitecore solution, give us a call.

Have you worked with multilingual implementations in Sitecore? Do you have feedback and insights to share? We’d love to hear your thoughts and experiences. Please add to the discussion via the comments below or Tweet Us, @Velir!