1. Home >
  2. Support >
  3. Total Upkeep >
  4. Using Total Upkeep to Migrate WordPress for Staging >

Using Total Upkeep to Migrate WordPress for Staging

Posted on by Harry J
Last updated on

When you have a live website for your business, chances are that you do not want to make changes on that site in the case that it could cause downtime for a number of reasons. For use cases such as this, it is best to create a staging site for your WordPress installation. The following WordPress tutorial will help you understand how to use Total Upkeep to migrate WordPress from your live to staging site using just a few clicks.

By the way, the general steps in this article will work too if you’ve purchased new WordPress hosting and need to transfer your site to your new host.

Don’t have a WordPress installation to use for staging? We offer a Cloud WordPress system that gives you one instance for free if you sign up for BoldGrid Central. If you need additional WordPress sites for staging, mockups or testing, you can upgrade at any time.

Taking a Fresh Backup of Your WordPress Website

To begin the process of migrating your WordPress website to staging, you first need to take a backup of your production site to use for transferring it. The steps below will outline that process for you.

  • In your WordPress Dashboard, navigate to Total Upkeep → Backup Archives
  • Click Backup Site Now

Depending on the size of your WordPress website, this could take anywhere from a few minutes to a half hour.

Image showing how to take a wordpress backup with Total Upkeep

Create an Installation for Staging WordPress

While your backup is running, the next step is to create an installation that you can migrate the WordPress backup to. This can be a local installation on your computer, or you can use our Cloud WordPress system. Where the staging instance lives is completely up to you and should accommodate your workflow. For the purpose of this tutorial, we will explain how to create a new instance using Cloud WordPress for staging.

Using Cloud WordPress for staging is quite simple. Just follow the following steps to begin:

  • Login to BoldGrid Central
  • Click Cloud WordPress
  • Click Create New Install
  • Select WordPress only, and Click Install

Once the installation is complete, you will be presented with a screen that provides your new site credentials, and a link to login to WordPress instantly.

Using Cloud WordPress to create site

Install Total Upkeep on the Staging WordPress Instance

To migrate WordPress to the staging instance using a download link, you will need to ensure that Total Upkeep is also installed on your new site.

  • In the WordPress Dashboard, navigate to Plugins → Add New
  • At the top right, search for Total Upkeep
  • Click Install, then Activate

Image showing installing a WordPress Backup Plugin - Total Upkeep

Once the installation is complete, it will be time to transfer your WordPress backup from live to staging. The next section will walk you through that process.

Migrating a WordPress Backup to Staging

Once your backup on the live website is complete, you can proceed to get a link to the backup to provide your staging instance for site to site transfer. This will save you the time of having to download the backup, then uploading it to the staged site. The steps below will walk you through what is needed to complete this.

  • In your live site’s WordPress Dashboard, navigate to Total Upkeep → Backup Archives
  • On the backup that just completed, click View Details
  • Click Get Download Link
  • Copy it to your clipboard by clicking Copy Link

Getting a link from Total Upkeep to migrate a WordPress for staging

Now it is time to go back to the staging instance you created in Cloud WordPress.

  • In your staging site’s WordPress Dashboard, navigate to Total Upkeep → Transfers
  • Select Destination
  • Paste the download link from the live site into the upload field
  • Click Upload
  • Once the upload is finished, click Restore

Keep in mind, that once you have migrated the WordPress backup and restored it, the login you created for staging earlier will be overwritten by the database backup you took from the live site, so you will be logged out of the staging site once the restoration has finished. To log back in, just use the same username and password combination you have on your live site.

Image showing the process of restoration for WordPress with Total Upkeep

Moving Changes From Staging to Live

Once you have a WordPress staging installation that matches your live site, you can make changes to it and transfer them over using partial, or custom backups. Alternatively, you can also head over to your staging site when there are WordPress updates you wish to test prior to running them on your production website.

Image showing how to make custom WordPress Backups with Total Upkeep

Congratulations, you now know how to create a WordPress backup and migrate a backup to a WordPress staging website. We would love to hear your comments on how you use Total Upkeep to help with your website migrations and other maintenance below!

 

SIGNUP FOR

BOLDGRID CENTRAL  

   200+ Design Templates + 1 Kick-ass SuperTheme
   6 WordPress Plugins + 2 Essential Services

Join For Free
View Premium Features >>

Everything you need to build and manage WordPress websites in one Central place.

14 thoughts on “Using Total Upkeep to Migrate WordPress for Staging”

  1. Peter says:

    Just tried this, and it is not working.

    The problem appears to be that the backup is unzipped over top of the existing contents, yet leaves all non-conflicting existing file structures in place. This is a HUGE problem for infinite reasons.

    For example, on the source I did *not* have the plugin `wpforms-lite`, while on the destination I did. It should not be in the wp-content/plugins folder of the new site after transferring the backup to it… but it is still there. The break for me is inside the CiviCRM plugin, but this incomplete cleaning out of the old code appears to be the cause.

    Just left the same comment on YouTube:
    https://www.youtube.com/watch?v=tfL6mrdB4nA&lc=UgxLwIDyPJ3XUUeCpC14AaABAg

    • Peter says:

      The worst part about this behavior, is that if it breaks in this manner I will never be able to use this as a pipeline from staging to production. Production would break everytime. And I can’t do a fresh WordPress install on production each time I want to push up a new transfer from Staging… that’s insane.

    • Peter says:

      The worst part about this behavior, is that if it breaks in this manner I will never be able to use this as a pipeline from staging to production. Production would break everytime. And I can’t do a fresh WordPress install on production each time I want to push up a new transfer from Staging… that’s insane.

      The error I see in the HTTP logs is from CiviCRM, and is caused by CiviCRM having a hard coded path in a config file, which became invalid after the transfer to a differently named directory structure…

      mod_fcgid: stderr: PHP Fatal error: require_once(): Failed opening required ‘CRM/Core/ClassLoader.php’ (include_path=’.:/home/dh_wrong_user/wrong_website.org/wp-content/plugins/civicrm/civicrm/:/home/dh_wrong_user/wrong_website.org/wp-content/plugins/civicrm/civicrm//packages:.:’)

      The error I see running the wp command “wp option get siteurl” looks like it is all bold grid’s fault:

      $ wp option get siteurl
      PHP Fatal error: Uncaught Error: Call to undefined function wp_get_current_user() in /home/dh_user/mysite.com/wp-includes/capabilities.php:693
      Stack trace:
      #0 /home/dh_user/mysite.com/wp-includes/functions.php(3424): current_user_can(‘unfiltered_html’)
      #1 /home/dh_user/mysite.com/wp-includes/formatting.php(2045): get_allowed_mime_types()
      #2 /home/dh_user/mysite.com/wp-content/plugins/boldgrid-backup/admin/class-boldgrid-backup-admin-core.php(1564): sanitize_file_name(‘boldgrid-backup…’)
      #3 /home/dh_user/mysite.com/wp-content/plugins/boldgrid-backup/admin/class-boldgrid-backup-admin-core.php(1820): Boldgrid_Backup_Admin_Core->generate_archive_path(‘zip’)
      #4 /home/dh_user/mysite.com/wp-content/plugins/boldgrid-backup/admin/class-boldgrid-backup-admin-core.php(3073): Boldgrid_Backup_Admin_Core->archive_files(true)
      #5 /home/dh_user/mysite.com/wp-includes/class-wp-hook.php(305): Boldgrid_Backup_Admin_Core->boldgrid_backup_now_auto(‘theme’)
      #6 /home/dh_user/mysite.com/wp-inc in /home/dh_user/mysite.com/wp-includes/capabilities.php on line 693
      Fatal error: Uncaught Error: Call to undefined function wp_get_current_user() in /home/dh_user/mysite.com/wp-includes/capabilities.php:693
      Stack trace:
      #0 /home/dh_user/mysite.com/wp-includes/functions.php(3424): current_user_can(‘unfiltered_html’)
      #1 /home/dh_user/mysite.com/wp-includes/formatting.php(2045): get_allowed_mime_types()
      #2 /home/dh_user/mysite.com/wp-content/plugins/boldgrid-backup/admin/class-boldgrid-backup-admin-core.php(1564): sanitize_file_name(‘boldgrid-backup…’)
      #3 /home/dh_user/mysite.com/wp-content/plugins/boldgrid-backup/admin/class-boldgrid-backup-admin-core.php(1820): Boldgrid_Backup_Admin_Core->generate_archive_path(‘zip’)
      #4 /home/dh_user/mysite.com/wp-content/plugins/boldgrid-backup/admin/class-boldgrid-backup-admin-core.php(3073): Boldgrid_Backup_Admin_Core->archive_files(true)
      #5 /home/dh_user/mysite.com/wp-includes/class-wp-hook.php(305): Boldgrid_Backup_Admin_Core->boldgrid_backup_now_auto(‘theme’)
      #6 /home/dh_user/mysite.com/wp-inc in /home/dh_user/mysite.com/wp-includes/capabilities.php on line 693
      Error: There has been a critical error on this website.Learn more about troubleshooting WordPress. There has been a critical error on this website.

    • Brandon says:

      Hi Peter,

      Sorry to hear you’re having trouble pushing your site from production to live. Could you open a new topic in the Support Forum so we can look into the issue more directly. Be sure to include your most recent backup archive log. To find your backup log navigate to Total Upkeep<<Tools<<Logs, it’ll have a name like archive-xxxxxxx.log. If you can paste your log results into the Support Forum we can better assist you in troubleshooting the error.

  2. Joe says:

    Hi, so I’ve tried what you suggested and this creates a DB connect error. These are the fields that I commented out in the wp-config for the subdomain (because they contain reference to the main URL):
    define( ‘WPCACHEHOME’
    define(‘DB_NAME
    define(‘DB_USER
    define(‘DB_HOST

    Once commented out the site no longer works and yields: “Error establishing a database connection”

    • Jesse says:

      Hi Joe-
      Try only commenting out the WPCACHEHOME line, and leave the others as-is. The lines DB_NAME, DB_USER, and DB_HOST will be necessary to avoid the error you got. Those values might also be different for your staging site as opposed to your primary site. You may need to contact your web host to find out the correct values to use for those lines for your staging site.

      • Joe says:

        Hi Jesse,

        This isn’t working. Can you tell me what the fields should look like in the sub domain? This is what is there pre transfer:
        define(‘WP_CACHE’, true);
        define( ‘WPCACHEHOME’, ‘/home/username/stage. [domain] .com/wp-content/plugins/wp-super-cache/’ );
        define(‘DB_NAME’, ‘stage_domain_com’);

        This is what is there post transfer:
        define(‘WP_CACHE’, true);
        define( ‘WPCACHEHOME’, ‘/home/username/ [domain] .com/wp-content/plugins/wp-super-cache/’ );
        define(‘DB_NAME’, ‘domain_com’);

        So, as you can see, even if I comment out the cache statement I’m still pointing to the main site db and not the db of the subdomain.

        Now, I did try two more things: A) carefully replaced each field using the previous definitions (from a backup of the wp-config of the subdomain) prior to the transfer. This yielded an error. B) replaced the entire wp-config with a backup prior to the transfer. This also yielded an error (Your wp-config already exists.)

        I tried looking through the logs and they don’t really contain much in the way of detailed information. I was hoping for something more specific as I would imagine that since the task at hand is restoring a a backup from a different domain I’m guessing their should be some sort of a wp-config modification process – yes/no? which does not seem to be happening. correct?

        Tell me if my logic is not correct:
        You have a main site: which contains a wp-config with specific references to the main sites domain as well as it’s database.
        You have a main site database: which contains references to the main site.

        You have a staging sub domain:
        Which when you Transfer the back from the main site (using Transfer, Upload, Restore) the process should automatically rewrite the appropriate lines in both the wp-config and the db so that after the restore the staging Subdomain wp-config and db point the subdomain URL and subdomain db. Correct?

        Also, thought I should mention, I did reach out to DreamHost and I was told because this is a third party product it is outside of their scope and expertise. That said: I am a savvy enough DH user to be able to locate the proper DB information and a savvy enough sql user to query, modify, backup, drop, restore, etc a mysql db. In fact, many years ago I wrote a backup script that did all of this for drupal. I no longer use drupal, WP is much more friendly. But, at first I thought I would dust off that script then I notice TotalUp Keep in my OneClick install, so I figured, why reinvent the wheel (and have to maintain it). Thank you!

        • Jesse says:

          Hi Joe-

          There’s definitely something odd going on. When performing a transfer (again, make sure you’re using the Transfers tab for both your production and your staging site) the following fields in wp-config should not be overwritten:

          $definitions = array(
	'DB_NAME',
	'DB_USER',
	'DB_PASSWORD',
	'DB_HOST',
	'AUTH_KEY',
	'SECURE_AUTH_KEY',
	'LOGGED_IN_KEY',
	'NONCE_KEY',
	'AUTH_SALT',
	'SECURE_AUTH_SALT',
	'LOGGED_IN_SALT',
	'NONCE_SALT',
);

          Here’s two ways you could go about fixing this. First, make a copy of your staging site’s wp-config.php with a different name like wp-config.back, and rename it back to wp-config.php after the transfer is completed. Alternatively, you can exclude wp-config.php from your source backup. Create a new backup on your production site, and click the option to make a Custom Backup, and add wp-config.php to the Exclude list. Then transfer that backup to your new site.

          If you’re still having trouble after those steps, please reach out to our support team directly so we can take a closer look and hopefully resolve this bug permanently for you.

    • Jesse says:

      Hi Joe-
      Sorry about the difficulty! You didn’t miss anything, but the article did need to be updated to clarify that you should use the Transfers tab to upload your backup and restore the migration, rather than the Backup Archives tab. Using the transfers tab will ensure that the Site’s URL doesn’t get overwritten in the database, which is what is causing you to be redirected to your production site.

      • Joe says:

        Ugg, still doing the same thing. I completed deleted my stage site (and deleted the DB). Did a fresh install, then used Total Update as describe to transfer. After being logged out during the restore, when I attempt go to stage.mysite.com/wp-admin I am prompted redirected to mysite.com/. What are the steps for me to debug this? Is there I debug mode or switch I can flip so the background task will write to a log file? Thank you!

        • Jesse says:

          Hi Joe-
          There will be logs from the restoration in your home directory, in a directory called boldgrid_backup. The root cause of this kind of behavior are two options in the WordPress database, siteurl and home. If you’re using the transfers tab to move your backup, it should not overwrite these values in your database. If you have command line access, I’d recommend running the command 

          wp option get siteurl && wp option get home

          to make sure that they both show your subdomain address. You can also use your host’s database administration tool, phpMyAdmin is the most common one. Another possibility is that your siteurl and home is being manually specified in your wp-config.php file. Check that file for lines similar to these, and either delete them or make sure they are specifying your subdomain:

          define( 'WP_HOME', 'http://example.com' );
define( 'WP_SITEURL', 'http://example.com' );

          If neither of these reveal the main domain instead of the subdomain, please reach out via a new support forum thread so we can take a closer look for you.

          • Joe says:

            Thank you for your assistance. Sorry to use to this thread but I did try posting more info to the Support link you offered but I don’t know where that post went and I never received an email reply. I wish I had saved it because there was a good deal of detail in that post.

            So that you know, I am a DreamHost customer so I’m not sure if this has anything to do with my issue? I can’t believe I’m not finding more information on this when I google. Clearly you must have numerous people using TUK for staging?

            What I found was that the wp-config.php has references to the main site (mysite.com). The database (siteurl/home) both have the entry stage.mysite.com). I would attempt to change the wp-config.php manually but that seems dangerous because I’m not sure what else during the migration is not being written properly.

            I did dump the post migrated db (of stage.mysite.com) and searched for internal references to the main site (mysite.com), and I found none, which I’m guessing is a good thing?

            As a quick fix, should I backup the wp-config.php prior the migration and then restore that as the final step? Or should I edit the migrated wp-config.php and manually change the database references?

          • Jesse says:

            Hi Joe-

            So it does sound like the migration was successful in terms of the database. All you’ll need to do now is remove that line from the wp-config in your staging site. By all means, make a backup first, but you can also simply comment out those lines by adding two slashes at the beginning. Don’t modify the wp-config on your live site, just the one in your subdomain.

Leave a Reply

Your email address will not be published. Required fields are marked *

Looking For Something Else?

white icon monitor tablet phone displayBoldGrid Help for
Designers and Developers
white icon of screwdriver wrench rulerBoldGrid for eCommerce
white icon server stackBoldGrid for Hosts