Possible Upgrade Strategy

Question

I'm wondering about a certain Sitecore Upgrade strategy.

It seems like i have 2 options to upgrade:

1. Perform all the upgrade actions manually ( at the very least time-intensive )
2. Create a new instance and migrate the data from one instance to an other.

I've been told that the second option can hold some unforeseen consequences because of the different designs of the db tables.

My idea: ( Take best of both worlds ? )

1. Copy current databases
2. Apply sql changes described in the upgrade manuals ( CMSxx_BeforeInstall.sql )
3. Create a new Sitecore instance ( with the new version ) and hook it up with the newly changed database tables.

Any comments and feedback are more than welcome.

Edit: In this case i want to upgrade from Sitecore 8.0 Update 2 to Sitecore 8.2 Update 1

Answer 1

Your idea is similar to the way that I used to perform upgrades before TDS. The below is the strategy that I used to use, which I call the "Hybrid-Clean Upgrade Strategy":

Hybrid-Clean Upgrade Strategy

1. Identify your upgrade path (all the versions that you will need to "pass through" as you iteratively upgrade to your target version) and set your current solution (everything but your databases) aside for later
2. Back up your databases with a unique name that includes the Sitecore version (don't overwrite existing backups)
3. Download a clean instance of the current Sitecore version in your upgrade path (the one your instance is currently on) and install it on your machine
4. Set the clean databases for the downloaded instance aside, back up the clean instance's configs to a zip (with a name containing the Sitecore version) and connect your existing databases to the clean instance
5. Install the Sitecore update package to update to the next version in your upgrade path on your newly set up instance (clean instance connecting to your existing databases). You can skip all manual steps for the file system, configuration, etc., except for those that require database schema changes, database script executions and/or other content changes that will be stored in the database
6. Delete the newly upgraded instance's website, keeping only the clean databases (set aside for later), the backed up clean configs (set aside for later), and your existing databases
7. Repeat steps 2-6 until your existing databases have been upgraded to the target version
8. At this point, you should have a clean copy of the databases for each instance in your upgrade path, as well as your existing databases (now upgraded to the target version), and backups of them from each step along the way. Set your existing (upgraded) databases aside for later, along with their backups (don't delete the backups until you are finished and certain that the entire upgrade was successful)
9. Back up the current state of your solution to a zip with the Sitecore version number in the name, and/or commit its current state to a source control repository/branch with the Sitecore version number in the commit comment (or tag name, etc. - just make sure you can identify the Sitecore version at each revision)
10. Now go back to your solution and connect it to the clean Sitecore databases (the ones you set aside, earlier) for the version that it is currently on
11. Install the update package to upgrade your solution to the next version in your upgrade path
12. Follow all of the manual steps, except for those that involve database schema changes, database script executions, or other content changes that will be preserved in the database
13. Now compare the configs in your solution to the clean configs for the new current version (I recommend either KDiff3 or WinMerge, but you can use whichever diff-viewer your heart desires). Make sure that everything matches up with what you would expect to see. If anything is awry, fix and test before continuing
14. Repeat steps 9-13 until your solution has been upgraded to the target version
15. Connect your upgraded solution to your upgraded databases, both of which should be at the targeted version
16. Test, test and test some more!

What you should end up with

At this point, you should have all of the following:

• Upgraded solution
• Upgraded databases
• Backup of upgraded solution for each version in upgrade path
• Backup of upgraded databases for each version in upgrade path
• Copy of clean configs for each version in upgrade path

Testing

Given what you have at the end, you can now test to make sure that your solution is working in the target version and if not you can test each version that you upgraded to in the upgrade path to find out where things went wrong and fix them for each subsequent version.

If desired, you can optionally modify the strategy and run both the database and solution upgrades at the same time, reconnect them after each version upgrade and test before upgrading to the next version. I usually don't do this, unless something went wrong (which is rare), in which case I simulate this with my backups.

Pros

• Speed: because either the databases or the website is always clean, each update packages installs a bit quicker than it would otherwise (though still slower than a fully-clean instance). You can start the upgrade for the databases while you set up the upgrade for the solution, so that they both run at the same time. Depending on the complexities of your databases and your solution, you may want to alternate which you do first, based on the amount of time each takes
• Reduced errors: since either the databases or the website is always clean, you have less errors on each update to go through, and there are also less errors thrown by Sitecore for things that it didn't expect/doesn't recognize
• Upgrade record: you have a historical record of the upgrade process and the state of your solution at each step along the way. You can stand up an instance of the historical state of your site at any version in the upgrade path that you might need, on demand with little to no effort.

Cons

• At the end of the day, you are still running each update package twice
• Requires more hard-drive space

Improving the Hybrid-Clean Upgrade Strategy with TDS

When performing a Sitecore upgrade using the Hybrid-Clean Upgrade Strategy TDS can cut the time and effort required for the upgrade down by almost half!

Changes to the Upgrade Strategy

If you have TDS, you can ignore the entire database side of the upgrade and simply serialize your existing (old) Sitecore databases using TDS and then deserialize them into a clean copy of the databases for your targeted version of Sitecore.

Changes to Testing Procedures

If you want to test at each step along the way, or if you need to roll back to retest at a particular version in your upgrade path, don't fret about not having copies of the databases at those versions! TDS can help with that too! All you would need to do is the same thing that you are planning to do at the end of the upgrade: attach a clean copy of the databases at the desired version, point TDS at them and deserialize your site tree into those databases. You should now be ready for testing.

Additional Considerations

• If you are using Sitecore membership then you may need to come up with an upgrade/migration strategy for users, which may mean running the upgrade with clean master and web databases but your existing core database
• If you are using analytics then you may need to come up with an analytics upgrade/migration strategy

Answer 2

There isn`t a single right answer for this. Upgrading Sitecore can be a time consuming activity and depending on the version jump you are facing and the timeline of your project sometimes you can't just upgrade every single update from your current to the latest. There is a related post answered with some insights on approaches you can take here

Personally I would recommend trying to follow the Sitecore's upgraded path because you will stay(or should stay) out of unexpected issues and you have a guideline to follow. If that's not an option Zachary made some very good points on the hybrid approach