Website migration best practices
Most of my new website build projects are first targeted at a test system, also known as a sandbox site. I currently run three such sandbox sites for developing new websites. I use them to flesh out design ideas and test out how they look on different devices. Although the Rapidweaver development tool I use has a preview option that allows a developer to preview what a site looks like on different devices / screen sizes, I feel that there is no substitute for running the site on a test domain. The big advantage is that I can also share this with my client. He or she can view the sandbox site and make a considered assessment of it and decide what changes they would like to make. It is an ideal way to ensure that ‘what you see is what you get’ or WYSIWYG.
The client can also change text through the CMS and add some initial blog posts. If they have any difficulties understanding how the Admin pages work or how to add a blog post, then their problems can be addressed at this stage, before the site goes live.
The sandbox sites are all hosted on my personal hosting package but I encourage my clients to use their own hosting package and to pay for the ongoing renewal costs. If my client is keen to use their own choice of hosting company, I then have to ensure that the hosting is suitable for their needs and that the hosting is fast, secure and kept up to date with the latest versions of technologies and languages such as PHP.
One important consideration in this approach is SEO metadata. I do not set this up in the test site as there is a very real risk that the test site will be competing for rankings with an already existing site. Another scenario I found out the hard way was a client who did not want to be found until she was ready to launch her business and she could be found on my test site because some metadata was already set up in the test site. So my advice would be to always add SEO metadata to the live site after going live.
I have found that this development approach works well for me, both for totally new websites and occasions when I am tasked with replacing an existing website and re-using an existing URL. In the latter case continuity is always a priority and the client cannot afford to be without a working website for more than a few hours. When the new site comes up it is vital that contact forms and booking engines work seamlessly from the start.
For that reason, it is vital that I personally have a very clear migration plan in place. This plan may change depending on various scenarios to do with what hosting I am targeting for the new site. However most of my checklist items are going to be relevant, whatever the scenario I am dealing with and some tasks may be more of a priority than others — for example, getting the contact form working and tested with the client.
For the technical details of how I migrate a CMS controlled website and then test it, please follow this link Migration-Best-Practice