I visited the Apple store one weekend for other reasons, and asked them about their iMac stock, you know, since I was already there. They don’t carry the upgraded model that I wanted (no surprise) so I’d have to order it online and wait. And that’s when the fun began…

When we returned home from the Apple store that day, it’s like the Mac Pro just knew. It seemed to retaliate and refused to boot up. Nothing I tried seemed to work – just the normal startup tone and a gray screen. Eventually, after I sucked it up and ordered the iMac, I realized that it was a system drive failure.

The iMac finally arrived and I was all giddy setting up my new toy. The screen is ridiculous. I just wish it was under better circumstances – I wanted to migrate my data over to it more gracefully, and at my own leisure…

I’ve learned a number of things during the setup of my iMac. First, I already knew that my most recent data backup was not really up to date (my bad), but at least I had something. Secondly, the Library folder is hidden in OS X Lion – so it takes just a little extra effort to migrate my data over to the new machine. And third, the folder structures in Lion have changed – significantly. I can no longer do a simple folder copy from one machine to another in order to “migrate” my data. It just won’t work.

I tried the migration assistant, which worked. Kind of. Since the iMac was already setup with a user account it needed to migrate the data over to a new user account. After that, I tested copying the Mail & Calendar folders over to the original user account now that they’ve been converted to the new folder structure – but that presented with a handful of permissions issues that I need to work through. The Calendar seemed to be mostly OK after that, but Mail just wasn’t quite right and, frustrated, I left it there.

I was actually able to get the old system drive working long enough to grab my Library & a few other folders off of it – so the data backup issue is no longer an issue. Now I just need to get everything Lion-ified.

So here’s my current plan of action (because I know that everyone’s just dying to know):

1. I scavenged another drive and rebuilt the Mac Pro with 10.6 & installed all of the updates.
2. I’ve started “restoring” my Mail, Calendar, and Address Book data back to the Mac Pro in 10.6 format.
3. Once that’s confirmed OK, I need to install my older version of iPhoto, make sure the photo library is OK, then link my iTunes library to the proper location and make sure that’s OK.
4. Then, I need to install the new version of iPhoto so that it’ll update the iPhoto library database. Apparently I decided at the wrong time to upgrade iPhoto – JUST prior to the failure. It didn’t actually install due to App Store connection issues…

That will be the end of the preparation phase. After that, I can go one of two routes:

1. Upgrade the Mac Pro to Lion and migrate the data over from there.
2. Reinstall Lion on the iMac and use the Migration Assistant to hopefully grab my data and migrate it over for me from the Mac Pro.

I’m going to reinstall Lion on the iMac anyway, because at this point I’ve tinkered so much that I don’t trust it’s stability. It’s already started throwing kernel panics.

This effort better be worth it! From what I’ve seen of the iMac and Lion so far, I think I’ll ultimately be pretty happy. If I can ever finish getting it setup.

I think it’s time to move back to Vanilla (again). It integrates so much better, and even though I absolutely loved it the last time I used it, it looks so much slicker now.

I’ve been doing some tinkering, and it’s NOT going to be an easy process. There’s a script that’s supposed to help with the migration – but it fails horribly for me no matter what I do to try to coerce into behaving. I’ve mapped out a lot of the fields (maybe I should actually write all of that down and share it) and that portion isn’t so bad. It’s the differences in the way that bbPress and Vanilla each store the content of the first post of each topic that’s going to be the biggest pain. Thankfully my little forum is pretty low traffic, so I can take my time.

So far I’ve tried a LOT of different approaches, and ruled them all out. I think I have a game plan now, and just need to sit down for a day and get it done. I’m hoping it actually works and I’m not wasting my time. It’s not entirely a waste though – I consider myself a database n00b, and hacking through all of this is teaching me quite a bit.

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.

I want to try to summarize all of the steps that I took in an effort to help anyone out there that’s looking to do this, as well as to document it for myself in the event that I need to do this again in the future. These steps are all specific to my circumstances – which are probably not all that common. However, maybe this can serve as a solid starting point and give ideas on what to think about.

My situation:
I was running WordPress 2.5.1, Vanilla 0.9.6(?) (shame on me for not staying up to date!) with 1 WordPress user, and a handful of Vanilla users. I did NOT have any subdomains setup (I believe this may affect the cookies). I was in the process of moving my website to a newer server and figured that I might as well use this as an opportunity to get things setup properly, integrated, and up to date.

The steps I took were probably NOT the most efficient because I was/am still learning. I’m sure that if you have the knowledge, you could script much of this – and I know the Vanilla/WordPress community would very much appreciate something along those lines.

It’s important to keep in mind that each user, blog post, forum category, comment, etc., each have their own incrementing ID#s that will need to be taken into account when planning your upgrade/migration. Those IDs all correspond to each other, and depending on your situation you may need to import your data in a different order than I have to make things easier for yourself. We’ll come back to this later.

I was starting fresh on my new server which proved to make most things easier. The files on my old server were unusable as they were, so monkeying with the databases didn’t affect anything (just make sure you make frequent backups before/after you do anything – just in case…!). The Vanilla upgrade instructions from 0.9x to 1.1.4 weren’t very thorough, so I kind of worked around them.

I followed the instructions from the Lussumo website here and had to make some adjustments to make everything play well together and work. Here’s a summary with some notes and extra steps, but be sure to read through the Lussumo instructions too.

Be sure to read through everything before starting in the event that you need to change the order of some steps to accommodate your situation.

1. If you’re starting with an older version of Vanilla you’ll need to prep the database. There’s a command that the upgrade script may say that you need to run depending on the version you’re coming from. I wasn’t able to find it in the Lussumo upgrade instructions (and I forgot to capture it during the process. Start the upgrade script and run the sql command if instructed, but stop there.
2. It’s probably best to start fresh. If you have pre-existing installs, backup your databases and drop the tables before starting.
3. The Lussumo instructions recommend installing WordPress first. I’ve found that this may “randomly” give you “500 Internal Server Error”s when attempting to install Vanilla after WordPress. For less of a headache, switch the install order and install Vanilla first.

Here’s a tip: Set your “throw-away” Vanilla admin account username and password to something different than you’re going to set for WordPress. This will help with troubleshooting in the future if you have problems logging in.

4. Install the latest version of WordPress.

During the install, I specified a custom table prefix. I would recommend doing this as well. If you do this, make note of the custom prefix for later steps.

Note that if you need, you can put WordPress in its own folder while keeping your root directory clean. See more info here. Although, this seemed to cause problems with my integration. I think it had something to do with the cookie path because the forum folder no longer resided inside where WordPress was located…(?) so I skipped this particular step.

5. Setup the secret key! This is new in WordPress, so this information is not in the Lussumo instructions. Check here or here for more info. I updated the WordPress wp-config.php file as well as the Vanilla conf/database.php file – but I did NOT update the WordPress “options” database table!
6. Now would be a good time to setup some security precautions while everything is new and easier to modify. The WP Security Scan plugin can help. Change your WordPress database table prefix (as mentioned previously), rename your WordpPress Admin user account, etc.
7. Tell Vanilla to use the WordPress user table by updating the conf/database.php file. If you set a custom prefix, make sure to make the necessary adjustments to the instructions to accommodate that.
8. Run the query to add the Vanilla-specific columns to the WordPress user table.

Leave out the line to add the ‘Email’ column. I’ve found that this isn’t used – perhaps it was at one time. Note that the previous step directs Vanilla to use the already-existing WordPress ‘Email’ column, so why add another one into the mix? If you already have a database backup that has this column in it, then you can leave it – and maybe remove it after your data import.

9. Create the People/People.Class.WordpressAuthenticator.php to setup the authentication. However, follow the instructions from this thread to do so.
10. Update the Vanilla conf/settings.php file to use the new Authenticator. Also comment any lines that refer to the old “LUM” user table if it exists.
11. Run the SQL command to set the WordPress Admin account to be the Vanilla administrative account, or just update the value manually.

Ok. You’re most of the way there now.

12. Make sure you can login to WordPress, and then stay logged in when you navigate to your forum. If not, check the Vanilla cookie domain, the authenticator, and the secret key in the wp-config.php file and the database.php file all match. At this point you should be able to stay logged in on the forum, and be able to browse around as the admin. I have not yet gotten the Vanilla login page to work. That is still in progress.

Once that was done, I had to import my database tables. If you’re fluent enough, you can probably just do this all at once with a large database import. I prefer to do this in steps so if something breaks, I’ll know where to start looking.

13. First, setup the basic structure that the rest of the data relies on. Import the categories, tags, roles, etc.: LUM_CategoryRoleBlock, LUM_Category, LUM_Role, and wp_terms. You can do this by copying the appropriate lines that say “INSERT INTO” from the sql backup file, and pasting them into the sql command field in phpmyadmin. Don’t forget to adjust the table names as necessary.
14. Browse to the forum as the admin and confirm that the roles and categories exist. Do the same for the WordPress tags.
15. Once that was setup, I opened the sql file and literally copied and pasted the data for the forum user accounts into the corresponding cells of the new users table. If you can script this – even better.

I really only had user accounts on the forum, so I transferred that data over to become the new hybrid user accounts. This will be more complicated if you had a number of different user accounts in both WordPress and Vanilla.

User ID#’s are important! If you import a user with an ID of “2″ into the database as user with an ID of “5″, then all of the associated posts will point to the wrong user! This also means that whatever the user ID is for your WordPress admin account, this will also be the Vanilla admin account. So plan this part carefully.

Also important! WordPress does not allow users to change their usernames, while Vanilla DOES! I’m not sure how this will affect WordPress if a user attempts this…

16. Next, WordPress has a second “_usermeta” table. You’ll need to populate this as well. This stores things like First & Last name, WordPress access type, nickname, etc. I don’t yet know how to redirect Vanilla to use this information, so there’s some data duplication. If your users update particular pieces of information, they may need to do it for both applications.
17. Again, perform a search for * users on the forum and make sure that everyone appears as they should. Open the WordPress Dashboard and browse the users to ensure that they look correct with the appropriate access as well.
18. When the user accounts are all imported, then you can begin importing the WordPress blog entries, WordPress pages, and the Vanilla discussions using the same method as the structure items above (wp_posts, wp_term_relationships, and LUM_Discussion).
19. After the blog entries, pages, and discussions are imported, then you can import the comments & replies (wp_comments and LUM_Comment).
20. If you want to carry over the Vanilla user IP history or the WordPress post edit history, you can do that now (LUM_IpHistory, wp_postmeta). I did some pruning to keep the database size manageable.
21. Don’t forget any links that you might have had setup in WordPress (wp_links).

I think that was it! Easy, huh?