Imagewize Migration – WordPress Migration Case Study

We just finally did it. The Imagewize Migration is a fact! Imagewize has become IMWZ starting today. We have been thinking about a rebranding for quite some time, but we are finally taking steps. Today we migrated to And I must say it went pretty smoothly. Let us tell you how we did the WordPress Migration so you can learn from this.


You must know that we moved to DreamPress, Managed WordPress hosting with Dreamhost. It is an amazing setup to run your WordPress business and I will highlight features ast the end of this post. There was one issue we bumped into as was due to WP Rocket DreamPress compatibility issues with DreamPress. This as the latter works with Varnish caching. So this is something you may no run into, but the rest is very similar to most WordPress migrations.

BackupBuddy Backup

We used BackupBuddy to backup the site and migrate it from the Dashboard to the new location. That saved us time using SFTP to SFTP everything to our local PC and then again to the new location. Both locations are in the US and from Bahrain using my meager Batelco ADSL here at Amwaj Islands would have been a massive PITA.

Wordfence Firewall Issues

We did run into one issue with Wordfence. We blogged about the fact that BackupBuddy and Wordfence do not like each other much before. It spoiled the database migration completely. As soon as the necessary files were unzipped we had a JSON error. One I could not just copy as it was in a BackupBuddy warning backup:

Error #839983: Failure parsing returned server data. SEe Status log for more details: `Unexpected token < in JSON at position 0`.
Resonse: `<br />
<b>Warning</b>: Unknown:Failed to open stream. Permission denied in
<b>Unknown<b/> on line <b>0</b><br />
<b>Fatal error</b>: Unknown: Failed opening required '/home/imgvps/'

There was an error because Wordfence was trying to load wordfence-waf.php from old server. Had to deactivate and remove Wordfence, empty cache before I could rename the file. Not sure if plugin removal was needed though, but did anyways. Just renaming wordfence-waf.php or .user.ini did not do the trick. Could have been a caching issue though. But hey, I would recommend removing Wordfence before you move. Or you will get stuck just like me.

301 Redirect from old to new domain

All our visitors and clients trying to reach us at the old website will be properly redirected to the new domain name. This we did with a fairly standard Apache redirect at the top of the .htaccess file:

#Options +FollowSymLinks
 RewriteEngine on
 RewriteRule ^(.*)$$1 [R=301,L]

As we only change the domain and not the permalinks the redirect RewriteRule was pretty straightforward. We will remove the site at the old domain as soon as we can. Will also allow us to reduce the VPS intake of RAM and save us some $.

The new problem I faced was this: we were redirecting the old site because we changed our name (and with it, our domain). While we’ve tried to let all our existing customers know about the name change, we still want to redirect the old site to a specific page of the new site designed to let them know that we are still the same people doing the same thing (so they would not think we had been acquired or otherwise changed).

Feedback Reader

Feedback from read of this post Bill Weber @ on a related redirect issue I decided to add here for now. If I do find another post it was more about I will move this piece to that post.

With the code you provide in your post, it redirected perfectly to the page we wanted IF you tried to access the primary .com home page of the old site, but redirected to the home page (rather than the desired page) of the new site if they tried any other link on the old site.

After another hour or so of fruitless searching, I finally figured out that I simply needed to remove the trailing “$1” in the last line of your code to get the behavior I was looking for: all pages on the old domain forwarding to a single page (not the home page) on the new domain.

The very slight modification I did to what you provided is below:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^(.)?wp-login.php(.)$
RewriteCond %{REQUEST_URI} !^/wp-admin
RewriteRule ^(.*)$ [R=301,L]

Google Webmaster Tools Change of Address

You can also tell Google that you have moved. For the property that has changed address you can register just that. Click on the top right button to register the change.

Change of address

After that you can follow the steps below and:

  • pick the new domain,
  • confirm the 301 redirects properly
  • check that the verification code still works properly
Webmaster Tools Change of address Steps

Google Analytics Property & View Changes

Do not forget to update your Google Analytics property and view settings. These need to use the new url as well. Otherwise you will see a quick drop in traffic post domain name migration. We did it by going to the Google Analytics account in question. There under admin you can change the url for the property and for the view(s) you have.

property url

Google Analytics Filters Check

Please be certain to change your filters if you have additional views with filters like a valid hostname filter. Otherwise it will not register any visitors as it will not accept the new domain name. We now have:


but had the first filter hostname as and had not adjusted it right away. Fortunately we have multiple views so we still had data, but lost some for this spam free view. The second allowed host is for our CDN. We may adjust the name there, but we will keep it for now.

WP Rocket Compatibility

To make WP Rocket Cache work properly with DreamPress Varnish we did need to activate a separate plugin provided by WP Rocket. This plugin had to be added to

  • be able to empty Varnish cache on emptying cache using WP Rocket,
  • remove Varnish removal as an option as it is no longer needed,
  • ensure minification compatibility and
  • remove the HTML expires rules from .htaccess

DreamPress Goodies

The additional advantage we have now is that we were now part of a Dreamhost one-click installation. So we were able to move over to DreamPress. It is really amazing. It allows you to focus on your site and let them manage core updates, server updates. And this with a setup with one server for files, one for the database and one for Varnish caching.

Design Changes

We will be replacing the logo and favicon this week. Just some final tweaking to do so to speak. The weekend was good for a migration so we went for it. We promise you will see a new shiny logo and favicon soon. This besides the new icons for social media. The Facebook Page has been renamed already, but will get a facelift too as soon as the design part is done.

Changing Site URL with WP-CLI

If you quickly need to change the WordPress site url on a VPS or dedicated server with WP CLI installed or installable WP-CLI is your friend. It is a great command line based option dealing with url changes during site migration. There are of course great plugins to help out too, but believe me with full server access or VPS access a command line tool like wp-cli can deal with the url issues in no time!

Development to Production

If you just need to move the database from development to production as you will go live with the content you can do this. You replace the database on the production server with the one on the development box. Then you use WP-CLI and then change the urls in a jiffy. Just ssh into your production server and run the search-replace command like this:

wp search-replace '' '' --skip-columns=guid

Afterwards all will work well. All content will be loaded properly with the right urls. Images should be loaded too as long as you moved those to the server as well. I do this often for all new Trellis LEMP box setups at Digital Ocean and I can tell you it works really well. A lot better than the WordPress Importer tool from the Dashboard. Though the importer does work quite well from the command line you still need to deal with images.

Dry Run – Better Safe than Sorry

You can also do a dry run first with –dry-run added. This to see what urls will be changed and to make sure you are running the correct command. So the command will then be

wp search-replace '' '' --skip-columns=guid --dry-run

Actually pretty smart to use. Especially if you are talking a lot data and or complicated url. Better safe than sorry. Will safe you restoring it all with or without backup.

Backup, backup!

Do remember it is always good to backup the database before you do this. Just in case you do not fill in the urls properly once you run things live. Sequel Pro is a great OSX database management tool for backups, changes and replacements of databases.

There is more..

You can do way more with wp-cli than just searching and replacing urls. You can set up full WordPress installations, install themes, plugins, add fields, backup setups and more. I will be sure to write some other applications again as soon as I have the time. Stay tuned!

Trellis Media Migration

When you work with a Trellis WordPress LEMP setup to manage a client site migration is set up pretty well. You can use scripts for server provisioning and site deployment. However, there are certain things that will / should not be in your git repository. These items will not be synched. Media in the uploads folder is one of them. Let me explain the reasons behind this and how Trellis media migration can be achieved.

Bedrock Ignores Uploads

Certain files and or directories are ignored by default using a .gitignore in Bedrock. This is because they will not stay the same locally and and live. They are often too big to be kept there or they are managed and installed by composer. The complete ignore list for Bedrock is:


# Application

# WordPress


# Dotenv

# Vendor (e.g. Composer)

# Node Package Manager

# Vagrant

One of the elements that are not in the repository and ignored using a .gitignore file are all the images and other media in the uploads folder. This is because they often take up too much space in a repo. And as said because often content on local server and remote server are not the same.

Synchronizing Media

Sometimes you do want to synch local media with the staging or remote server though. You may have set up a site with basic pages and posts including images and other files locally. In that case you do not just want to migrate the files and start from scratch. You then want to move the files, database and all media. To move all media files there are two things you can do. You can either sftp all files to the server as admin or use an Ansible Playbook to synchronise them.

SFTP Uploads

You can use SFTP and SCP to upload all to the server. Then you use SSH to move it to the right location and change the rights and permissions. Swalkinshaw suggested the following here:

  • SFTP uploads to /home/admin/uploads
  • SSH in as admin ssh
  • sudo su (use your admin pw) to become root
  • chown -R web:www-data /home/admin/uploads
  • su web (now you’re the web user)
  • Move/copy uploads to proper dir/srv/www/ using mv

As you can see these steps require an (S)FTP program like Filezilla to upload all and the terminal to move things around and change permissions. For most Trellis users not an issue really.

Ansible Playbook to Synch Media

CFX in the same Roots Discourse thread mentioned a playbook that is available at Github Gist. The script was made by Louis-Michel Couture. With it you can synchronize your uploads content by just running the script with the following simple command:

ansible-playbook uploads.yml -i hosts/staging --extra-vars=" mode=push"

You do need to make sure the uploads.yml is in your site’s web root. And you of course need to change the domain. Push is for going from local server to staging or production.

Here is the whole script as in the gist:

- name: Sync uploads between environments
  hosts: web
  remote_user: "{{ web_user }}"

    project: "{{ wordpress_sites[site] }}"
    project_root: "{{ www_root }}/{{ site }}"

  # ansible-playbook uploads.yml -i hosts/staging --extra-vars=" mode=push"
  - name: Push uploads
      src: "{{ project.local_path }}/web/app/uploads/"
      dest: "{{ project_root }}/current/web/app/uploads/"
      rsync_opts: --exclude=.DS_Store
    when: mode is not defined or mode == "push"

  # ansible-playbook uploads.yml -i hosts/staging --extra-vars=" mode=pull"
  - name: Pull uploads
      src: "{{ project_root }}/current/web/app/uploads/"
      dest: "{{ project.local_path }}/web/app/uploads/"
      mode: pull
      rsync_opts: --exclude=.DS_Store
    when: mode is defined and mode == "pull"

I did use it and it works well. You just do not see progress and it can take some time for all the files to have been uploaded.

My favorite

In the end I think I would pick sftp. It does show you progress and there is the option to gzip or zip all before upload. This will be quicker. You will then have to ssh into the server, but if you are good at it this will be quicker. the Ansible Playbook is the lazier or easier option, but it will take more time.

WordPress Site Migration – Case study

I have taken care of a lot of WordPress site migrations or movals over the years. A WordPress Site Migration is therefore nothing new to me. People move their website because they get more traffic, need more flexibility or because they are unhappy with their hosting provider. Or all of the above of course. I thought it would be interesting to tell the story of one of the latest ones as a case study. I recently took care of  migration of the Bakfiets en Meer WordPress website. Let me tell you how such a migration or moval takes place. You will see it does not have to be a scary of frustrating thing like the folks in the image seems to have deal with.

Client Case – Bakfiets en Meer Cycling Blog


Bakfiets en Meer

Bakfiets en Meer is a blog run by Henry Cutler, the owner of WorkCycles. He mainly writes about City Cycling, Amsterdam and WorkCycles or other bikes. Alle the things he is passionate about. It had been running pretty well the last couple of years with in the Netherlands and had been getting a decent amount of traffic too. Many people love reading Henry’s personal blogs on cargo bikes or bakfietsen and everything surrounding it.

Reasons for Migration

For the last couple of months we have been having too many server issues. This due to issues with traffic and attacks on the shared server . But also due to issues with the site being to big for the package we were paying for. We wound up having not enough space to add more files and uploading even caused  certain files to disappear on us on an attempt to overwrite them as we were already over our limit! And when we realized the Antagonist (Dutch hoster) offered a better and cheaper package including great service we decided to move the site.


First we made a backup of all the files and the database. This can be done with a plugin like Backup Buddy which is one of our favorite tools for backing up and migrating sites. However my partner Doede and I decided to do it all the old fashioned way this time using PHPMyAdmin and FTP.

When you do backup with FTP do make sure that all files are backed up and uploaded to the new location. Sometimes some files do not come along the first time around. We highly recommend the open source FTP program Filezilla to do all the heavy lifting.

As for PHPMyAdmin, well most hosters have it installed for you and is basically a GUI to manipulate your database:import data, export data, remove data, add tables, optimize data and so on. Normally the hoster allows you to access it from their control panel. This is the case in CPanel and Plesk as it is in most control panels.

Files and Database Migration

Once you have all the files on your PC you can start moving them to the new server. If the domain name has not been migrated yet, and as we of course want the site to work before we do that is the case, you need to upload all the files and import the database.  Uploading via FTP can be done using the username and password and ip address you have been given by the hoster. this way you can still upload without having the option to use the domain name.

NB If you do change domain names there will be database changes that need to be made as well as possible .htaccess changes. For database changes in case you moved without using a plugin like BackupBuddy, use Search and Replace by Interconnect/it

Local Testing

If the moval is not too complicated you can do it all on the remote server or final destination. But if more work is to be done it is always quicker to work locally. This can be done using a VirtualBox with Vagrant or a Trellis package or using more automated packages such  MAMP or WAMP . There is of course DIY using the built in tools on your box. I find Trellis to work well.

In this case a direct migration to the new server was an OK option so we went for that. This as nothing changed, but the hoster. No domain name changes, no webserver or database changes. Just a bare bone migration.

Remote Testing

Most hosters offer an option to test the site before you migrate the domain. Sometimes it means changing the Hosts file on your own PC or Mac to access it via IP.

Hosters File Change

For unix systems like my Mac the file is under /etc/hosts. For Windows 7+ is is under %systemroot%\system32\drivers\etc\ . See Helpdeskgeek article on Windows hosts file. In the past moving the same site from Villa to Webreus I had to use this trick by adding the new ip with domain name to this hosts file:

Domain name x-ed out here for security reasons.

This will load the site from the new location using the domain. And this will then of course only be the case for you. If your client wants to see changes this way as well you will have to ask him to make the same changes on his computer.

Once you have moved the actual domain you can comment out the line or remove it.

Site Testing Service

Sometimes the hoster has a domain service for it. The Antagonist does.  Using their alvast online (online beforehand) service you can preview the site before you move the domain.  And then you do not need to use the above mentioned trick, which is a nice service on the part of the hoster!

It is really vital to test using the domain on the final destination, especially when you have to make database changes due to domain name changes. Then you can test whether all pages and posts load well after you saved or made the new changes

Maintenance Mode

Also when you do do all the testing online, do remember all can access the site unless you use maintenance mode to give only a limited amount of people access.

Domain Name Migration

To move the domain to the new hoster, which we wanted in this case, you need the authorization token or epp code ( transfer secret) from the old hoster to authorize the new hoster’s DNS server to take over this responsibility. This is at least the case for most TLDs. See this extensive NameCheap article What is an Auth/EPP code? for more information on epp. I quote:

You’ll need an Auth Code to transfer a domain from one registrar to another. Specifically, Auth/EPP codes are required for .com, .net, .org, .us, .biz, .info, .me, .co, .io, .ca, .tv, .in, .mobi, .cc, .pe,,,, domain transfers.

NB For Dutch .nl domains you need the authorization code or verhuistoken too. See SIDN article Domeinnaam verhuizen

DNS Propagation

Once we had taken care of this all we only had to wait a little while for the domain name transfer to propagate. That means it takes time before all or most domain name servers or DNS servers worldwide know about the moval of the site. So some servers might send visitors to the old server or old site location. This can take up to 24 hours, but in most cases it is a done deal within 4-6 hrs.

WordPress Site Migration : Finito!

So there you have it, a standard WordPress Site Migration taken care off. As you can see not too hard. But if you do run into issues, as we did as you can see in the following chapter, and you cannot solve them, do not hesitate to contact me!


Most migrations have some issues:

  • sometimes there are small problems due to domain name changes,
  • or hosting size constraints,
  • sometimes the database import is tough due to table size or database size ,
  • PHP or MySQL version changes and causes issues,
  • Moval to new web server with different configuration rules like an Apache > NGINX switch
  • and sometimes the character settings of the server are different.

The main issues we had in during this WordPress Site Migration case was access issues to both core accounts for domain transfer and the display of Flickr photos in the sidebar.

Domain Transfer issues

The new hosting account was set up quickly, but the project delayed and email with access details to Antagonist core account not sent through properly. The other issue was access to the old hoster’s account. These issues caused a delay as we could not pass on the authorization code. That is why it is always important to keep a project up and running and avoid delays as much as possible. But well, sometimes they cannot be avoided.

Flickr Widget Issues

Quick Flickr Widget was no longer working so moved onto Slickr Flickr and needed the ID of my client’s Flickr account, which I was able to get at IDgettr . Do display more than 20 images you need an API key was well though so I got that through his account as well. Finally there were display issues as the flickr gallery widget did not display the images as they had been before. So had to add some CSS voodoo as well.

However, due to the limited functionality display wise of the plugins and Flickr plugins in general out there we decided to leave it out for now. Just could not display images of a decent size, all cropped to the same dimensions opening the photo in a new tab at Flickr when clicked on.

What we did in the end was adding a catchy title followed by the Flickr log. On clicking the logo you will go to the client’s Flickr page to see more great bike stuff!

[gravityform id=”9″ title=”true” description=”true”]