Migrating your WordPress site? Consider this
In this article, we share some learnings from the countless WordPress sites we’ve migrated over the years….
Freeze Period
At some point during the migration from old hosting to new, you’re going to want to take a copy of the website files (+ database) and install them onto the new hosting platform.
From this point on you’ll ideally want the current live website (on the existing hosting) to be considered frozen – i.e. the website admin team do not make further updates to pages & content. Because if they did make further updates, that would make the new hosting out of step (as the database backup was taken before these changes).
The length of the freeze period is obviously up for discussion and we have to balance here how often the admin team want to make content updates and accommodate that.
Please bear in mind though that this free period only really applies to content and changes made by the website admin team themselves; there are other changes that can happen.
And if other changes happen, we run the risk of switching over to the new website and losing some of these changes. Not good!
Let’s look at two examples….
WordPress Comments
If the website has commenting turned on (native WordPress commenting, rather than a third-party system like DISQUS), then this certainly is something that could cause an issue. However, depending on how often comments typically appear on a website, the client may not be too worried about losing a comment or two in migration. One solution could be to inhibit commenting on the live website (until everything is fully migrated),
E-Commerce
A typical WordPress e-commerce plugin is the superb WooCommerce. With WooCommerce, when someone buys from your website, admin can log in to the backend, and review orders, doing whatever they need to do to fulfil them etc.
This being the case, we can easily imagine the potential for website visitors placing orders during the freeze period. Now, we could write a whole article on the exact process to follow here, but the gist of it is this:
- Keep the freeze period as short as possible so that the window for orders being placed is very slight.
- Perhaps arrange the migration (and therefore, the freeze period) to span a time when you know orders are less likely to happen.
- If orders are placed on the current live site (when you know the new site is not yet live), adust your workflow accordingly. This may mean manually copying the order across (from the old site to new one). Or this may mean having access to the current site after migration to the new one (in a password protected form). Yes, this gets complicated. If you think the possible scenarios through ahead of time, you’ll be better prepared.
- If the order is placed when both websites are live (yes, this can happen, see later!), then you’re going to keep an eagle eye on both website backends for where the orders are*. Again, plan for this.
(*An important backup here is to have access to the current live website after migration – typically we do this in a password-protected manner, so as the old site is kept off the Internet at large. This allows authorised users to go back and check the old website when needed. This facility is useful even on non-eCommerce websites).
Commenting and E-commerce are just two examples you need to consider. Think about any of the functionality on your website which can alter its state, and prepare contingency plans for that.
DNS & TTL
DNS is the service that translates domain names (such as GLASSMOUNTAINS.CO.UK) into machine-readable Intenet IP addresses. DNS has a setting called Time To Live (TTL) which, to cut a long story short, means how quickly the world at large will see changes to your DNS. If your TTL is low, it means any changes are propagated across the Internet quickly, if your setting is high, it means it takes a longer time.
TTL is expressed in seconds, a low TTL might be 300 (which is 5 minutes). A high TTL might be 86,400 (which is 24hr hours).
Note: You may be wondering what the benefit of having a high TTL is? Well, it allows the burden of translating domain names and servicing DNS requests to be distributed – greater distribution typically means faster lookup response times & greater resiliency.
Your DNS does not typically change often and, even when it does, we don’t typically need the world at large to see these changes as soon as possible – so the TTL setting does not come into play often.
However, the exception here is when migrating a website!
When we migrate WordPress, we have to change the DNS so that the relevant record is repointed from the old hosting company to the new one; we do this by updating the IP address.
If the TTL is set to high, then there could be a long period of time where some people are seeing the old website and some are seeing the new one – not an ideal situation! The lower the TTL, the narrower this window becomes. E.g. if the TTL is 300, then we know that 5 minutes after we updated the DNS with the new IP address, everyone on the Internet will be looking at the new website (and the old website is now just sat there quietly doing nothing).
On the run-up to migration, you typically want to lower the TTL on the DNS to (say) 300 and then, when you are happy the website has fully migrated you can put it back up (if you so wish).
More on IP addresses
Some services (e.g. older e-commerce ones) require you (in their merchant portal) to specify the IP address of your hosting company (perhaps to validate the orders are from a genuine source).
Whilst this doesn’t happen very often anymore, you do still see it (indeed, we came across it recently). You need to be aware of any such IP restricted services related to your website, and make sure they are updated as part of your migration procedure.
Caching?
Again, we could write a whole article (or series of articles on this) but the gist here is this: when you migrate from one host to another, make sure that the caching plugin that is installed (if any) is compatible with the current hosting company (WPEngine, for example, disallow certain caching plugins). The issues of such disallowed plugins may not show up during the more limited activity of testing, so investigate carefully whilst you have time before the new website is opened up to the Internet.
Many websites have a (say) contact form – where a user fills in a form, and the website sends the form details to the website admin team.
Again, without going into too much technical detail, there are items called SPF and DKIM which are related to your DNS records – these can help indicate that a particular website is allowed to send emails on behalf of your domain. If any of these records mention the IP address of the current hosting company, then they too will need to be updated coming migration or the deliverability of emails from your website can be affected.
The End
Forwarned is forearmed ao hopefully the above has given you some food for thought in terms of planning for and migrating your WordPress site.
Joel
p.s. If you would like to talk to us about possibly migrating your WordPress website, please don’t hesitate to get in touch.