Recently Sitecore 8 has released and it has came up with lot of exciting new features. So our team decided to move from Sitecore 6.6 to Sitecore 8. Before migrating, i would like to know what all things i should be having in handy. Such as, .net Framework, Hardware configuration, environment etc.
Also, i would like to know the procedure to migrate from 6.6 to 8? I, never involved in sitecore migration project before. Please suggest me some good articles or post here your thoughts.
Thanks in advance. :)
See the Sitecore Compatibility Table for the .NET Framework, SQL Server version and Windows version.
Two common approaches.
1) Follow the Sitecore upgrade path.
2) Package the content, and start with a clean install.
Currently I working on a upgrade with an scripted upgrade that follow the Sitecore path. So I can easy repeat the steps and have the latest content in the databases.
I have some of my findings put down here Sitecore update and modules this article contain also a Related links section. Such as the upgrade white paper from Varun
Depending on how 'cluttered' your existing instance is, you may also want to consider installing a fresh copy of Sitecore 8 and then migrate your data/code to avoid all the hops that would be necessary to get to 8.
May be the following blog might help. Take a look at it.
https://varunvns.wordpress.com/2014/11/11/sitecore-version-upgrade-whitepaper/
I would recommend you make a backup of your site to use as a "sandbox" for the upgrade. Copy your databases and the web root for your site to a new location and then set up an IIS site with appropriate permissions pointing to your copy, and change your connection strings in the copy to point to a copy of the databases you backed up.
Perform the update there and ensure everything is working correctly. Work slowly to make sure you are following instructions correctly and note any special actions you had to take to perform the upgrade. Once you have it upgraded, perform the same process on the "real" site.
If you work with a Sitecore partner, I would highly encourage you to discuss the process with them to learn more specifics about the risks and challenges you may encounter during your upgrade.
Related
I am trying to upgrade Sitecore 9.0 to Sitecore 9.2. Couldn't find any specific way except first upgrading to Sitecore 9.0.2 and then proceed further. But, this way getting many errors related with config file. Is there any other way to upgrade directly to 9.2 verion? Any help would be a highly appreciated. Thanks.
The alternative method to 'upgrade' which I often look to is to spin up a clean install of the newer version and then migrate my old code into a new solution which will already have all the latest configs/ Sitecore base code in place.
Doing this means you can just patch your custom app config settings and ensure the Sitecore dependencies in your solution are the newer version which can often be a cleaner/simpler way to go.
There are a couple of things to consider before doing this however, such as whether you need to keep your data in XDB etc. as it would mean that you may need to look at migrating it which can be a pain and since you are looking at 9.0 to 9.2, you'd have additional services to consider as well such as Identity and may need to account for that kind of thing too.
I am currently trying to upgrade a Sitecore installation from 7.5 to 8.1 Update 3 and I can't seem to figure out a good process that won't take weeks and weeks. I have posted questions on other blog posts and also to the official Sitecore Community site but have not really gotten any good feedback. Here is what I am trying to do.
I need to upgrade Sitecore from 7.5 to 8.1 Update 3. To do that it looks like I need to do 3 separate upgrades:
7.5 to 8.0 Initial Release
8.0 Initial Release to 8.1 Initial Release
8.1 Initial Release to 8.1 Update 3
In addition we are using both the Email Campaign Manager (ECM) and the Webforms for Marketers (WFFM) modules. Each of those modules has its own separate upgrade instructions.
Also we have servers in 3 different environments: 1 in DEV, 1 in QA and 3 in PROD (1 CM and 2 CD)
The upgrades of Sitecore itself are long and tedious and filled with many manual steps prone to error. I am already on my 3rd attempt to upgrade my DEV site and it seems every time I do it I get about half way through and I run in to lots of errors. In addition the instructions for upgrading ECM/EXM seem to not allow you to skip to major releases. So to upgrade EXM itself I am going to have to do 10 individual upgrades!!!
I am trying desperately to figure out if there are any shorter ways to accomplish this upgrade. This is so complicated and tedious that I feel like it will take me one or two days just to upgrade the DEV site. Then another one or two days to upgrade the QA site - assuming I don't run in to any errors that I can't figure out.
Then after that I have absolutely no idea how I am going to upgrade PROD. I have a CM server and 2 CD servers. There's no way I can freeze content entry and editing for a week while I do the upgrade. Plus we have some user generated content like user registrations and order entries on the site. How can I upgrade PROD and not lose registrations and order entries and other user generated content?
I was hoping that there would be some easier way of doing a Sitecore upgrade from one major version to the next but I can't seem to figure it out. No matter what I try it is incredibly complex and manual and prone to error.
Any help is appreciated.
Corey
One option could also be installing a new version of Sitecore 8.1 update 3 and run a database comparison tool (such as RAZL) to get across the items in your new Sitecore instance.
You could get the items across using the regular Sitecore packages although that's more time-consuming unless you automate that using something like Sitecore Ship or Courier.
You'll also need to check your code of course, any config changes you're patching in etc. still will have to be tested.
Mind you, this is not recommended practice for reasons you can find in the blogpost jammykam posted in a comment (http://www.seanholmesby.com/the-truth-about-sitecore-upgrades/)
There's rumors of an Express upgrade tool in 8.2 that will allow you to upgrade directly from an old version. I don't have an official source, but there's a few blog posts about this, this for example: http://kverheire.blogspot.com.au/2016/06/sitecore-82-in-depth-preview-83-update.html
I believe the people who actually have more info on that are bound by NDA - so you'd have to ask Sitecore directly for more info.
If you can't wait for 8.2 - then you can also create new blank environments of a newer version and write your own processes for migrating data across. Not sure how easy this will be with EXM, WFFM, or Analytics though.
Recently we have upgraded a project from sitecore 6.5 to sitecore 8.0 update 5, and we are now in the process to go live, but we want to migrate the data from the live environment so we can deploy the upgraded site.
We always migrate the data by serializing the items in the content tree or creating sitecore packages. Is It safe to do this, specially we will move the items from sitecore 6.5 to 8, Any potential errors might happen? Are there another techniques we can use?
I have taken this approach with an upgrade from 7.2 to 8.0 update 3 without any problems.
There was a change to the structure of the rules engine in 7.1, so if you are making use of rules in your content you might run in to a few problems. It's shouldn't break Sitecore completely, but you might have to reapply the rules.
While I'm quite comfortable with the content migration approach to upgrades, not everybody feels the same way. Here's a blog post that raises some concerns you might want to consider:
The Truth About Sitecore Upgrades
I'm planning a migration on a server from ColdFusion MX7 (Server 2003) to ColdFusion 11(Server 2012). There is a Other Server Where I need to migrate from ColdFusion 8 (Server 2008) to ColdFusion 11. Does my System effect in any way when upgrading like tags, or compatibility issues. Does anyone know which steps I should without effecting. I know about the code analyzer that we had in Cf administrator. I want to know if there is anything effected seriously when migrating.
Thanks in Advance
Kiran Kumar
The Code Analyzer helps in migrating your applications to ColdFusion 11 from earlier versions of ColdFusion. However, it checks the same for only two versions back. The Code Analyzer reviews the CFML pages that you specify and informs you of any potential compatibility issues. It detects unsupported and deprecated CFML features, and outlines the required implementation changes that ensure a smooth migration.
As far as the code compatibility is concerned, everything "should" work. However, it is recommended to check the code compatibility and deprecated tags (if any). You can refer to https://wikidocs.adobe.com/wiki/display/coldfusionen/Deprecated+Features & https://wikidocs.adobe.com/wiki/display/coldfusionen/Deprecated+tags,+attributes,+and+values.
I have briefly covered the entire Migration process here. So, will not iterate the same. Also, you can have a look at another helpful article for Migration Tweaks.
Having said that all, it's strongly recommended to test your website on the Testing/Development environment, before moving it on Production.
Hope this gives a better picture of the migration process.
I did the migration in the past, did not face important issue, as everyone have a different system the best solution would
- Backup
- Test the upgrade and see
if it's a production machine, you can copy your machine to a vm and test the upgrade there. it's may be a lot of work, but you can not know if you don't test
I am currently moving a ColdFusion 9 site to Coldfusion 11 and the way I tested it was to create a separate set of folders on the ms2013 server. I ran them side by side with a duplicate database with a different name for the test site.
I have moved sites up from 5 to 9 with few issues and the only one that really got me in ColdFusion 11 is dbtype in database functions. It has not only been depreciated but will always throw an error if found.
It also depends on how Coldfusion 11 will react to cfcs and other special tags if you use them. I don't so it was a snap.
Examples:
mydatabase
mydatabase1
mypagesfolder
mypagesfolder1
index.cfm
index1.cfm
Going live was a snap. I just renamed the folders, links*, dsn and renamed index1.cfm to index.cfm.
*Links only need to be changed if posting outside of folder and if so just the path.
The general guidance appears to be to install Sitecore into one folder, e.g. D:\Websites\MyWebSite and then create your Visual Studio project in a separate folder, e.g. C:\Projects\MyWebProject. You would then publish your custom code into the Sitecore folder from Visual Studio (This video explains what I’m describing https://www.youtube.com/watch?v=i3Mwcphtz4w around 13 mins in).
I have the following questions:-
Do people only store their Visual Studio project in source countrol and not the Sitecore code?
The publish option from VS into the Sitecore folder only has options for adding files or deleting anything not in the VS project. How would files removed from the VS project ever get deleted without doing it manually?
We use web-deploy to publish sites to staging and live environments. In this scenario would you publish from your VS project or would you set up a way to publish the Sitecore folder (if so how)?
Is this actually a good set up to have or do you do something different?
I did a lot of research on this when we started Sitecore development a couple of years ago. I remember reading a post from Sean Kearney that made a lot of sense to me: http://seankearney.com/post/Visual-Studio-Projects-and-Sitecore
We ended up using this approach for both large and small scale projects and it has been great. You will also want to look at a couple of other tools:
Team Development for Sitecore (TDS) from Hedgehog Development (http://www.hhogdev.com/products/team-development-for-sitecore/overview.aspx)
CopySauce from Igloo (http://www.igloo.com.au/blog/copysauce-igloos-sitecore-development-utility/)
SitecoreRocks for Visual Studio
So to answer your questions:
All of your code and some of the Sitecore items are stored in source control. The approach you want to take is to only store new Sitecore items (layouts, sublayouts, templates, etc) that you create along with any items you may need to customize. You do not need to store all of the sitecore source, content or modules...just what you would need to reapply to get a fresh environment up-to-date. You can manage this manually but a tool like TDS makes this MUCH easier.
We use TDS to manage the publish/deploy to each of our environments. TDS has configurable settings for handling items that have been deleted, including the ability to move it to the Sitecore recycle bin or simply remove it. You have to be careful with this but it does work.
We use a separate build environment to assemble and run deployments using TDS and Jenkins. Basically, all of the code is retrieved from the source control system to the Sitecore server and built using MSBuild and TDS. In most cases we use a webdeploy directly to the Sitecore webroot, but for production we build TDS packages and then run them on each Content Delivery Server
We have used this setup for 7 sitecore projects so far and I am very happy with how it has worked out. We have questioned whether TDS is worth the license fee but the answer always comes back as a yes. The alternative is not very appealing for our development staff and time savings far out-weigh the costs.
Everything is stored in Source Control!... just not always in the same area as they reside on the web server. Storing the Sitecore folder in source control is a good idea as there are changes that you will have as you install modules, but you do NOT add the Sitecore folder as part of your solution/project and should really be there to pull from if need be and not something that is even tracked/monitored.
Once Sitecore is installed, create a new project that resides in the website folder and only add things like the properties folder, layouts, xml and other folders that you want. I don't even include the app_config in my project. Oh and to be clear, it's probably best to just keep the Sitecore folder as a sort of reference folder in your source control but not as part of your website trunk. We have it on the ignore list for website folder in source control. However, that being said, keep in mind that you will NEED to have it in your website folder.
Technically speaking, the recommended approach is to install Sitecore on to the server itself as a stand alone empty instance.. like using the installer with the client mode (not full) so that you get the framework for an empty site in place. Then you can create the deployment package/packages/whatever and it will all be your own code. You should really never have to mess with changing/removing the base Sitecore file system manually.
See above. Generally speaking, unless you have a reason to do so: install Sitecore as an empty instance... then manage your code/files via deployment and just leave the Sitecore folder files alone. You will have very little reason to ever touch them or the Sitecore folder itself outside of an upgrade.
Adding Sitecore itself to source control should be avoided, since you won't be deploying Sitecore as part of your implementation. For modifications to Sitecore itself, you would need a way of handling those inside your implementation, but the config patch system and other mechanisms provide the means for this.
Redundant files in the web site folder will only be a real problem in your development environment. When publishing to a demo environment or to a live environment, you will only publish the material that you actually want. And the deployment-based setup opens up the possibility of always starting from a clean Sitecore installation - as long as you include your Sitecore modifications as part of your implementation (which is not covered in the video). So there is little risk of this being a problem in real life, and the development method in the video makes eliminating this risk entirely possible.
The Sitecore installation should be handled outside of the deployment of your implementation.
It's a good setup, because the method in the video is the method Sitecore recommends for development, and it is also the method Sitecore teaches to developers in development courses. The most obvious advantages of this method are
Clean separation between your web site implementation and the Sitecore installation. There is no risk of accidentally mangling the Sitecore installation, and there is no risk of forgetting unmanaged manual modifications to Sitecore that are needed to run your site. This separation is hard to accomplish if you're not using the method in the video.
By using publishing to deploy your implementation, you know that your implementation is deployable on top of a clean Sitecore installation - and works. This means when deploying to a production or demo server in the future, things will work the same and there will be no surprises. This is very hard to be confident about if you're not using the method in the video.
To test your implementation on a different version of Sitecore, you can just deploy to a clean installation of a different version. This is very hard to test if you're not using the method in the video.
There is sample source code for the video on GitHub, along with instructions on how to set up the development environment, including the publishing parts. This sample source directly and indirectly answers some of your questions.