One place for hosting & domains


      How to Migrate Your WordPress Website to DreamHost (In 6 Steps)

      Choosing a web host is typically one of the first decisions you’ll make when setting up your website. However, over time you may come to regret your choice of provider. If this happens, you’ll be faced with the prospect of migrating your website from one host to another.

      Fortunately, that process is more straightforward than it might first appear. This is especially true if you’re moving your WordPress site to a host that will provide a better, safer home for it — like DreamHost! What’s more, this can be done in just a few steps, thanks to our new Automated Migration plugin.

      In this article, we’ll show you how to easily migrate your site to DreamHost in six steps using our plugin. We can’t wait to show you how it works, so let’s dive right in! 

      Easily Migrate Your WordPress Site

      Leave your current hosting hassles behind and get back to focusing on what matters most. Move to DreamHost today with our free, automated migration plugin.

      Why You Might Want to Migrate Your WordPress Website

      DreamHost WordPress hosting plans.
      DreamHost hosting plans provide excellent performance and useful features.

      When we talk about migrating your website, we mean moving it from one web host to another. Typically, one of the first things you’ll do when creating a new site is to sign up with your chosen hosting provider. 

      Typically, they’ll take care of getting your site online, so people are actually able to visit it.
      However, if you decide you want to move your site to a different host after it’s been functioning for a while, you’ll need to migrate all your files and database information. 

      There are many reasons why you might want to migrate your WordPress site to a different host, including:

      • Your website has grown over time, and you need more options, functionality, or space to keep up with it
      • Your current host doesn’t provide the security features or support options you’re looking for
      • Your site is experiencing poor performance or a lot of downtime

      If you feel it’s time for a change, whether due to the above reasons or something else entirely, your first step will be to find a new host that’s a better fit. You should look for one providing excellent performance and uptime, plenty of flexibility and “scalable” options, and top-notch security and support.

      Here at DreamHost, we offer hosting plans that meet all of these criteria and more. You can choose from affordable shared hosting packages, or opt for DreamPress — a fully-managed solution. Either way, you’ll benefit from great performance, lots of useful, WordPress-specific features, and expert support.

      Best of all, migrating your site to DreamHost is a simple process when you use our Automated Migration plugin. 

      Introducing DreamHost Automated Migration

      “The DreamHost Automated Migration plugin.”

      If you’ve decided to migrate your WordPress website, you have several options. As we mentioned above, you can often have your new host take care of the process for you. Advanced users may be interested in manual migration options, such as using WP-CLI. However, in many cases, the simplest option is to use a plugin.

      That’s why we worked with the team over at BlogVault to create a tool specifically designed to help you migrate your site to DreamHost. With DreamHost Automated Migration, not only do you get the ease of using a plugin, but you also know that your migration will be tailored to our hosting services. This also means you won’t have to take the extra step of cloning your website before you move it. 

      Key Features:

      • Enables you to move or migrate your WordPress site to DreamHost.
      • Lets you copy your files and database over to your new hosting account without cloning your site separately.
      • Only requires six simple steps, from installation to migration.

      This really is the simplest way to migrate your website and know that it will fit right into your DreamHost account. 

      Pricing: The DreamHost Automated Migration plugin is available for free to DreamHost account holders. This means that if you’ve recently switched to DreamHost or are considering it, your migration process just got easier and a whole lot more budget-friendly!

      How to Migrate Your WordPress Website to DreamHost (In 6 Steps)

      Now that we’ve covered the basics, it’s time to discuss how to actually perform your site migration. The six steps below will help you move your site from your current hosting provider to your new DreamHost plan.

      Step 1: Prepare for the Migration Process

      Migrating your site to DreamHost (or any web host) is a fairly simple process. However, there are a few tasks you’ll want to take care of before proceeding:

      1. Make sure you’ve updated your WordPress installation to the most recent version. 
      2. Check your themes and plugins to ensure that they’ve all been updated or deleted if no longer in use. 
      3. Choose and purchase a DreamHost plan, or add hosting to your existing DreamHost domain

      After you have all of the above items in place, you’re ready to get started! 

      Step 2: Locate Your Migration Key in Your DreamHost Account

      Once you’ve established your account, log into your user panel and navigate to the Free Migration tab directly from your Home page.

      “Accessing free migration tools in your DreamHost user panel.”

      There, you’ll see where you can click on Generate Migration Key. You’ll need this to complete the migration process. Once you select it, your key will appear below the button.

      “Where to locate your migration key in a shared plan user panel.”

      You’ll need this information for the next step, so it’s best to leave your browser tab open for easy access. It’s important to note that the migration key generator is not available on Virtual Private Servers (VPSs) or dedicated hosting plans. Keys can be requested by contacting our support team or you can manually enter your host details.

      If you have a shared plan where you host more than one website, you may not see the generator in your account. If that’s the case, you’ll need to contact our support team to request your migration key or any additional keys you may need. 

      Locating Your Migration Key in DreamPress Accounts

      It’s important to note that for DreamPress accounts, this process is the same, but your migration option will be located in a different place. In your user panel, you’ll go to WordPress > Managed WordPress in the left-hand menu. You’ll then find a Migration tab among your options.

      “Locating the migration options in a DreamPress account.”

      Next, you’ll see the Generate Migration Key button. Click on this, and you’ll receive your unique key to be used during the migration process. This is the key our plugin needs to access and move your site’s files and database. 

      It’s recommended that you leave this page of your user panel open, and head over to your WordPress website by opening another browser tab. 

      Step 3: Install the Free DreamHost Automated Migration Plugin

      In your WordPress website dashboard, navigate to Plugins > Add New and use the Search field to find the DreamHost Automated Migration plugin.

      “The DreamHost Automated Migration plugin for WordPress.”

      Click on Install Now, and then Activate the plugin once the installation is complete. 

      Step 4: Use Your Migration Key to Start Your Migration

      You’ll recall that we recommended leaving your DreamHost user panel open in another tab. Now you’ll go back to that tab, copy your migration key, and head back to WordPress.

      You’ll see a DreamHost option in your left-hand menu. Click on that, and you’ll be able to add your migration key.

      “The Automated Migration plugin interface.”

      Paste the migration key from your DreamHost account into the Migration Token field. You’ll need to agree to our partner BlogVault’s Terms of Service as well. Once you check that box, click on Migrate.

      Step 5: Track the Progress of Your Migration

      Next, you can either wait for an email from the DreamHost team or watch the progress of the migration in your WordPress dashboard. This will let you know when your migration is complete.

      "Monitoring the migration process.” 

      Additionally, if there are any issues with your migration, you’ll receive the relevant information on this screen.

      Step 6: Update Your DNS Records

      Once you receive notice that your site has been successfully migrated, you should review it within your DreamHost account. If your domain is the same at DreamHost and your old host, you can review this by adding “” to the end of your DreamHost domain. If you’ll be using a different domain name at DreamHost or are using a temporary subdomain, visit our knowledge base for additional steps.

      You’ll also want to make sure that your domain is pointing to your newly-migrated website. This means updating your Domain Name System (DNS) information. 

      You can find DreamHost’s DNS address by going to Domains in your user panel and clicking on DNS underneath your domain.

      “Finding DNS information in the DreamHost user panel.”

      Providing this DNS information to your existing domain registrar will ensure that your domain is pointed at the correct web content, now hosted with us at DreamHost.

      That’s it! Your migrated site should now be up and running. It’s a smart idea to test your new site thoroughly and make sure everything has been transferred correctly. Then you can delete your old site, and enjoy your new quality hosting with DreamHost.

      Make Your Move

      Whether you need help migrating a website, installing WordPress, or vetting web hosting plans, we can help! Subscribe to our monthly digest so you never miss an article.

      It’s Simple to Switch Web Hosts

      Migrating your website to a new host might be a bit of a hassle, but it can be well worth it in the long run. If your current host isn’t up to par, you’ll want to switch to a new host that provides the performance, stability, and security your site needs to thrive. Plus, WordPress users will find that the process can be handled easily using our own Automated Migration plugin

      Source link

      How to Migrate From k8s-alpha CLI to Terraform

      Updated by Linode Contributed by Linode

      The k8s-alpha CLI is deprecated. On March 31st, 2020, it will be removed from the linode-cli. After March 31, 2020, you will no longer be able to create or manage clusters created by the k8s-alpha CLI plugin, however, you will still be able to successfully manage your clusters using the Kubernetes Terraform installer for Linode Instances.

      In This Guide

      You will use the Kubernetes Terraform installer for Linode Instances to continue to manage and support clusters created using the k8s-alpha CLI plugin following the EOL date and beyond. You will learn how to:

      Manage k8s-alpha Clusters

      The k8s-alpha CLI plugin was based on Terraform. As a result, it created a number of Terraform configuration files whenever it created a cluster. These Terraform files are found within the .k8s-alpha-linode directory. You can change into this directory using the following syntax:

      cd $HOME/.k8s-alpha-linode

      If you list the contents of this directory, you will see a subdirectory for each of the clusters you’ve created with the k8s-alpha CLI plugin. For any of your clusters, contents of these subdirectories will be as follows:

      drwxr-xr-x  5 username  staff   160 Dec 11 08:10 .terraform
      -rw-r--r--  1 username  staff   705 Dec 11 08:10
      -rw-r--r--  1 username  staff  5456 Dec 11 08:14 example-cluster.conf
      -rw-r--r--  1 username  staff  5488 Dec 11 08:16 example-cluster_new.conf
      drwxr-xr-x  3 username  staff    96 Dec 11 08:10 terraform.tfstate.d
      • Both of the .conf files are kubeconfig files for this cluster.
      • terraform.tfstate.d is a Terraform state directory.
      • .terraform is a hidden directory which contains Terraform configuration files.
      • is the Terraform module file. This is the most important file here because it will allow you to scale, upgrade, and delete your cluster.


      Scale a Cluster

      1. Open with the text editor of your choice. The contents will be similar to the following:
        variable "server_type_node" {
          default = "g6-standard-2"
        variable "nodes" {
          default = 3
        variable "server_type_master" {
          default = "g6-standard-2"
        variable "region" {
          default = "us-east"
        variable "ssh_public_key" {
          default = "/Users/username/.ssh/"
        module "k8s" {
          source  = "git::"
          linode_token = "<your api token>"
          linode_group = "kabZmZ3TA0r-mycluster"
          server_type_node = "${var.server_type_node}"
          nodes = "${var.nodes}"
          server_type_master = "${var.server_type_master}"
          region = "${var.region}"
          ssh_public_key = "${var.ssh_public_key}"
      2. To scale your cluster, edit the value of the nodes variable. To resize the number of nodes from 3 to 5, make the following edit and save your changes:

        variable "nodes" {
          default = 5
      3. Once your edit is made, move back to the /.k8s-alpha-linode/clustername directory and apply your changes with Terraform:

        terraform apply


        You may need to use the original Terraform version used to deploy the cluster (either Terraform 0.11.X or Terraform 0.12.X). If you do not, you will see syntax errors.

      4. Once this is completed, you’ll see a prompt reviewing your changes and asking if you would like to accept them. To proceed, type yes and Terraform will proceed to make the changes. This process may take a few moments.


        When prompted, you may notice that one item in your plan is marked as destroy. This is generally a “null resource” or a local script execution and is not indicative of an unintended change.

      5. After Terraform has finished, your cluster will be resized. To confirm, enter the following command to list all nodes in your cluster, replacing the string mycluster with the name of the cluster you edited:

        kubectl --kubeconfig=mycluster.conf get nodes
      6. The output will then list an entry for each node:

        kubectl --kubeconfig=mycluster.conf get nodes
        NAME             	STATUS   ROLES	  AGE 	  VERSION
        mycluster-master-1      Ready	 master   21m 	  v1.13.6
        mycluster-node-1 	Ready	 <none>   18m 	  v1.13.6
        mycluster-node-2 	Ready	 <none>   18m 	  v1.13.6
        mycluster-node-3 	Ready	 <none>   18m 	  v1.13.6
        mycluster-node-4 	Ready	 <none>   4m26s   v1.13.6
        mycluster-node-5 	Ready	 <none>   4m52s   v1.13.6

      Upgrade a Cluster

      You may have noticed that the Terraform module file,, refers to a specific branch or git commit hash referencing the remote Kubernetes Terraform installer for Linode Instances module on GitHub. The following section will outline how to upgrade your cluster to the latest version.

      For example, your source variable may have a value that points to the git branch ref for-cli. To perform an upgrade this must point to the latest commit history hash.

      1. Visit the branch of the Terraform module you’re using on Github. Note the commit history and copy the latest hash by clicking on the clipboard next to the hash of the most recent commit. At the time of this writing, the most recent hash is as follows:

      2. Edit to prepare for the upgrade. Update the following section using the hash you copied to appear as follows:
        source = "git::"
      3. To apply these changes, re-initialize the module by running the following command:

        terraform init
      4. Once this has completed, apply your changes with the following command:

        terraform apply


        Depending on the changes that have been configured, you may or may not see the upgrade perform actions. For example, in this case, because the only change was to the Kubernetes version, no actions were taken.

      Delete a Cluster

      To destroy a cluster, navigate to the directory containing your cluster’s files, and enter the terraform destroy command:

      cd ~/.k8s-alpha-linode/mycluster
      terraform destroy

      Terraform will prompt you to confirm the action, and on confirmation will proceed to destroy all associated resources. If this process is interrupted for any reason, you can run the command again at any time to complete the process.

      Create a Cluster

      1. Create a new directory to house the new cluster’s configuration files in the ~/.k8s-alpha-linode directory. In this example the cluster name is mynewcluster:

        cd ~/.k8s-alpha-linode
        mkdir mynewcluster
      2. Create a Terraform module file in this new directory called with your desired configuration. Replace the values for the variables ssh_public_key and linode_token with your own unique values and feel free to change the configuration values for the cluster itself. The example configuration below will create a cluster with a 4GB master, with a node pool with three 4GB Linodes, hosted in the us-east region:
        variable "server_type_node" {
          default = "g6-standard-2"
        variable "nodes" {
          default = 3
        variable "server_type_master" {
          default = "g6-standard-2"
        variable "region" {
          default = "us-east"
        variable "ssh_public_key" {
          default = "/Users/username/.ssh/"
        module "k8s" {
          source  = "git::"
          linode_token = "<your api token>"
          linode_group = "mynewcluster"
          server_type_node = "${var.server_type_node}"
          nodes = "${var.nodes}"
          server_type_master = "${var.server_type_master}"
          region = "${var.region}"
          ssh_public_key = "${var.ssh_public_key}"
      3. Initialize and apply your new Terraform configuration:

        terrform workspace new mynewcluster
        terraform init
        terraform apply
      4. When prompted, review your changes and enter yes to continue.

      5. Once completed, you’ll see a kubeconfig file, mynewcluster.conf, in this directory.

      6. To complete your deployment, you will use this kubeconfig file and export it using the following syntax:

        export KUBECONFIG=$(pwd)/mynewcluster.conf
        kubectl get pods --all-namespaces
      7. Once completed, you should see your new cluster active and available with similar output:

        NAMESPACE     NAME                                            READY   STATUS    RESTARTS   AGE
        kube-system   calico-node-4kp2d                               2/2     Running   0          22m
        kube-system   calico-node-84fj7                               2/2     Running   0          21m
        kube-system   calico-node-nnns7                               2/2     Running   0          21m
        kube-system   calico-node-xfkvs                               2/2     Running   0          23m
        kube-system   ccm-linode-c66gk                                1/1     Running   0          23m
        kube-system   coredns-54ff9cd656-jqszt                        1/1     Running   0          23m
        kube-system   coredns-54ff9cd656-zvgbd                        1/1     Running   0          23m
        kube-system   csi-linode-controller-0                         3/3     Running   0          23m
        kube-system   csi-linode-node-2tbcd                           2/2     Running   0          21m
        kube-system   csi-linode-node-gfvgx                           2/2     Running   0          21m
        kube-system   csi-linode-node-lbt5s                           2/2     Running   0          21m
        kube-system   etcd-mynewcluster-master-1                      1/1     Running   0          22m
        kube-system   external-dns-d4cfd5855-25x65                    1/1     Running   0          23m
        kube-system   kube-apiserver-mynewcluster-master-1            1/1     Running   0          22m
        kube-system   kube-controller-manager-mynewcluster-master-1   1/1     Running   0          22m
        kube-system   kube-proxy-29sgx                                1/1     Running   0          21m
        kube-system   kube-proxy-5w78s                                1/1     Running   0          22m
        kube-system   kube-proxy-7ptxp                                1/1     Running   0          21m
        kube-system   kube-proxy-7v8pr                                1/1     Running   0          23m
        kube-system   kube-scheduler-mynewcluster-master-1            1/1     Running   0          22m
        kube-system   kubernetes-dashboard-57df4db6b-rtzvm            1/1     Running   0          23m
        kube-system   metrics-server-68d85f76bb-68bl5                 1/1     Running   0          23m

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      This guide is published under a CC BY-ND 4.0 license.

      Source link

      How to Migrate from Google Cloud Platform to Linode

      Updated by Linode

      Contributed by

      This guide describes the recommended strategy for migrating your services from a Google Cloud Platform (GCP) VM instance to Linode. The specific steps you’ll need to carry out will vary depending on the software you use, but the high-level outline is generally the same regardless of the nature of your service. The Migrate to Linode section offers other guides which describe migrating particular services in more detail.

      Deciding on a Migration Strategy

      There are three general strategies for migrating from another hosting provider:

      1. Migration Strategy 1: Manually Install Each Service Individually – Recommended Method

        • Create a Linode, deploy a Linode-provided Linux image to it, and copy over only the configuration and data relevant to your services. This results in a Linux environment that is guaranteed to boot normally on the Linode platform.

          Re-installing your services can take time, but any issues that come up when setting up your applications are usually easier to troubleshoot than low-level configuration problems. This is the recommended strategy when migrating.

      2. Migration Strategy 2: Use Configuration Management and Orchestration – Recommended Method

        • If you use configuration management and orchestration tools, like Ansible, Salt, Chef, and Terraform, you can use the same tools to deploy a new Linode instance. You can use your existing configuration management files as a foundation to deploy Linode instances with the same configurations used by your GCP instance.

          We have an extensive configuration management section in our Guides and Tutorials library that you can use to get started with your preferred tool.

      3. Migration Strategy 3: Transfer your Disk Images – Not Recommended

        • Create a Linode and perform a full clone of your existing disks from your GCP instance to the Linode. This will create an exact copy of your disks on the Linode platform. This strategy is not recommended because low-level system configuration files can be different on different hosting providers.

          These differences can prevent your Linode from booting normally. It is possible to adjust these settings sufficiently to allow your Linode to run normally, but getting the right values for these settings can be difficult, and it can be difficult to troubleshoot when they are incorrect. However, if you are confident in using this method, you can proceed to the Transfer your GCP disks to Linode section of this guide.

      Migration Strategy 1: Manual Migration Strategy

      Deploy a New Linode

      There are two considerations when creating a new Linode: which data center the Linode should reside in, and which hardware resource plan the Linode should run under.

      1. Data Center Location

        • To choose a data center location, run speed tests to the different regions that Linode offers from the speedtest page. This page allows you to download a 100MB file from each location. Compare the speed of each download to determine the bandwidth between your location and the data center.

          You can also run MTR tests to the speed test servers at each location (e.g. These tests will report latency between your location and the data center–a lower latency is more desirable.

      2. Plan Size

        • To determine which plan to choose, review the Linode Pricing page. At a minimum, choose a plan which offers enough storage capacity for the data you store on your current GCP VM instance.

          CPU and RAM allocations are also important since a service with a higher workload/higher traffic will require more of each. If you’re not sure what your workload will require, start with a smaller Linode and then resize your plan up or down as needed.

      Deploy a Linux Distribution to your Linode

      Determine the Linux distribution your current GCP instance uses and deploy that to your new Linode. If your current deployment uses an older version of a Linux distribution, deploy the newest version available for your new Linode to ensure the latest security enhancements and software availability.

      For further details on deploying your new Linux image, follow the Getting Started with Linode guide. It is also recommended that you follow the How to Secure Your Server guide once you have deployed your new image.

      Install Software on your Linode

      1. Install the same software stack that is present on your GCP instance onto your new Linode. You can use your GCP instance’s package manager to retrieve a list of all installed packages. For example, if you are using Debian or Ubuntu you can issue the following command:

        apt list --installed
      2. Once you have identified the software you would like to migrate to your Linode, you can reference our Guides & Tutorials to learn how to set up your system’s software on your new Linode.

        For example, if your GCP instance is used to run a WordPress site, you should install WordPress, PHP, MySQl, and Apache or Nginx (web server) on your Linode instance.

      Create a Snapshot of your GCP Data

      Locate and backup the data on your GCP instance by creating a snapshot. Identify:

      • Which software configuration settings should be preserved (e.g. web server, virtual host information, database connection settings, and which files contain these settings, etc.).

      • Where your data is stored on disk (e.g. as files in a directory, in a database process, etc.).

      If your data is stored in a database, you will likely need to perform a database dump. This will result in a file on disk that encapsulates your database data and can be copied over the network as a normal file:

      Use rsync to Transfer Your GCP Data to Your Linode

      • Transfer your data to your Linode using a network transfer tool like rsync. The Introduction to rsync guide is a good place to become more familiar with this tool.

        For example, the following command will upload files from /path/to/source_folder on the current host to /path/to/destination_folder on the new Linode. Run this command from your current GCP instance. Replace example_user with the Linux user on your Linode, and linode_ip_address with your Linode’s IP address:

        rsync -avzh /path/to/source_folder [email protected]_ip_address:/path/to/destination_folder
      • If you have uploaded a database dump file to your new Linode, you will also need to restore the dump file so that your database software can use the data normally. The database guides linked to in the Create a Snapshot of your GCP Data section include instructions for restoring those files.

      Test the New Environment

      When you have finished setting up your software and restoring your data, test the installation to make sure it works normally. At this point, you have not yet updated DNS records to point to your Linode deployment, but there are still methods for previewing your services without DNS.

      Take this time to perform load testing on your new service. ApacheBench is a popular benchmarking tool for web services. If you discover that the hardware resource plan you chose originally is not enough when completing these load tests, then resize your plan and continue testing.

      When you have finished testing, move on to the last step in migrating: updating your DNS records.

      If you are managing your GCP instance with configuration management and orchestration tools, you can use the same tools to manage your Linode. This means you can use configuration management tools to execute a migration from GCP to Linode. At a high-level this process would entail

      • Using an orchestration tool, like Terraform, to deploy a Linode instance(s) of the required size and region. See the Deploy a New Linode section of this guide for tips on choosing a Linode data center and plan size.

      • Using a configuration management tool, like Ansible, to install system software and perform system configurations. In many cases, you could use the same configuration management files to configure your Linode. For example, if you were using an Ansible Playbook to deploy and configure a LAMP stack on your GCP instance, you can likely use the same Playbook to manage your Linode instance.

      • Migrating any additional GCP instance data to your new Linode instance using rsync.

      • Testing your new Linode environment.


      Migration Strategy 3: Transfer your Disk Images

      GCP Prerequisites

      This section contains all of the preparation steps that you will need to complete on the Google Cloud Platform and on your GCP instance in order to migrate your disk images to Linode. At a high-level, you will disable Google specific daemons running on your GCP instance, create and export an image of your instance, and store the image in a GCP object storage bucket.


      While it is possible to migrate a GCP disk image to Linode, due to differences in low-level system configurations between GCP and Linode, you may encounter some unexpected results that require additional troubleshooting steps. Continue with this method only if you are confident in your understanding of the Google Cloud Platform, GCP IAM roles, and GCP disks and images.

      Install and Set Up gcloud


      If you have already installed the Google Cloud SDK on your computer, you can skip this section.

      The Google Cloud SDK gives you access to the gcloud command-line tool. You will need gcloud to create and export an image of your GCP instance. You will create the instance image later on in this guide.

      1. Download and install the latest Google Cloud SDK for your operating system.

      2. Setup gcloud compute by running the following command:

        gcloud init


        gcloud init will guide you through a setup process and ask to use your browser to log in to your Google account. If you do not have access to a browser, you can use the following command to force console only setup. This method will give you a URL to paste into a browser for verification, which in turn, will give you a verification code to paste back into your console:

        gcloud init --console-only

        The setup will ask you for your project id, region, and zone. You can find these values from your Google Cloud Platform account. Check the GCP documentation for a full list of Google regions and zones.

      Create a GCP Object Storage Bucket

      When you create an image of your GCP instance you will temporarily store it in a GCP object storage bucket. Follow the steps in this section to create the GCP object storage bucket.


      Using the GCP object storage service will incur additional charges outside of the cost of your GCP instance.

      1. Navigate to your GCP dashboard. From the left sidebar menu, under the Storage section, click Storage.

      2. Create an object storage bucket. You can follow GCP’s inline steps to complete this process. For more information on GCP object storage access control options, see their official documentation.

      Prepare Your GCP Instance

      Now that you have completed the prerequisite steps, you are ready to prepare your GCP instance for its migration to Linode. This will require creating a root password, turning off Google daemons, and creating and exporting a GCP image.

      Root Password

      GCP instances don’t have root or user passwords setup by default, you will create these so that you can log into your machine after you migrate it.

      1. SSH into your GCP instance.

      2. Once you’re logged into your GCP instance with ssh, run the following command to set a root password:

        sudo passwd
      3. If you want to set a password for your user account, switch to root and then set user account passwords. Ensure you replace username with the username for which you want to set a password:

        passwd username
      4. Return to your normal user, if desired:


      Inspect your GCP Instance’s Disks

      Before continuing with the preparation to migrate, you should inspect your GCP instance for the following information:

      • The number of non-volatile disks located on your instance.
      • The amount of storage space each disk takes up. In the Prepare Your Linode section, you will need to know the size of each disk you would like to migrate in order to select the appropriate plan size for the Linode you will be migrating to.
      • Determine which disk(s) you would like to migrate to your new Linode. You will need to repeat the steps in the Create and Export Image and the Create New Disks and Configurations sections for each non-volatile disk on your GCP instance that you would like to migrate to your Linode.


        At minimum, you will migrate your GCP instance’s boot disk. On a Linux system, without a custom boot disk configured, this is likely /dev/sda1.

      1. To inspect your GCP instance’s disks, ssh into your GCP instance and issue the following command to view disk size on each mounted disk:


        The usable disk space that is reported by df reflects only 90 percent of full capacity.

        df -h

        You should see a similar output:

        Filesystem      Size  Used Avail Use% Mounted on
        udev            3.7G     0  3.7G   0% /dev
        tmpfs           749M  9.9M  739M   2% /run
        /dev/sda1       9.8G  1.2G  8.2G  13% /
        tmpfs           3.7G     0  3.7G   0% /dev/shm
        tmpfs           5.0M     0  5.0M   0% /run/lock
        tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup

        You can also issue the following command, which displays all available block devices:


        Your output should resemble the following:

        sda      8:0    0  10G  0 disk
        └─sda1   8:1    0  10G  0 part /

        In this example, you will create a disk image for /dev/sda1 and you will need, at minimum, 10GB of storage. For more details related to Linode plan size considerations see the Create a Linode section.

      Turn Off Google Daemons

      Before you migrate the instance, turn off the daemons that communicate with Google servers. If you don’t do this, once you move to Linode, these services will continually try to access Google servers and fail if the daemons are still running.

      1. With the text editor of your choice, create a new file called /etc/default/instance_configs.cfg.template file. Copy and paste the configurations in the example file:

        sudo nano /etc/default/instance_configs.cfg.template
        accounts_daemon = false
        clock_skew_daemon = false
        network_daemon = false
        ip_forwarding_daemon = false
      2. Regenerate the instance_configs.cfg file with your changes by running the following script:

        sudo /usr/bin/google_instance_setup

        Verify that the changes took effect by viewing the contents of the /etc/default/instance_configs.cfg file. The [Daemons] section should resemble the file you created in step 1.

        cat /etc/default/instance_configs.cfg
      3. Stop and disable the daemons:

        sudo systemctl stop google-accounts-daemon
        sudo systemctl disable google-accounts-daemon
        sudo systemctl stop google-clock-skew-daemon
        sudo systemctl disable google-clock-skew-daemon
        sudo systemctl stop google-network-daemon
        sudo systemctl disable google-network-daemon
        sudo systemctl stop google-ip-forwarding-daemon
        sudo systemctl disable google-ip-forwarding-daemon


        If your GCP instance was not created with IP forwarding enabled, then you may see a similar message after attempting to stop and disable the google-ip-forwarding-daemon:

        sudo systemctl disable google-ip-forwarding-daemon
        Failed to disable unit: No such file or directory
        [email protected]:~$ sudo systemctl --status
        systemctl: unrecognized option '--status'
        [email protected]:~$ sudo systemctl status

      Stop Your GCP Instance

      In order to create your instance’s disk image in the next section, you will first need to stop the instance. This will prevent any new data from being written to the persistent disk.


      GCP recommends stopping your instance prior to creating a disk image, however, it is possible to keep the instance running while you create your image. See their official documentation for details.
      1. Navigate to your GCP dashboard. From the left sidebar menu, under Compute, click Compute Engine.

      2. Viewing your VM instances, click on the more options ellipsis for your instance and select Stop.

      Create and Export a Disk Image

      You are now ready to create and export an instance image using the gcloud command-line tool. If you have not installed the Google Cloud SDK, you will need to do so before proceeding.

      1. Create an instance disk image with the command below. Replace migrate-gcp-img with a name you want to give your image, test-gcp-instance with the name of your instance’s disk, us-east1-b with the zone for your instance, debian-9 with the distribution image family for your instance, and us-east1 with the region where you want your image to be stored.

        gcloud compute images create migrate-gcp-img --source-disk test-gcp-instance --source-disk-zone us-east1-b --family debian-9 --storage-location us-east1
      2. The output will look similar to the following:

        Created [].
        NAME             PROJECT             FAMILY    DEPRECATED  STATUS
        migrate-gcp-img  speedy-area-263218  debian-9              READY
      3. Export the image to object storage with the command below. Replace lin-docs-test-bucket with your bucket name, migrate-gcp-img with your image name, and speedy-area-263218 with your project id. This process may take a few minutes to complete.

        gcloud compute images export --destination-uri gs://lin-docs-test-bucket/migrate-gcp-img.tar.gz --image migrate-gcp-img --project speedy-area-263218


        You may need to respond to some command-line prompts before the image is exported.

      4. The output will look similar to the following:

        [image-export]: 2020-01-03T18:05:46Z Step "image-export-export-disk" (IncludeWorkflow) successfully finished.
        [image-export]: 2020-01-03T18:05:46Z Serial-output value -> source-size-gb:10
        [image-export]: 2020-01-03T18:05:46Z Serial-output value -> target-size-gb:1
        [image-export]: 2020-01-03T18:05:46Z Workflow "image-export" cleaning up (this may take up to 2 minutes).
        [image-export]: 2020-01-03T18:05:52Z Workflow "image-export" finished cleanup.
      5. From your GCP dashboard, navigate to your Storage Browser and click on the GCP object storage bucket that you exported your instance image to.

      6. You will see your instance image listed. Click on its corresponding more options ellipses and select Edit Permissions from the drop down menu.


        If you do not see the Edit Permissions option, then your bucket may have been created with uniform access controls. To make the image publicly accessible, see GCP’s official documentation for information on making data public. When you have completed the steps listed in the GCP documentation proceed to step 8 of this section.

        Google Object Storage Bucket Edit Permissions

      7. In the dialog box popup, click the Add Item button to add a new row to the table. Select User for Entity, all Users for Name, and Reader for Access. Then click the Save link.

        Google Object Storage Bucket Permissions Add Item

      8. Now you will see that the status under the Public access column for this bucket item is set to Public with a link icon.

        Google Object Storage Bucket Public

      9. Right click the link icon and click Copy Link Address to copy this object’s link address. Paste it into a text file somewhere to save for later. It will resemble the following link:

      Prepare Your Linode

      In this section you will create a new Linode, add a new disk and configuration profile in order to boot the Linode from your GCP instance’s image, import the GCP image to your Linode, and finally, boot your Linode using your GCP instance’s image.


      You will be importing your GCP image onto a raw disk with the direct disk boot option. This will result in a working custom installation; however, it will not support advanced Linode features such as disk resizing or the Backup Service by default. These features require an ext4 formatted disk.

      If you would like access to these features after completing your migration, ensure you complete the following steps:

      Create a Linode

      You will first create a new Linode to import your GCP image to and then, boot the Linode from that image. Before creating your Linode, verify the storage size of your original GCP disk if you have not already.

      1. Log into the Cloud Manager.

      2. Access the Linode create page by clicking Create at the top of the screen and selecting Linode from the dropdown menu.

      3. Create a Linode by making the desired selections on the Linode create page. For more detailed steps, see the Create a Linode section in our Getting Started guide.


        When selecting your Linode’s plan, if you want to have access to advanced features like resizing your Linode and our Backup Service, choose one that will be large enough to hold twice the size of the entire expanded disk image that you created from your GCP instance (not just the size of the compressed tar file). This is needed so that later you can move your installation over to an ext4 formatted disk. Once the move to an ext4 formatted disk is complete, you can delete the raw disk and resize to a smaller plan.
      4. Once the Linode is finished provisioning, power it down. Click on the Running status at the top of the Cloud Manager and select Power Off from the drop down menu.

      5. Disable Watchdog, also known as Lassie, which is a Linode Cloud Manager feature capable of automatically rebooting your Linode if it powers off unexpectedly. Click the Settings tab, then Shutdown Watchdog. Toggle the Enabled switch to Disabled.

      6. Disable your Linode’s Auto Resize capability. Click the Resize tab and scroll to the bottom of the screen. Uncheck the box for Auto Resize Disk.

      Create New Disks and Configurations

      In this section you will create a new disk and boot configuration in order to be able to boot your Linode from your GCP image.

      1. Access your Linode’s Disks/Configs tab.

      2. Under the Disks panel click the more options ellipses next to the main disk (for example, Debian 9 Disk) and select Resize from the drop down menu. Resize this disk to make room for the new raw disk you will create in the next step. The new raw disk is where your GCP image will be installed.


        If, for example, your GCP disk image’s size is 10GB, ensure that you resize the main disk to make enough room for a a new disk that is slightly larger than 10 GB (11 GB, for example). This will ensure that you can safely reboot your Linode from the extracted image (you will complete that step in a later section).

      3. Click Add a Disk and create a new Empty Disk. Give it a label like “New Google”, for filesystem, select raw, and for size, enter a size that will accommodate the entire extracted image. Click the Add button.

        Linode Create New Raw Disk

      4. Click Add a Configuration and setup a new Linode Configuration with the following settings:

        • Label: Google
        • Kernel: Direct Disk
        • /dev/sda: New Google (your new disk)
        • /dev/sdb: select the default swap disk when the Linode was created
        • Root Device: /dev/sda
        • Filesystem/Boot Helpers: disable all of these settings
      5. Click on the Submit button to complete creating the new configuration.

      Import the Image

      1. Click the Rescue tab.

      2. Set /dev/sda to your new disk. In this example, the disk is named “New Google”. Set all remaining options to None.

      3. Click the Reboot into Rescue Mode button. The Linode will reboot into Rescue mode.

      4. Once booting is complete, click Launch Console at the top of the screen. This opens the Weblish and Glish console window. You will be presented with a Finnix rescue terminal and root prompt.

      5. Run the following command to pull your image from Google cloud storage, unpack it, and copy it to the Linode. Replace the URL with the one you copied from your GCP object storage bucket.

        curl -k | tar -xzO  | dd of=/dev/sda
      6. The output will look similar to the following:

          % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                         Dload  Upload   Total   Spent    Left  Speed
        100  667M  100  667M    0     0  1156k      0  0:09:51  0:09:51 --:--:-- 81996
        20971520+0 records in
        20971520+0 records out
        10737418240 bytes (11 GB) copied, 593.648 s, 18.1 MB/s
      7. When this completes, close the console and return to the Cloud Manager. Click the Running status, select Reboot, choose the Google configuration that you created above, and click on Submit.

        Cloud Manager Reboot Into New Configuration

      8. Once booting is complete, click Launch Console at the top of the screen. Again, this opens the Weblish and Glish console window. This time, you should have a regular Lish shell. You should also be able to SSH to your Linode at this time.


        If you are having trouble with ssh starting, you may have to run the following command to start the service from Lish:

        sudo service ssh start

        You may also need to update your SSH server’s configuration file to temporarily allow password authentication. Your GCP instance may have been configured to disallow password authentication and it may not have your computer’s SSH keys stored.

        1. Open your SSH server’s configuration file with your preferred text editor:

           sudo nano /etc/ssh/sshd_config
        2. Find the PasswordAuthentication configuration and set its value to yes:

            PasswordAuthentication yes

        See the SSH guide for more SSH troubleshooting tips.

      Remove Google Packages

      You disabled the Google services from calling out before creating and migrating your image, however, there are a few Google packages that you may want to remove. From the console run the following commands:

      sudo dpkg -r google-osconfig-agent
      sudo dpkg -P google-osconfig-agent
      sudo dpkg -r --force-depends google-compute-engine-oslogin
      sudo dpkg -r google-cloud-sdk
      sudo dpkg -r google-cloud-packages-archive-keyring

      Optional: Transfer Disk to ext4

      As stated above, to take advantage of features like resizing your disks in Cloud Manager and Backup Service, you’ll need to move your new disk to an ext4 formatted disk. To do this, follow the procedures in the Linode Manager Compatibility section of the Install a Custom Distribution on a Linode guide.

      Cleaning Up

      When you’re done:

      Additional Migration Considerations

      Migrating DNS Records

      To direct your visitors to your Linode, associate your domain with your new Linode’s IP. There are two options for moving your DNS records:

      • Use Linode’s fast, stable DNS hosting which is free as long as you have one active Linode on your account.

      • Continue to use your current nameserver authority and update your DNS records with your new Linode’s IP address. You should check with your current provider to see if there are any costs for their DNS services. If you are using your domain name registrar’s nameservers, then they are generally free.

      (Optional) Prepare Your Domain Name to Move

      A recommended first step is to lower the Time to Live (TTL) setting for your domain so that the migration won’t have a negative impact on your site’s visitors. TTL tells DNS caching servers how long to save information about your domain. Because DNS addresses don’t often change server IP addresses, default TTL is typically about 24 hours.

      When changing servers, however, make the TTL shorter to make sure that when you update your domain information, it takes effect quickly. Otherwise, your domain could resolve to your old server’s IP address for up to 24 hours.

      1. Locate your current nameservers. If you’re not sure what your nameservers are, use a Whois Search tool. You will see several nameservers listed, probably all at the same company. nameservers

        You can usually derive the website of your nameserver authority (the organization that manages your DNS) from the nameservers you find in the Whois report (e.g. corresponds with Sometimes the labeling for the nameservers is not directly related to the organization’s website, and in those cases you can often find the website by plugging the nameserver into a Google search.

      2. Contact your nameserver authority for details on how to shorten the TTL for your domain. Every provider is a little different, so you may have to ask for instructions.

        Updating TTL at common nameserver authorities

        Most nameserver authorities will allow you to set the TTL on your domain or on individual records, but some do not allow this setting to be edited. Here are support documents from some common authorities that mention how they manage TTL:
      3. Make a note of your current TTL. It will be listed in seconds, so you need to divide by 3600 to get the number of hours (e.g. 86,400 seconds = 24 hours). This is the amount of time that you need to wait between now and when you actually move your domain.

      4. Adjust your TTL to its shortest setting. For example, 300 seconds is equal to 5 minutes, so that’s a good choice if it’s available.

      5. Wait out the original TTL from Step 3 before actually moving your domain–otherwise, DNS caching servers will not know of the new, lower TTL yet. For more information on domain TTL, see our DNS guide.

      Use Linode’s Nameservers

      1. Follow Linode’s instructions on adding a domain zone to create DNS records at Linode for your domain. Recreate the DNS records listed in your current nameserver authority’s website, but change the IP addresses to reflect your Linode IPs where appropriate.

      2. Locate your domain’s registrar, which is the company you purchased your domain from. If you’re not sure who your registrar is, you can find out with a Whois Search tool. nameservers

        Your registrar may not be the same organization as your current nameserver authority, though they often are, as registrars generally offer free DNS services.

      3. Log in to your domain registrar’s control panel and update the authoritative nameservers to be Linode’s nameservers:


        Updating authoritative nameservers at common registrars

        The following support documents describe how to update the authoritative nameservers of common registrars:
      4. Wait the amount of time you set for your TTL for the domain to propagate. If you did not shorten your TTL, this may take up to 48 hours.

      5. Navigate to your domain in a web browser. It should now show the website from Linode, rather than your old host. If you can’t tell the difference, use the DIG utility. It should show the IP address for your Linode.

      6. Set reverse DNS for your domain. This is especially important if you are running a mail server.


        If you’re having trouble seeing your site at the new IP address, try visiting it in a different browser or in a private browsing session. Sometimes your browser will cache old DNS data, even if it has updated everywhere else.

      Alternative: Use Your Current Nameservers

      If you’d like to continue with your current nameservers, update all of the DNS records that are assigned to your old host’s IP address to use your new Linode’s IP. Contact your nameserver authority for instructions on how to update your DNS records.

      Updating DNS records at common nameserver authorities

      The following support documents describe how to update DNS records at common nameserver authorities:

      After DNS propagation has finished, set reverse DNS for your domain. This is especially important if you are running a mail server.

      Next Steps

      After completing the steps above, your service should be fully migrated to Linode. It is a good idea to wait a few days before cancelling your shared hosting service to make sure that everything is running smoothly, and to confirm that you don’t need to obtain more files from your shared host.

      This guide is published under a CC BY-ND 4.0 license.

      Source link