In a few weeks, I'll start a migration project of a Sitecore 6.5 site to an 8.2 site. At that time the Express Migration Tool will only support 7.2 to 8.2, so the rest will be a manual process. I still have to go over the project and code with the original developers. I've googled around a bit for different strategies and was wondering if anyone had a better idea.

I've heard there are a lot of WFFM forms on this site, so they will be a key success factor.

upgrade preparation plan

  1. identify the state of all environments (which version/branch of the solution is deployed where
  2. if possible deploy latest version everywhere (preferably done with original dev)
  3. identify custom code and which parts of Sitecore it plugs in to (together with original dev)
  4. identify configuration coupling: which files need to be changed and which can be used as a whole (together with original dev)
  5. set up a (manual) test plan for smoke testing site in each intermediate version
  6. list deprecated functionalities of each intermediate version to determine code to be modified
  7. list modules that need to be upgraded/replaced
  8. list prerequisites for each intermediate version
  9. choose appropriate windows and SQL server version
  10. run a link checker before any new upgrade to check for any extra problems.
  11. decide which errors can be ignored (but should be documented) until reaching the final version
  12. discuss upgrade strategy with Sitecore (sharing as much info as possible from previous steps)

high-level upgrade strategy:

  • stop development
  • clear publishing and event queues. set longer timeouts in web.config
  • shrink and rebuild db indexes
  • update all environments with production content (take care not to lose not deployed development)
  • upgrade to version x
  • backup analysis and upgrade reports and logs
  • test, compare to x-1 and backup version x
  • deploy version x to staging or whatever temporary QA site
  • have key users verify version x on staging or whatever temporary QA site
  • upgrade to version x+1
  • ... repeat until version 7.2 (or whichever version is supported by then)
  • use Express Migration Tool

Since it's important to spread the word, I will be blogging about this and the solution. First part can be found here

  • Theritically, testing each version upgrade is the best way. but, from my personal point-of-view, i would not put much time on testing individual version upgrades. It is lot of work. Commented Oct 4, 2016 at 11:10
  • do you need analytics data also be migrated to 8.2 ? Commented Oct 4, 2016 at 11:12
  • Check that they didn't use the original Item Buckets shared source module. Last time I worked on a project on 6.6 the installation of this module cause a real headache with the upgrade. Commented Oct 4, 2016 at 11:20
  • I think I heard someone mention silo's. Commented Oct 4, 2016 at 11:47
  • 2
    Is it important to retain any analytics or form data? That's an important factor in deciding on approach. Sitecore was strongly suggesting migrating content to a new 8.x install rather than going through all of the upgrade steps - but you lose all analytics data.
    – Chris Berg
    Commented Oct 4, 2016 at 13:36

9 Answers 9


The answer to this depends on the context of your project. Sitecore's recommendations are to make incremental upgrades for every version and updates as well since your current to the latest you are trying to get upgraded to. This does require a lot of work specially when it's a big jump from 6.5 to 8.2. As already answered here if you are making manual upgrades consider the lists described here as well as upgrading modudes(make sure they are compatible with the latest version), create a separate environment just for the upgrade to run(make sure you coordinate with the client how that impacts the content editing in that time frame), you will most likely need to drop the serialized content tree from 6.5 to 8.2 and test all places where it can break. I recommend checking out these tips for upgrading as well.


When I did an upgrade from 7.2 to 8.1 earlier this year, I followed these steps:

  1. Setup a new instance of Sitecore 8.1 and configure it according to the documentation.
  2. Get my settings/layouts into some sort of source control (using Unicorn or TDS)
  3. Apply those settings/layouts to my new instance
  4. Compile the existing code against the new version of Sitecore, making whatever programming changes were necessary. This took a long time.
  5. Apply a content package from Production, and make sure that the site is working.
  6. Freeze content, generate a final content package, apply it to your new servers.
  7. Run an automated smoke test against the site to make sure that everything in the site is working as expected.

For me, making sure that I had some level of automated end-to-end test was a requirement before we could do a big site-wide upgrade. We had to have all of the major functionality automatically tested before I would entertain an idea of upgrading.

For us, we didn't use any of the "Big Data" features in Sitecore prior to 8.1, so keeping that data was not a priority for us. If it is, then you will have to go through the painful process of upgrading one version at a time.

  • thanks for the answer Keith, good idea of separating the structure items and the content items. This will avoid having test content which could give incorrect results on any automated tests. Which tool did you use for the smoke tests? Commented Oct 12, 2016 at 10:09
  • Hi Ruben! We use Selenium (docs.seleniumhq.org) for our automated smoke test. It gives you the ability to programmatically select elements on a page and then decide what you want to do with it. The tool also has some pretty cool Screen capture capabilities so you can capture screen shots of things when an error occurs. I'm sure that there are other tools out there that do the same thing, but this one fit our budget (It's open source) and there is a lot of good documentation about how to configure it. I hope this helps! Commented Oct 13, 2016 at 14:27

I normally try to split DB upgrading from code upgrading.

This allows me to run the DB upgrade process of vanilla Sitecore instances where any customisations won't interfere with the db upgrade process.

I then upgrade the code as per the SC upgrade guides (and yes this means going through each one). This can take some time because the config changes a lot, my last upgrade from 8.0 to 8.1 u3 had something like 150 pages on config changes to review.

Once I have upgraded and tested my DB and code locally it is then very easy to roll this out because I only need to perform the DB upgrade in each environment which again is done with vanilla Sitecore instances.

More information on the process can be found here:


  • 1
    stackoverflow.com/help/how-to-answer please review this documentation on how to write a good answer. I recommend expanding upon the context of the link. The answer should be answering the question without the user having to leave the page.
    – Anicho
    Commented Oct 12, 2016 at 10:26
  • I just performed the same upgrade as you, pretty much the same way. The main difference was that rather than do manual config updates, I went through the existing solution and turned all config changes into patch files (ideally, they would be like this already) and then I could just drop the new config changes on top. I did this before the upgrade so I could diff the result showconfig.aspx results and confirm the output was the same.
    – Kasaku
    Commented Oct 19, 2016 at 10:56

To inform item 7 in your preparation plan, look at the Sitecore Modules Compatibility Table for Sitecore XP:


Ensure the modules you are using are compatible with 8.2. In my case, Active Directory isn't supported in 8.2, so we opted to upgrade to 8.1.

  1. You have to migrate 6.5 to 7.2 through every revision with manual update. You may have a lot of issues to fix, especially if you are using indexes extensively. We did have a lot of issues as we were using indexes at a lot of places.
  2. Use Express tool to migrate from 7.2 to 8.2.
  3. Upgrade the rest of the customization/code through a manual process.
  4. Fix issues Throughout the upgrade process, you either need to freeze content or do the dual content maintenance.

Also know that you will need to upgrade the .NET version to 4.5.2 for all projects. Are you using solr? Then consider upgrading that too. Here is the solr compatibility table and instructions for Solr configuration - https://kb.sitecore.net/articles/227897#note2


1- If you are doing any pipeline customization, disable it before starting upgrading process. 2-Give Proper read/write permission on your Website folder.

3- If you are doing upgradation process manually, then after upgrading to Sitecore 7.5, analytics database will be needed. So either disable analytics db by disabling Sitecore.Analytics.config or install Mongo DB else it will not let you upgrade further and keep throwing error in backened.

4-Increase application timeout time to proper value.

5- In other case, you can use Express Migration Tool given by Sitecore itself.This will help you to directly upgrade from sitecore 7.2 to 8.2

6- After upgradation is done, You will have to do code changes manually according to new Sitecore version. List all pipeline customization done in sitecore 7.2, and incorporate them manually in Sitecore 8.2


For the record:

The Express Migration Tool now Supports 6.6, so it's an manual Upgrade to 6.6 and than straight to up-to-date for you.


It also supports 7.5 now (which the old one didn't), however only if you go to 9.0.

  • thanks. I used the tool (after manual upgrade to 6.6) last year. Pretty straightforward and smooth experience.... and then came the custom code :) Commented Jan 16, 2018 at 8:08
  • Great to hear that the tool worked nicely. I'm in a migration project 7.5 to 8.2 so I'm blocked from using it and am suffering some pain. The custom code part was rather straightforwarded for me. Commented Jan 19, 2018 at 10:05
  • If at all possible a migration would probably be easier than an upgrade. If you're using WFFM be sure to check the raw values of the _tracking field. The xml thatvis saved changed a bit over the versions between 6.5 and 8.2. Here's some more info and how I fixed it sitecorn.be/2017/03/24/fixing-WFFM-tracking-field Commented Jan 20, 2018 at 23:32

Migration from 6.5 to 8.2 depends on various parameter as below, considering all these factor your migration strategy may be different

  1. your current sitecore architecture
  2. Sitecore search lucence,solr,coveo or other?
  3. sitecore custom implementation means how much you have customized your existing system, including pipeline customization,WFFM,customization etc
  4. Workflow customization, as in new version some workflow pipeline has been changed
  5. DMS implementation, as DMS t XDB is against a new chapter of migration
  6. Page editor mode?
  7. Third party implementation means CRM, Sales force or any other connector implemented in the current system
  8. Current technology may be you are using Webform and want to migrate in MVC.
  9. Any other custom module installation

And many more....

Also refers some good blog on the same:

Good blog by akshay sura: https://community.sitecore.net/members/akshaysura_5f00_1413267979

Another good blog by Jan Bluemink http://sitecore.stockpick.nl/english/upgrade-and-modules.aspx

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.