(you really can’t just upgrade? 99% of the people I’ve seen it went just fine)
The db changes are negligible. Install 3.0, drop the db and dump yours in. Keep your wpmu-based wp-config.php file and .htaccess file.
It’s pretty much like a backwards upgrade though, as you still have the same database and the new files – which is what an upgrade is.
I’m gonna make a WAG that you had a pretty heftily mod’d 2.9 WordPress install and would rather not repeat old mistakes and want to start fresh. Naaah, never been there 😉 Anyway, so let’s assume you can’t upgrade naturally.
Or would importing and exporting each WPMU blog individually result in a cleaner migration?
That would be the cleanest of the remaining options, but you have the same old risks of weird image locations.
I would try Andrea’s method on a second install, just for grins and giggles first, though.
My first choice was a direct upgrade, but I made some mistakes in managing the 2.9.2 instance that need to be wiped clean and started over.
Plus our environment is a shared one with other enterprise groups, which meant that someone else was managing our OS patch upgrades. After our WPMU server completely failed during one of those upgrades, we decided to split the shared environment into Dev and Prod systems so that OS patches could be tested on Dev to make sure they didn’t kill WordPress. Since the Dev environment didn’t exist prior, and the network tech didn’t have the time to replicate WPMU 2.9.2 on it so we could attempt a direct upgrade (only enough time to drop 3.0 on it), we had to opt for the fresh install and migration.
See, told ya’ it was complicated. LOL
I’ll take your word that the database structure is the same. But one item I neglected to include (sorry) was the fact that we’re changing the table prefix on the 3.0 instance for security purposes and so that it matches what will be our not-yet-installed 3.0 Production instance so we can easily script a mirroring of the data between the Dev and Prod environments.
Will we be able to globally find/replace the table prefix in the exported SQL statements before importing the WPMU database to 3.0 and not experience trouble? Any exceptions to that find/replace that you know of?
Will we be able to globally find/replace the table prefix in the exported SQL statements before importing the WPMU database to 3.0 and not experience trouble? Any exceptions to that find/replace that you know of?
If you do it in SQL itself (phpmysql I THINK can do that via search/replace if crafted right), and change your wp-config.php file to point to the new prefix, that’s all that WordPress needs you to do for it.
Cool. Thanks for the quick responses.
