As implementations differs from one company to another, the intent of this article is not to show so how to steps or guidelines on how to implement Helix on your current solution, it is just a client case demonstrating the successful implementation of Helix on a Sitecore 6.6 which clear our path to an upgrade towards the latest version.

A bit about the project:

The website is was build in 2012 for the yellow page provider of The Netherlands. Initially built on Sitecore 6, the project has seen some ups and down during the years. It was first built for the public environment and as a website is meant to evolve, the private environment was added to the stack. The public environment was using Sitecore features, and on the other hand, the private environment was using only 25% of Sitecore features and almost everything was hard-coded.

When I joined the project it was kind of a shock. I worked with Sitecore 8 and all of a sudden I am back on an oldie, it was running on 6.6! The project had what most of the projects built on older version of Sitecore have: Sublayouts everywhere, class names as item names, a lot of item inheritance with not really an explicit name, in short a "not really easy solution to maintain and to grow". Do not get me wrong, I am not saying that the persons who worked on the project did a bad job, but as a matter of fact, the project have been outsourced to different partners and in-sourced a couple of times over the years, and as a result, as you might expect is a quite what we had as a solution. Although each party tried to understand their predecessor, each entity involved in the project created their code in their own way making quite difficult to navigate through the final solution and to maintain it.

Why the change?

As any other companies, to stay up to date our website evolves quite fast: new features are added, the current design is improved, etc... Our problem at that time was how to make it grow faster, improve our delivery quality and better and potentially upgrade its technology stack? As we were most of the time doing trial and errors when modifying a component, the last but not the least of our problem was "figuring out" how to maintain existing functionalities and also increase our time to production.

The solution!

A question might pop up "why would spend time implementing Helix on a Sitecore 6.6 solution instead of making the upgrade and doing it on a later version of Sitecore".

The reasons of the mentioned above question might be quite obvious:

There is a huge difference of 2 major releases between 6.6 and 8.2 which makes our upgrade path longer and involved a lot of rework in remodelling all the components from ASP.net webforms to ASP.net MVC, why don't we just rebuild the whole site in MVC.
The website has a lot of features that a currently being used on the live site.

Based on the two previous points, refactoring an already working website, even if it is an old one, is a hard cookie to sell to the management.

How we tackled it

First step: Prove the value added of this technical step.

I was the only one knowing Helix at the company, so the first step was to first share my thoughts and my approach to the development team. Since we are meant to add and remove features on the go, Helix was the right path for us. So we started to create all new modules as Helix compliant and started to rework on the old components to make the Helix compliant as we go. As a result, since everybody knows where to locate the modules and two persons could work together without affecting each other's code, component level unit tests were added to the solution, we increased our velocity and also our quality.

Second step: Promote the result to the marketing team.

Also, Helix is not really visible to the marketing team, yet, they could still see a difference between the old and the Helix compliant solution, they could start to use more Sitecore features such as personalization instead of hard-coded pages which resulted in the marketing team being able to propose the right content to the right user at the right time.

Third step: Wrap everything and promote it to the management.

The crucial step in the implementation is to switch from a multi-tier architecture to a component based architecture. We refactored and separated every business logic into separate layers. The modularization of the business logics allowed us to reuse the code in both MVC and WebForms.

Since we already made some indirect steps towards the upgrade, we felt confident to pitch the upgrade to the management team.

Final step: Acquiring the upgrade and moving forward with the Helix implementation.

Thanks to the previous steps, we could come up with a more accurate planning plus a reduced timeline for the upgrade. As an outcome, the company's stakeholders were more than impatient to finally run on the latest version of Sitecore.

Lessons learned

Using Helix on a Sitecore 6.6 solution might not be the solution every architect would implement at first because it would take too much time and most of the time, refactoring an already working solution is not really seen as a value added from a business and the management point of view even if we technical people would consider it as a must. In our case, our solution was highly tightly coupled, making every change a risky one.

Making that first step in implementing Helix was not an easy one, since nobody is aware of what it is, my first job was first to share my knowledge with most of the team at first, pushing it to the content authoring team and gradually pitching it to my management.
A solution needs to evolve to support the current trend, if it does not, then we would have difficulties other competitors in the market.
As a direct effect of having Helix's implementation, we increase our quality, productivity and most importantly we could show the management that everything is not black or white.
We already made some steps towards Helix without even knowing it.
Not all Helix implementation follows the Habitat model; We made a migration from an multi-tier architecture to an hybrid multi-tier/component based architecture to support our traditional Enterprise Service Bus and merge it with Sitecore.
GIT and Helix are meant to work together.

The noticed benefits from Helix:

Quality:

Increase could be noticed in the code quality. Each feature is set as a separate project and each project has its own unit testing allowing every developer to test before deploying.

Really compatible with GIT and its feature branches. Each time we have to create a new feature or make an intervention, we have to create a feature branch and make pull request to allow everybody to review each other's code before merging.

Velocity:

Establishing Helix took us some efforts, but once it is in place, we could notice an increase in our velocity during each sprint

Unlocking the Sitecore Upgrade:

Using Helix on a Sitecore 6.6 solution might not be the solution every architect would implement at first because it would take too much time and most of the time, refactoring an already working solution is not really seen as a value added per the business and the management even if we technical people would consider it as a must.

In our case, our solution was tightly coupled with every services and every modules were all built in a single big project, making it really difficult to even consider an upgrade.

To overcome this aspect, we had to make an hybrid multi-tier/component based architecture demonstrating the real added value of a loosely coupled modules by applying the right dependencies and separating each services, business logics and sublayouts into their distinct projects which was the winning ticket for the upgrade.

Tech

Breaking through migration issue with HELIX!