And so it begins! This is my first blog post in a few months…where have I been? As some of you know, I have been the Sr. Architect of the eBay SharePoint 2010 Upgrade Project. One of 3 *major* upgrades that are occuring in the United States in 2011. I will be presenting a series of blog posts on how we did what we did and what challenges we ran into over the project. This is the first of about 15-20 blog posts of material you have not seen before on any MVP, MCM or anyone else's blog post because I know for 100% fact, we were the first to do many of these things! Which makes me think we were the first to really do a major upgrade with all the pieces (DR, DMZ, data center move, firewalls, etc).
First, a little background. The project started in early March and we were given a target completion date of mid July. Several vendors bid on the process, but none had a response as deep and technical as ours, with several other carrots and goodies built in. Also, all of them but ours said it was impossible to do in 3.5 months. Many quoted 3x as long and 4x as much in price..WOW. I was also well known by the eBay team for my work at other companies and the ACS SharePoint Courseware. So my reputation preceeded me, which is good and bad depending on who you are (wink wink to Microsoft).
I started off the project in a very Avanade like manner (I worked at Avanade for about 1.5 years) using the ACM methodology, which is very similar to Microsoft's MOF. The phases include:
- Envisioning
- Planning
- Executing
- Stabalizing
- Deploying
As part of the Envisioning phase, I utilized a series of tools that I had built over the past few months that would do a DIFF of their SharePoint servers. I will have a whole blog post on this tool in the next couple of weeks, and I can tell you right now, MCS was drooling to get their hands on it. This tool determined EVERYTHING they had done to the environment. Using this data, I was able to map it to the code and solutions and determine what items we didn't have code for. This was a great process step as we learned where the code was, what it mapped too and where it was used. All very vital elements to making sure the upgrade would be a success.
As part of the Planning phase, we needed to start to get an idea of the reasons behind moving to SharePoint 2010 and what changes MUST be made to the environment moving forward. This evolved into building out a massive Governance document FROM SCRATCH, utilizing elements from our ACS Governance course. It is much more details than anything out there today (sorry Nuedesic, Slalom et all). This doucment really got the converstations going between the management and us to figure out what really had to happen and what the final Farm needed to look like. We also had to identify what code needed to be refactored (and let me tell you, don't ever hire an accounting company to do SharePoint code – some of the worst code I have ever seen).
The executing phase, my favorite phase! Once we knew what needed to happen, we started to do trial upgrades on the envrionments. As part of this, we needed a moc development 2007 environment and a 2010 environment. This was not an easy task. There were several elements such as custom code, 3rd party applications and just a lot of random changes to the SharePoint root that weren't really documented. Once we installed everything we thought we needed, it became impractial for us to click on every page in the farm to determine if there were any issues/errors. Utilizing another tool I had built from other projects, I modified it to hit every page in the farm and record if any errors were occuring. It gave us back nearly perfect data. We were able to find several components that needed to have extra settings or code installed. As part of this entire process, I started to create the most amazing document of the project…THE PRODUCTION BUILD GUIDE. This document has every single step for a network/server admin to perform to get the farm installed and up and running with no interaction from us. This document is pure GOLD. We utilized this document to build out two more environments, QA and STAGING. By this time, I and my friend Satya had built out and upgraded the environment 4 times (you should expect at a minimum to do the same).
Stabalizing. This was probably the most important step of the project. As a consultant, I can make anything work and fix any error, but when it comes to the functionality of the sites and components, I can't possibly know that. This means that business owners must step in and look at the QA and Staging environments to determine if their components are working correctly. In the end, everything worked out fine due to the stellar team we had, but honestly, we could have given alot more time to this vital piece.
Deployment: Getting the hardware installed was somewhat of an easy part of the process, one of the hard parts was specing out the hardware that would be needed to support 10s of thousands of users. I did the first configuration of the hardware and then eBay decided to bring in some MCS folks just to validate. They unneedingly added in double the memory to the WFEs and APP servers, but hey…memory is cheap so blah (By the way, utilization of the servers shows my config was spot on). Another thing we had to deal with was the movement of data centers. We needed to move alot of large content databases to a new data center. Our upgrade window was 60 hours. I'll tell you, trying to ensure that a massive farm environment is only down for 60 hours is a REAL challenge. We had to get really creative to make that happen. I brought a lot to the table in terms of getting things into that window. As part of the deployment phase, we needed to build a project timeline with all the steps of the build guide in it. Each step was a taks with its respective timing (thank god MS Project can do hourly). After I had built out this AWESOME document, I realized that tasks had to be started the next monday (this was Thrusday evening of the week). We had to have a mandatory meeting to make sure everyone knew what needed to happen. Everything went through perfectly, the build guide was the document that really drove the project timelines. I'l tell you, every step we did out of order or did not do….bit us in the ASS. I'll never not follow my build guide again!
In summary, the upgrade is complete. The system is running great, but now we have hit the training aspect for the business users. It has been quite a shock (even to me, the writer of the first SP2010 courses for End Users) to learn about all the things that the SharePoint team changed between 2007 and 2010. Some are really great, some are *really* bad. We have had numerous tickets coming in asking how to do this, how to do that and what the heck is this "ribbon" thing. Next phase is to build out custom courseware for the users using the great tools we have built at ACS and have utilized for other customers like Exxon Mobil, Abbott Labs and very large government organizations.
It has been/was a GREAT project. And although the title of the blog is "How I Successfully Upgraded eBay to SharePoint 2010", you can't do something like that alone (you need at least 4-5 superstars). The team at eBay was OUTSTANDING to work with and I have to say, the stars aligned for this project to be succesful. I am confident, no one else on the planet could have executed like we did, I am truely grateful to eBay and the 3rd parties (Corasworks, AvePoint, etc) that we had to engage with on the pr
oject. Only one person on the team actually has another public blog and that is Maarten Sundman. He was pivotal in a lot of our code review, code modification and branding aspects of the project. He was also a "get it done" type of person, which is great to have on a project like this.
Watch for the next blog post in this KILLER series,
Chris
Also, come find me at the SP Conference, we will have a session on our eBay upgrade project, feel free to ask some deep and technical questions at the session!
And lastly, if you need help with your SharePoint Upgrade, there isn't anything I don't know about the process, drop me a line and I'll be happy to help!
Continue to next blog post in this series – Upgrading UserProfiles – the non-database attach method