7

The short version is that we have Sitecore 6.x running right now. It was put into place about 3 or 4 web developers ago.

I'm currently without a dedicated web developer, though I've got someone I'm training (I also develop, but have really no time for a project this size). Due to a number of developers working on it over the years, there are a number of varied forms, styles, etc. The last guy worked hard to make it all look cohesive, but there are still forms that are used that are less than ideal.

Anyway, it has become a pain to work on and I've been told, by our Sitecore rep, that the newest version is leaps and bounds better. I've also been told it is a huge leap to upgrade from what we have. They have given us a quote for some hours, but it seems very high. I'm looking into some trusted partners for help as well. Now, for my actual question!

How difficult is it to put in the latest version of Sitecore (8.2 at time of writing) and move/port/redo what we have in 6.x?

Edit: just wanted to say thanks! Y'all are giving me some great insight on how we will go forward. To clarify, when I said "they" on the quote, I meant a quote straight from Sitecore and I have to imagine this is the most expensive route. I'm going to discuss some of these ideas with my boss and see what direction we will be going down.

10

Having done a fair few of such upgrades in the past, I'll chip in with my own view as well.

And it will probably not be entirely without controversy.

Scrap and rebuild

My advise to you would be: scrap it. And rebuild. And since you indicate you've already received a "very high" quote for the work, my guess would be that this is more or less what the vendor who quoted, has in mind. This remains speculative though.

But I'll sum up the reasons why - just keep in mind, I have nothing to base this on but own personal (anecdotal) experience, and what you've shared with us.

It's old, and it's costing you money

IT was put into place about 3 or 4 web developers ago. I'm currently without a dedicated web developer, though I've got someone I'm training (I also develop, but have really no time for a project this size). Due to a number of developers working on it over the years, there are a number of varied forms, styles, etc. The last guy worked hard to make it all look cohesive, but there are still forms that are used that are less than ideal.

And you have now come to the (right) conclusion.

Anyway, it has become a pain to work on

Paraphrasing what you outline here is; would be something like the maintenance cost of this beast is killing us, and it's no longer worth it.

Upgrading won't solve your problem (alone)

Nothing in what you say tells me, that you and your users are in any particular way unhappy with the Sitecore version as such. With the Page Editing experience, with the limited OMS/DMS capabilities (or if they are even used). All the problems you describe point to an aging codebase and the aches and pains associated with it; and the increased maintenance hassle in keeping it airborne.

Also; 4-5 different developers have been involved over the years - each with their unique coding approach, each with their own Sitecore background (or perhaps even lack thereof). I've seen codebases like that. They are what they are.

Just be clear; none of these problems will get fixed by an upgrade. Those require a rewrite.

Difficulty of this task

Nowhere near as bad as you might fear. The initial reaction - especially from non technical managers - tends to be: "But we've invested 4 years of development hours into this. No way we're scrapping it". Reality is however; code I've spent maybe 2 weeks to create for a custom solution, I could usually re-do in 1-2 days were I to scrap it and do it again. If you're just rebuilding without actually changing everything around, functionally, the task is much less cumbersome than one might be inclined to think.

In your case; you're also looking at .NET framework upgrades; possibly a shift from the soon obsolete Webforms to MVC; maybe take a look at that dated and likely not optimal HTML and CSS that's been clogging up mobile phones for years - add all that up, and the benefits of a rewrite become more apparent.

How to estimate the workload

I'll tell you this; it has very little to do with the amount of pages you have. Usually, content can be scripted across in one form or another - and the only thing that changes when a script runs through 100 or 1000 pages, is the time it takes to execute.

These factors influence the price, both to upgrade and to rebuild:

  • Number of unique components. You may refer to them as "renderings", "sublayouts", "stylesheets" (shudder). Any way - unique building blocks that make up the framework of your site.
  • Number of integration points, to any and all third party systems
  • Information Architecture. If done really badly (and there was a lot of that going around, back around the time your solution was originally crafted) - then it might need to be completely redone. This has the potential to make your content migration significantly more difficult.
  • HTML crafting; actually does affect how easy it is to componentisize. Again; the world has come a long way with HTML and frontend developer tools since the turn of this decade.
  • Functionality. If for instance there's ecommerce functionality on the solution, this will significantly increase development time AND (more importantly) testing time.

And yes, find a trusted partner.

I simply cannot stress how important this is. Find one of the core partners in your region, the ones that live and breathe Sitecore, and have the right people around to get things done right. The worst thing that can happen in your case, will be to get another team of inexperienced developers on board to rewrite the solution, only to end up pretty much back where you are now - only shinier and with lighter pockets.

In summary

Your solution is upwards of 6-8 years old. Financially it should be written off by now; but the amount of technical debt (a term not chosen by coincidence, at all) is still crippling your platform. Likely taking up so much time, there is no room for new development. As you also state:

I also develop, but have really no time for a project this size

Get it re-done. To make it an easier sell to management (or whoever foots the bill); you might want to re-term this slightly differently; use maybe car analogies like "we're going to keep the frame and bodywork intact, but all the electrics and most of the engine parts need to be replaced" or some such. Whatever works.

But rebuilding is, in my opinion, your best course of action here.

I bring 12 years of Sitecore experience to the argument, since we're dealing with a highly subjective question here.

A few additional resources

8

In short it's not easy to do this as version 6 is pretty old (nearly 9 years old to be exact!).

Sitecore have released a tool to upgrade from 6.6 or 7.2 to 8.2 but it will not do everything for you and it depends on the customisation and how they have been done as to how much manual work there will be to do: https://dev.sitecore.net/Downloads/Express_Migration_Tool/20/Express_Migration_Tool_20_Initial_Release.aspx

At SUGCON last week there was mention of improving this tool further to support 6 or even older versions so that may help. I'm not sure when this will be available though.

The key thing though is that how things were done back in the days of 6.0 is very different to how things should be done now in 8+, for example:

  • 6.0 will be using Web Forms and you should now be using MVC to build components and layouts
  • 6.0 didn't support doing config overrides in the same way so they are likely disorganised
  • 6.0 didn't have all of the APIs in place that are available now or is using old/depreciated/changed APIs and references
  • Code written for 6.0 is likely implemented in a non-best practice way and will need re-writing to be more manageable and more in-line with modern approaches
  • 6.0 is written against .NET 2.0 and 8 is .NET 4.5
  • In 6.0 Stored Analytics data in an SQL database in a specific format and in 8 it is stored in MongoDB so the data and any related code will need migrating/updatingA
  • Any custom modules you are using will need upgrading (some may not be supported on 8.0 either)
  • Often 6.0 solutions used custom caching layers due to performance problems with Sitecore 6.0, these are no longer needed in 8.0

There are many other things to consider here too, this is just some of them.

Ultimately you may find a migration from 6.6 to take your data/content over 8.2 and starting again with building your solution is the best bet.

As others have mentioned there are tools to help with migrating content over so you don't have to completely start again.

Maintenance of the solution and future upgrades would certainly be better if you started again in terms of custom code, config and so forth though. It will also allow you to create a solution using more modern approaches such as DI/IoC and tools such as GlassMapper and Unicorn.

3

You have different options but it all depends on timings and budget. Also, there can be other different options apart from the one I've listed below. It's mostly based on my experience while doing Sitecore upgrades.

Option 1

Express Migration 2.0 module can be used to update the Sitecore Instance 6.x to 8.2. More info about the tool can be found here.

Option 2

Making use of upgrade packages only. This is a very long process whereby you will need to upgrade the sitecore instance gradually. In other words, you update from 6.x to 7.0, then perform the adjustment of config and dlls files. Then 7.0 to 7.1 and it goes like this.

Option 3

Install a fresh Sitecore Instance v8.2 directly and then start migrating your code and items. You may use TDS to sync your items or Razl to migrate the items or Sitecore packages. Note that TDS and Razl are paid modules. Moreover, before deploying your code, it needs to be built with the new Sitecore 8.2 dlls.

Note that code changed will be required as there are many namespaces from 6.x are obsolete or have changed completely.

I will tend to choose option 3 as from my experience it is much quicker and also, reduce the number of errors in terms of configuration files and dlls versions.

1

Until your Sitecore implementation doesn't have much customizations, multiple integration points and variety of add-on modules, Express migration tool is your best bet.

But if the answer of above three points if yes, I will recommend to go by the incremental upgrade approach, Option 2 by Hishaam above.

Extracting the experience of 4 upgrades, i penned these two blogs:

https://sitecorecompetencies.wordpress.com/2016/08/24/planning-a-sitecore-upgrade-tips/

https://sitecorecompetencies.wordpress.com/2016/08/24/estimation-tips-for-a-sitecore-upgrade/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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