I didn’t make any changes to the forum, though I have been attempting to integrate WordPress with a new install of Vanilla. I didn’t think I had made any changes that would impact bbPress, but apparently… I did?

Check back later this weekend. Might need to continue moving forward with the Vanilla install and manual data migration.

This is a very long, and involved process – so far (it’s still in process) using nothing more than out of the box commands, and SharePoint Designer.

The original data is in a single WSS site collection. Their end goal is to break things up and better organize their content using multiple site collections. Initially we were hoping to be able to use stsadm’s export/import to migrate the original sites over individually, and directly into their end destination in MOSS. After much research and testing, that does not appear to be possible.

• The “backup” and “restore” options for stsadm are available in both 2003 and 2007, but they will only work for an entire site collection. This was not an option for us.
• The stsadm “export” and “import” options that will save permissions, versions, and modified meta – is only available in 2007.
• 2003 has “smigrate”, but 2007 does not.
• “smigrate” saves in a file format that’s incompatible with 2007′s stsadm “import” – so we can’t combine the two to go directly from one to the other.
• SharePoint Designer has backup & restore capabilities, but you can’t use it as a method of upgrading a site. The SPD backup on 2003 creates the same file type as the “smigrate” method, while creating the same file type as the stsadm “export” method for a 2007 backup. You can only use SPD’s backup/restore to migrate within the same type of portal, and of the same version (e.g., WSS 3.0 to WSS 3.0, MOSS 3.0 to MOSS 3.0, WSS 2.0 to WSS 2.0 – you get the idea). We need to go from WSS 2.0 to MOSS 3.0, so this is definitely out.

Migration options then become:

1. Backup & restore the entire portal to the new environment. Then perform the cleanup.
• This will do an in-place upgrade of the portal’s content.
• We would either need to take one long “outage”, or do this in batches and backup/restore the database multiple times to make sure we have the most current data.
2. Or the slower, more tedious manual methods:
• Save each site as a template, copy over, and recreate site using new template.
• Save each List and Library as a template individually, and copy them over…
• Or manually recreate each site, and each library, and copy/paste the content across.
• Down sides to all are that the templates have file size limitations (but you may be able to get around this by changing settings in Central Admin).
• It’s SLOW.
• You lose all of the creation/modified meta.
• Web parts will most likely need to be recreated – at least on each site’s landing pages unless you can copy the default.aspx file over without too much fuss.
• Beware of custom columns using these methods if not saving as templates.
• Custom column meta may be lost with file types like PDFs when copying/pasting across.
• Also – you will need to recreate your views if not saving as templates.

The client has already been through a SharePoint upgrade to 2003 – and lost all of their created/modified meta. Retaining as much meta as possible was our priority, so we opted to go the first route. We performed a test migration and had hashed out a plan for the real migration. The steps have since evolved quite a bit through a lot of trial & error. Also, as things progressed we found that some of our previous steps had stopped working properly so we had to get creative and alter our migration steps accordingly.

** Don’t forget to run the pre-upgrade scan tool before starting! **

This process becomes significantly faster and easier if you perform a thorough review of your content, make note of the permission structure (where it’s inherited, where it’s not), plan out the starting location vs. final destination, remove any DVWPs (data view web parts) from web part pages, etc.

Now, let’s get started.

First – Backing Up:
Scheduled an “outage” with the users (in quotes because the data would still be available to view). We attempted to set the site collection as read-only via SharePoint’s commandline tools, but GetSiteLock didn’t appear to be a valid command for 2003? We ended up locating the content database in SQL (2000) and setting the database read-only very similar to these instructions. When we were satisfied that the old portal was no longer being written to, we used SQL to backup the database, copied it over to the new location, and restored it to a new database in SQL 2008.

Second – Upgrading:
The upgrade was actually the easiest part (though I’m sure there’s an easier, more direct method than the following steps).

1. Login to Central Admin and create a new temporary site collection.
2. Remove the database that was created for this site collection.

stsadm -o deletecontentdb -url http://MyPortal/MyTempSiteCollectionURL/ -databasename SPAutoDBName -databaseserver MySQLServerName

3. Set the old portal’s database that was restored to the new environment to be used as the temporary site collection’s database.

stsadm -o addcontentdb -url http://MyPortal/MyTempSiteCollectionURL/ -databasename MyOldPortalsDBName -databaseserver MySQLServerName\MyCustomInstance

• This will take quite a while depending on how much content you have. This is where it upgrades your content.
• We actually had to “deletecontentdb” and then “addcontentdb” a second time during our initial test. Not during the real migration though. If your site collection doesn’t seem to have content, give that a quick try.

Third – Preparations:
We found that we had to perform the following steps to each site to clean things up and “2007-ify” everything.

• In Site Actions > Site Settings
• Reset all pages to the site definition.
• Reset the theme to the default.
• In some cases this is already done.
• In some cases it appears to be done, but isn’t.
• In most cases, it’s very obvious that it needs to be done.
• Inherit the global navigation.
• Grant full control to any accounts that will be used to perform any exports/imports, etc.! This will save headaches.
• It’s a good idea to look through the web parts on your pages for web parts with errors and delete them. Don’t forget to check for this in your “closed” web parts or you may run into warnings/failures in your export/import.

In our case, to help down the road we had to also:

• Add the accounts that we were using to the Site Collection Admins.
• The upgraded portal was not Publishing. We enabled the Enterprise features to have access to the “Manage Content & Structure” functionality.
• Site Actions > Site Settings > All Site Settings
• Site Collection Features > end enable the Office SharePoint Server Enterprise Site Collection features.

Fourth – The Migration!
Initially we exported and imported via stsadm, but it was giving us errors on the first few sites that we tried. I don’t recall the exact details at this point, but we eventually tried SharePoint Designer which seemed to do the trick.

• Open SharePoint Designer.
• If the account that you’re logged into your computer with does not have appropriate access, right-click on the SPD shortcut and “run as…” an account that does.
• File > Open Site > type in the URL of the site to be migrated > click “Open”
• In the SPD menus open Site > Administration > Backup…
• File > New… > Web site
• Specify “Empty Web Site” and enter the full URL to the destination site on the appropriate site collection.
• Site > Administration > Restore…

Voila! If you don’t run into issues with file sizes, or a number of other misc. errors, you have just upgraded & migrated your first site.

Fifth – Oops, Missing Documents:
The above steps seemed to work just fine for a while. Then when reviewing our migrated sites in more detail, we started noticing that Document & Picture Libraries were randomly missing files. Lists appeared fine.

None of the libraries in the original portal had versioning or content approval enabled or required. However it seems as though during the upgrade process SharePoint believed some of the files to be drafts? This is the only explanation that I have been able to think of that makes sense.

The solution was to use stsadm to export the sites. SPD is essentially using stsadm already, but with some default settings. In order to set other options (like setting the version levels to export) you will need to use stsadm:

stsadm -o export -url http://MyPortal/MyTempSiteCollectionURL/MySite/ -filename MyFileName -versions 4 -includeusersecurity

I won’t spell out the details of importing via stsadm because…

Sixth – Oops, Now What Happened to the Meta?
That worked great. For a few sites. Then for some reason (still to be determined?) all of the created/modified meta was reset to the import user account and timestamp.

After further testing, the best combination appeared to be:

1. Export via commandline as above.
2. Using SPD, create an empty site at the destination.
3. Restore using SPD.

Seventh – Where’s the Love for Workspaces?
Workspace migration was a different story. They seem to be tied to their parent site and could not be exported & restored like the other sites. Given that I could not find an option in stsadm to “include children” – I assumed that this was not available. When in fact, stsadm appears to include child sites and workspaces automatically.

Before we figured this out, we started using SPD and checked the option to include subsites. This lost us a few of our files, but in those cases we weren’t overly concerned about the meta and manually copied those over.

Another option (especially if you’re relocating the workspace within your site structure) is to:

• Use stsadm to export the parent site
• Use SPD to create an empty site.
• Use SPD to restore the parent & subsites.
• Use “Content & Structure” to move the workspace from its imported location to its final destination.

Another few notes:
Some sites would duplicate their list items (and in one case, triplicate) on import. When possible, using SPD to perform the import seemed to do the trick. If you prefer the stsadm method, try using the updateversions option.

There are a few other “quirks” that we’ve run into while migrating content, but I’ll save that for the next post.

Update:
For some reason, reverting back to the stsadm import method worked just fine after returning from the weekend. Not sure why this stopped working in the first place – but very happy that it’s behaving now.

Lesson? SharePoint Designer and stsadm are finicky and fragile. When one starts acting up, try using the other to see if it does the trick.

Note that I keep WordPress in its own folder to keep the files/folder structure on my webserver clean… It’s key in this upgrade method.

1. Always make a backup of your WordPress database before proceeding!
2. Manually download the WordPress zip file.
3. Open your FTP program of choice and upload the zip file to the same folder level that your WordPress folder resides.
4. Unzip the WordPress zip file on your webserver.
   • This can cause weird problems if you unzip it on your local computer before uploading.
   • It will unzip it to a “wordpress” folder, so make sure that this is not the folder name that you choose to keep your WordPress files in.
5. Compare the wp-config-sample.php of the new version, to your existing wp-config.php.
   • If there isn’t any new content (like new salt/keys, etc.), then copy your wp-config.php to the new folder “wordpress/”.
   • If there is new content, save the new wp-config-sample.php as your new wp-config.php and copy over your settings from your original wp-config.php. Then make any other changes needed for the new content.
6. Copy your theme folder from the old install to the new install location.
7. Copy your plugins files/folders from the old install to the new install location.
   • The new install already has Akismet and Hello Dolly – so you can leave these.
   • It’s a good idea to verify that your plugins are all compatible with the new version before doing this.
8. Copy over any of the other folders & files from your old wp-content (like “uploads”, “cache”, “backup-db”, etc.)
   • Up through this point, you’re still using the old version and have had zero downtime. You can choose to wait and finish later without having any impact.
9. Rename your old WordPress folder to something else, like “wp_old”.
10. Rename the new WordPress folder to the name of your old WordPress folder.
11. Open your browser and go to YourDomain.com/Your-WordPress-Folder/wp-admin.
12. You will be prompted to update your database if necessary.
13. Verify that everything functions.
14. Remove the “wp_old” folder.

Done! It’s not as fast as the automatic upgrade, but it’s great for the paranoid, or those who prefer to just perform the upgrade themselves.

Enjoy!

Things went… strangely at first. But then I made a few tweaks and it all seemed to work out in the end! Perhaps tomorrow I’ll be able to make acceptable progress on the theme. And maybe bring the forum back online too?