Migrating legacy solution with 10 sites, to Helix architecture

Question

We have existing Sitecore sites (around 10 sites) and now we want to convert those to helix architecture. Could you please suggest best way to move these projects to helix ? Do we need to do it start from scratch or any other way is there ?

Thanks in advance !

Answer 1

Others have recommended that you hold off, which is good advice. However, this is how I would start to go about doing it anyway if I had to.

The Plan

First off, you need a plan. Just diving right in would be dangerous. Instead, I would first perform an audit of the codebase. If you haven't already, read through the Helix guidelines pretty carefully.

You'll need to answer these questions:

1. What are some similar themes to classes, so that I might group them together as a module?
2. Are these modules likely to change frequently?
3. Does the module have presentation (HTML/CSS)?
4. Does the module depend on other modules?
5. Where does this content currently live in Sitecore?

Infrastructure

You should check out Habitat repo and get a local instance setup. Habitat has a lot of good practices in it for setting up the infrastructure. At this day and age, it's recommended that you have some sort of repeatable build and setup scripts. Habitat has a bunch of gulp tasks that can be used as a starting point for building something that's right for you.

Creating the Modules

After identifying the modules in planning, I would then start creating them one at a time. I would not rename the existing projects.

For an example, let's say I identified a Calendar Feature in planning. I would create the Feature.Calendar project and refactor all the related code into that project. Before moving onto the next module, I would build the solution and test it to make sure it still works. Having unit tests could speed this up considerably.

Things to Consider

• Sitecore items could contain fully qualified namespaces (ex: Controller renderings). Be sure to update these.
  • if you serialize all your items, you may be able to speed this up by doing a text search in your serialization folder
• Foundation modules can reference other Foundation modules, but Feature modules cannot reference other Feature modules (same deal for Project modules)
• Think about how you're going to deploy this to environments

Helpful Sources

• https://pratiksatikunvar.wordpress.com/2017/07/02/sitecore-helix-converting-existing-sitecore-solution-into-helix-standards/
• How to structure product data in a Helix based solution
• https://www.linkedin.com/pulse/what-powerful-fundamentals-helix-principles-sitecore-based-chopra
• https://www.akshaysura.com/2016/12/27/finally-with-one-great-big-gulp-i-conquered-sitecore-helix/
• http://www.mtelligent.com/home/2017/10/13/best-practices-for-sitecore-helix-and-general-development

---

Disclaimer

This is in no way a step-by-step in how you should do this. My intent is to guide you in the correct direction and get you thinking about what's involved, should you choose to go this route.

Answer 2

I would say that technically, starting from scratch is the best approach, but as Richard already mentioned in his comment, this gives you little to no business value.
So if your organisation accepts that, then go for it.

If you want to deliver business value and migrate to Helix, then try a more graceful approach: Whenever a feature needs work (e.g. it needs to be extended or you need to fix some bugs), refactor that single feature to a Helix structure.
The first time this requires some additional time, because you will need boilerplate code for you solution, but it will cost you less time each time you do it and over time the solution will be migrated to Helix for a large part.

So what happens to code that never requires any changes?
Well, nothing. It continues to live in a non-Helix structure, which is fine!
The Helix architecture is mainly there to help you with maintainability (while staying productive) so legacy code that is never changed doesn't need this architecture.

Answer 3

Please start from scratch from content and technical point of view.

Figuring out what is "component" really mean or needed in the new structure from content and domain point of view (running subdomains or modern "one branding" ) which will drive how you put the data source to be shared.

Also, changing the mindset of typical old "I can edit all the fields in one page type" to "(almost) everything is driven from data source". It will be a big change for content editors.

(Please let me know if I am not answering what he asked for....)