This may be a vague question or too broad for Stack Exchange, but I will try it anyway.

We are doing an upgrade from v7.5 to v8.1-3. We are using a hosted instance of Mongo called ObjectRocket from Rackspace. My basic plan for doing the upgrade is as follows:

  1. Create a second web site on the CM and CD server using a separate IP address.
  2. Install fresh copies of v7.5 on the second web sites.
  3. Backup and restore the current production Sitecore SQL Server databases with new names and modify the fresh installs of Sitecore to point to these database copies.
  4. Perform the upgrade to go from 7.5 to 8.1-3 on these second sites.
  5. Deploy all of our custom code on to the servers.
  6. Switch over IIS to use these second sites.

That's the rough set of steps. My real question is how does Mongo/xDB fit in to all of this? I guess I don't have a clear understanding of what data is in xDB in v7.5 and how exactly I should handle that during an upgrade given my above approach. Do I have to make copies of my xDB databases and create a second set of Mongo databases? Can I just hook up my second sites to the same Mongo databases during the upgrade process? My only understanding of xDB is a vague idea that it holds large amounts of "analytics" data that is eventually transferred to the analytics SQL Server database. I'm just wondering if I am missing something that I need to be doing for this upgrade with Mongo/xDB.

Thanks, Corey

1 Answer 1


To answer your question, really, I feel it's prudent to walk through the deployment steps and call out where places that might be gotchas. I'll finish with a summary of what I would do.

Sitecore 7.5 - 8.0 Initial (141212)

The first step that you'll want to do is upgrade to the 8.0 Initial release. You can find the Upgrade Guide here. During this upgrade, there is not much that is changed on the xDB front, however Step 1.2.8 - Redeploying Marketing Data is going to be taking portions of your analytics database and redeploying it to a new schema.

With regard to xDB there is not much going on here. Also worth noting that schema changes in xDB kind of happen automatically, one of the pro's of using a schema-less data repository.

Sitecore 8.0 (141212) - 8.1 (151003)

The second step is going to be upgrading from 8.0 to the inital release of 8.1. You can find the Upgrade Guide here. This is a pretty involved upgrade step, mostly doing a lot of work on the SQL side, however, really starting to augment the xDB side of the house with content testing data in xDB.

You'll want to pay careful attention to Step 1.3.3 - Upgrading Content Testing Data which has direct impacts on xDB and xDB configuration.

Sitecore 8.1 Initial (151003) - 8.1-Update 3 (160519)

The third upgrade step is going from 8.1 Initial to 8.1 Update 3, again you can find the Upgrade Guide here. In this particular upgrade, there are no specific xDB upgrade steps, short of making sure that you disable xDB in the config while the upgrade package is running.

How I would do it

1) I would look into making a copy of your Mongo collections. To do this, as long as you are using MongoDB 2.1+, you can copy a collection using the following syntax in a tool, like Robomongo:


In this example, the collection I want to copy is example1 and this will copy it to a new collection called example2. You'll want to do this for all of the mongo collections:

  • analytics
  • tracking_contact
  • tracking_history
  • tracking_live

2) I would then setup your second 7.5 site (upgrade environment) that you'll be using as your upgrade site and point the connection strings for mongo to the new collections.

3) Perform all of your upgrade steps in your upgrade environment.

4) Adjust/refactor your custom code base as needed.

Now, in a perfect world, you would think that switching over IIS to the new site would work, and maybe in your case, the rate of change in your production content is minimal enough that this work. If that's the case, the I think that's all you need to do.

However... if the rate of change is high, you may be looking at having to upgrade the Content Management environment in PRODUCTION again. Only this time, you know what to expect, you've done it once before in the upgrade environment, and now it's just a matter of doing the work. This will also include any changes to production xDB.

At that point, use your standard deployment methodology to move code bits to the CD servers and any other role servers you might have deployed. And your off to the races.


You really don't have to worry too much about xDB. I think the Content Testing changes are the only point that you'll want to pay attention to. The rest of the upgrade, for the most part, has xDB disabled.

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.