With all the nifty features and functions that are available in the new version of OCS, I can’t really see a reason to hold back and NOT migrate. Being the type of company that we are, it’s important to keep up with the latest products and show that we can make them work. That being said, sometimes it’s hard to hit the ground running when you don’t have a large customer base for that type of work.
One of the struggles with any small company is that with the limited resources available, sometimes you can’t set up a whole new lab environment just to test the new software. In my case, my work on other paying projects put a lot of internal IT projects on hold. This is not to say that the projects were being ignored, just that they took a much lower priority than I would have liked to assigned them.
My current project of love and devotion is our migration as a company to Office Communications Server 2007 R2, which was recently released. This is a big deal to me, being a Unified Communications consultant, so I’ve taken the time at work and at home to learn about what needs to be done.
I don’t want to sit here and outline all the dinky step-by-step screen shots, since I’m sure that there are other sites out there that have those. What I’d rather do is outline the thought process and planning steps that are required for the migration.
Okay, on to the fun stuff… Let’s talk about migration paths!
Supported Migration Paths
Microsoft has put a bunch of OCS 2007 R2 documentation on Technet, but none of it is available for download, so I’ll just sum up some of the recommendations and provide the link so that you can get more detail about them on the site. Oh, wait… There isn’t any more detail!
To start off with, there are two supported upgrade or migration paths:
- Side-by-side migration
- Uninstall/reinstall
Side-by-side Migration
This is the one that sounded like a really good idea for us, due to my limited time to ensure that everything was set up correctly. In this scenario, you stand up a second pool in the same Forest and then migrate users at your leisure.
Pros:
- You have the ability to deploy the environment and validate/test it before you deploy it
- It could be done with minimal downtime for users, theoretically no loss of service
- Pool co-existence allows for cross communication and migration
Uninstall/reinstall
For this install, the process is dead simple. You remove all the old stuff, and you install the new stuff. Of course, there are more steps to it than that, but the idea is pretty simple. I didn’t think that this would be a good fit for us because of the downtime that would be incurred. Okay, who am I kidding? I didn’t want to take the time to listen to people complain about downtime. I think we, as a company, could handle it
Pros:
- It minimizes the use of extra hardware (rebuild on the same platform)
- The installation is simplified when dealing with back ends (more on this in the details)
- This is a good chance to completely rebuild and redesign your OCS infrastructure
The Devil is in the Details
When the dust settles, it’s all comes down to what actually the details of the situation are. In the case of migrating any production system from one version to another, there are going to be a host of issues and minor settings that can either slip through the cracks, or come back to bite you, later. The details always start out as a high level overview and then drill down to individual check boxes and radio buttons.
In Part 2, I’ll cover the details of the Side-by-side Migration and in Part 3 I’ll cover the Uninstall/reinstall details. More to follow!