Migrating Wordpress websites from Webfaction to Opalstack

Yes, you can use your opalstacked.com subdomain (or even a sub-subdomain of it like test.foo.opalstacked.com) to test your WP site before you cut your DNS over.

The general steps should be something like:

1. Create your WP application at Opalstack and add it to a site using the domain or subdomain that you want to use for testing.
2. Import your migration file into the WP site on Opalstack.
3. Configure your WP app on Opalstack to use your testing domain by adding the following to the end of your wp-config.php:

   define( 'WP_HOME', 'http://test.username.opalstacked.com' );
   define( 'WP_SITEURL', 'http://test.username.opalstacked.com' );

4. Test the site on Opalstack until you're satisfied that it's working as it should.
5. Remove the two lines added in step 3 from wp-config.php.
6. Add your actual domain to your Opalstack account and assign it to your WP site.
7. Cut your DNS over to Opalstack.
8. Wait for DNS to propagate. You'll know it's finished when traffic has stopped hitting the site at your old host.

1. Create a new shell user to use as your SFTP user. I'll refer to that user as sftp_user in the remaining steps.
2. SSH to your server as your WP app's shell user and run the following commands to grant access to the SFTP user:

   setfacl -m u:sftp_user:--x $HOME
   setfacl -R -m u:sftp_user:rwx $HOME/apps/wp_app

3. Configure your plugin to use /home/wp_shell_user/apps/wp_app as the directory path.
4. When you are finished with your migration, remove the ACL with:

   setfacl -x u:sftp_user $HOME
   setfacl -R -x u:sftp_user $HOME/apps/wp_app

My experience mostly following/detailing Sean's 20Jan algorithm:

1. Made Opalstack WP app on throwaway/testing subdomain (say: migrate.myaccount.opalstacked.com). I UNTICKED the default <site URL managed>, not sure if this matters or not.
2. With FileZilla deleted all files in the app and uploaded AkeebaBackup WP archive (.jpa) and unpacker (kickstart.php) with most settings obvious (db, username, ... ) and/or already correctly ticked (e.g., SetHandler will be deleted from the .htaccess, see https://community.opalstack.com/d/44-wordpress-white-screen-limitinternalrecursion-error ). DIFFERENCE: I unticked all database replacements of (old-live-url) to (new-test-url) because eventually will delete test-domain anyhow. If the old website has "wp-" as table prefix, don't fix that during migration as some parameter values will get screwed up (e.g. an uncommon plugin with "wp-" in its name messing up autoreplace in pref_options & pref_usermeta).
3. No step3 as AkeebaBackup already did.
4. 5. 6. 7. 8. Unchanged.

I'm using AkeebaBackupWP because I'm used to AkeebaBackup for Joomla, where they have a reputation for very good quality code and development. The WP version doesn't appear in the WP plugins list for reasons they explain, so downloaded directly from their website.

I used to have Duplicator but hated their setup often (an installerscript+archive pair, just like Akeeba, but the script is unique to the archive for no good reason; and without datetime stamp and siteURL automatically appended to the script name, matching it to its archive was a nuisance). Also (non-WebFaction issue!) larger WP site the "Duplicator Package" creation error'ed out for using too much resources.

On a sidenote, when you're trying multiple cloning/backup plugins, each inadvertently backs up the other's backups so it gets inordinately large if you forget (or cannot) exclude the others' backup location when making an archive/backup/package/whatsamacallit.

I tried WP Staging but that seemed to insist on a staging sub-directory not allowing migration/staging on independent domain as needed here. [Maybe my fault, interpreting "staging" too broadly.]

In any case I'd suggest a look at AkeebaBackup-for-WP to minimize the (Sean's words) "migrate a site without some sort of export/download/upload/import" dance. I find their options both before (configuration) and after (during restore) vastly more clear and useful.

I just did migrations of several Wordpress sites to Opalstack. Maybe my solutions were quite simple (ecommerces etc anyways) but i managed to do it with:

1) Create a new PHP app in Opalstack (and domains and routes)
2) Create a new Maria DB database in Opalstack
3) Navigate (ssh) to PHP app's root.
4) Use scp to fetch all data from Webfaction (scp -r you@you.webfactional.com:webapps/yourapp .)
5) Wait until it had everything fetched (later on i used TAR to create one tarbal insted of transferring slowly thousands of files but this works too..)
6) Log in (ssh) to webfaction.
7) Create sql dump of your database. Use command mysqldump -u your_username -p [databasename] > dump.sql
8) Use scp to fetch that dump to your opalstack home folder
9) Use mysql command line tool to import sql dump (mysql -u your_username -p [databasename] < dump.sql)
10) Update wp-config.php regarding database username / password
11) Point domains to Opalstack
12) Get coffee (wait for DNS changes to propagate)
13) Enjoy your sites live at opalstack.

If you want to test it first before pointing your live domains at it, stop at step 11 and point some test-domain there. In that case you need to change some settings too, i'm not sure if you can define site host and url in wp-config (to override those in database) or do you actually need to change settings in the database. Anyway, its quite simple.

Not sure if this helps anyone but just wanted to share my way as using those migration tools feel so complicated and kind of "blackbox" when it comes to problems you might encounter.

(Please note: check mysqldump and mysql commands syntax from google before proceeding. I did my best to write them correctly but of course no promises).

Fjordis

Just to add a small note to the steps:
In step 10 above, instead of manually override the fileds, which can be intimidating to some of us, we can:

• Back up the new wp-config.php (just created on the new hosting and after having setting up the db)
• Copy the old wp folder over to override the content of the new folder (rm -rf *; scp ...)
• Override the old config with the new config file we've backed up above.