6

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 !

Improve this question
1
  • 2
    It is generally accepted that a project to migrate a codebase from one structure to another, or a project that involves widespread refactoring, is a bad idea. These projects are very risky, expensive, time consuming, and offer little-to- no business value. Instead consider that all new works adhere to Helix principles, and remove legacy components as soon as possible. Over time your codebase will improve, and you will learn good code hygiene habits as you go. (ref softwareengineering.stackexchange.com/questions/122014/…)
    – Richard Hauer
    Commented Jan 29, 2018 at 6:46

3 Answers 3

Reset to default
8

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

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.

Improve this 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.

Improve this answer
1

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....)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.