So I recently had a fun opportunity to migrate a custom from WSS 2.0/Server 2003/SQL 2k to a Foundation 2010/Server 2008 R2/SQL 08 implementation. Learned some good things with it I thought I would share for those out there who may try the same thing.
First and foremost, simple is NEVER simple. This WSS 2 site had a single site collection with about 40 sub webs. 200 megs of content. It was completely vanilla, no styles, no use of designer, no custom anything. Not even the Fab 50, or smiling goat components (which I ALWAYS run into with WSS 2.0). So simple right? lol.
Second, because of rule 1 do NOT skimp on the dots on the i’s and crossing the t’s. I was anal and did a slew of backups before, and after the pre-upgrade check and many other steps. it saved me bigtime.
WSS 2.0 to WSS 3.0
Should have been a snap. But the server was about 2 years behind on patches.Also the server was the primary DC for the company as well as their exchange server. So the stakes were a bit high on keeping her up and running. To better raise my chances, before I migrated I applied all up to date patches on the OS and SQL, very carefully because of the critical role of this server in the client environment.
So far so good, except it took 3 hours. Due to budgetary concerns I had to do an in-place over top of the prod system (yeah did not make me warm and fuzzy either but sometimes budgets trump best practices and you do what you can do). Ran the in-place, seemed fine. Then I realized that the content webs did NOT come across into WSS 3.0. Further more, and I have NO clue how this happened, when WSS 3.0 upgrade ran, it upgraded the DBs and somehow put them into a Schema/format that SQL 2k said was a future release so SQL dropped the DBs and they were unattached with SQL refusing to attach to them. So at this point we are completely down. SQL 2k will not allow a restore, or reattach cause the DB is in post 2k format according to SQL. My IIS web app is orphaned (with host header and SSL settings) and life is looking grim.
Now we had taken a virtual snapshop before doing any of this so completely losing everything was not happening, I just did not want to lose 4 hours of work I would have to redo anyway. First task resolve SQL issues. Installed SQL 2005 Express on the WSS 3 box, created a completely new instance and reattached the old content DB there. Then plugged it into the WSS 3.0 farm and the 3.0 migration took. Heart rate went back down to normal levels. Step 1 of migration was complete. Minus the Web app configuration.
WSS 3.0 to Foundation 2010
With the mess of the WSS 3.0 migration out of the way it was time to do some real migration. And this time, things ran MUCH smoother. Took a backup of the WSS 3.0 Content Db, copied that to the Foundation 2010 SQL box and restored it to a proper DB name (at this point it still had the WSS 2.0 name to it). Then use powershell to connect the 3.0 DB and all the content was in.
We left it in 2007 visual upgrade mode to allow users to adapt to the new URL and ensure the environment was stable. A couple days down the road we will be doing the full visual upgrade to 2010 and finalizing the system.
One additional thing at the end of this while i was logging in and new users were logging in fine, the majority of old users were failing authentication. On the Foundation 2010 server Security log there were Failure Audits for all these users with the event ID:4625. Try as we could, we could not get past these. What finally solved them, on each user machine the client had them clear their browser cache. Once that was done, it started working like a champ. seeing as we ported this from WSS 2.0 to 2010 overnight along with the SPUsers in the content DB, I suspect there was some type of token cached from the WSS 2.0 environment that caused the issue. However, should you run into this have the users clear their browser cache and that may clear it up for you.
What I took away from this:
- Simple is never simple. So Plan, even for the simple migrations. Get the Technet and MSDN articles down and at your fingertips to allow you to be nimble when you need to be. Having those at the ready saved me a lot of time on search engines. The other thing is plan all the way to the end. This means finalization steps like configuring backups on the new environment. If you end up in a long running migration process like this turned into, you may not be clearly thinking at the end and may just overlook it. I can think of nothing more depressing that going through all that and finding the system down and data lost the next morning.
- Backups are crucial, at no time was I ever in danger of losing the data. My worst case scenario was restoring the virtual back to the state before the migration effort and losing MY time. While my time is valuable, it is no where near as valuable as production data.
- The effort could have been sped up if I had downloaded all the potential updates (SQL 2005 being the big one here) ahead of time, and better scoped out the WSS 2.0 environment. Doing those patches days ahead of the migration would have certainly simplified life and prevented the marathon migration effort.
Anyone have any other guidance/suggestions/experience, feel free to post up.
Happy migrations everyone!