Currently I am using the plugin "All-in-One WP Migration" to transfer websites over from Webfaction to Opalstack:

Old WF website:

  • install "All-in-One WP Migration"
  • Export to file (I do this twice, just in case)

Domain:

  • switch nameservers to OS
  • observe and wait...

New OS:

  • Create WP website
  • install "All-in-One WP Migration"
  • Import file
  • Yay...

////

I am wondering if there is possibly a faster/easier way where I can maybe use my username.opalstacked.com to install the website before I switch the nameservers? Basically I would like to have access to two websites before I switch the NS.

Having two active websites, there might be another migration plugin that can transfer the website without me exporting and importing?

Not that I am lazy, but I have several websites to migrate.

Thank you very much for your suggestions!
Holger

Holger changed the title to 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.

Thank you!
This sounds very good, I will try it out asap.

Just in case: could you recommend a WP migration plugin to avoid the download and upload on my side?

  • sean replied to this.

    Holger Just in case: could you recommend a WP migration plugin to avoid the download and upload on my side?

    I'm not personally aware of any WP plugin that will migrate a site without some sort of export/download/upload/import dance.

      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

        sean
        Wizardry (-; Terminal still makes me pause with awe, but I will try it!
        Thank you very much, this is cool.

        All-in-One WP Migration failed to work for me. The issue is: when you create a new Wordpress site, you must provide an initial user. If the initial user doesn't exactly match the initial user in your old Wordpress site, the migration is unable to overwrite the entry in the User table. I found that Updraft plus backup and restore worked for several of my sites. I was able to correct any User table entries using the Adminer database tool.

          4 months later

          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.

          4 months later

          We now have a migration script that you can run to move your WebFaction Wordpress sites to Opalstack. If you'd like to try it out, just email our support team and we'll help you get started with it :-)

            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 thanks for sharing that! I was planning to post something similar in the coming week but maybe I'll just refer to yours instead :-)

              8 days later

              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.
              16 days later
              Mastodon