Website Transfer Guide – Common Pitfalls & Solutions

A Different take on the normal “Website Transfer Guide” …

Taking over, or inheriting responsibility for an existing website happens to any web designer or developer at some point. In theory, website transfers sound extremely minor and insignificant – take a backup of the site, re host and away you go. As a result, if you Google something generic like “transfer web site” you’ll get lots of guides that are technically correct but rarely work in theory, as external factors have a big part to play. For instance, look at the website transfer guide of 123-reg.It appears transferring a site is a case of following a couple of basic points. It really isn’t! In reality, taking responsibility for a website is an absolute minefield and deceptively complex. A website transfer guide should reflect these complexities. What follows are some points to consider, from the view of a web developer when doing just that.

The Existing Website

The first thing you should be noting is the situation with the current site, in it’s current state. The temptation when transferring a site is be blase about the whole process and assume everything is working as expected. To save yourself lots of pain in the future, perform a sanity check on the current site. For instance, get login details to the administration area and check functionality. Also check that you can easily add new content and that basic things like user management works. Of course, a simple static site will involve less checks than a complex or custom website. Additionally, there are less checks to perform on say a vanilla WordPress site than a site that uses a bespoke platform. The time required for each will vary and is something that should most definitely be factored in during costing – testing (correctly) is time consuming.

This testing may seem overkill at this early stage but it avoids one common pitfall that many will find themselves in. Issues after the transfer, through no fault of the poor developer who inherited the site, are blamed on that developer. The absolute worst situation to be in is when your client says “well I could do [additional functionality] before the transfer” or “this has been broken since you’ve moved my site”. If such a situation was a direct result of the shoddy coding/practice of the previous developer, at this stage, it doesn’t matter. Ultimately, if you are unfortunate enough to end up in such a situation you’ll lose out in some way. Trying to explain, to a non technical client that the shopping cart doesn’t work because the cart controller doesn’t extend the base controller and as a result, isn’t sending across the correct array of attribute data, (insert in any valid technical reason here …) won’t wash in the least. Even if you have simply restored what was previously there, you are responsible, end of story.

To avoid this awful and hopeless situation, get the client to confirm that the current site is fully working and if necessary, outline any incomplete issues they have outlined to their previous developer. You’ll not only get a good view of what the client you are inheriting is like to work with, which is always good information to have but also have a document to fall back on if the worst happens.

Personally, I always take a backup of the current site in full, host it on a test server and get everything working. The client then goes through their site and confirms everything is working on the new site, as they expect. Time spent now is extremely worthwhile.

Sourcing the existing website …

This sounds simple but getting a physical backup of the existing website can be challenging and is key to any website transfer guide. Some developers simply don’t want to give up their custom code. Others will have signed an agreement saying they own all code and it must be hosted on their own system. Others are simply unreachable and impossible to get hold of, or have “vanished”, as some clients say. Lingering unresolved issues between the previous developer and client may also exist and prevent you from gaining a timely backup. The latter represents lost time for yourself. Early on in the process, (yes, transferring a website to another person is a process that has lots of scope to get complicated and time consuming, don’t for one minute think it isn’t …) explain to your client how to proceed. Will you become a middleman, used to communicate, or will you simply state that a process is delayed until the client has provided a full backup of the site files. However you broach this, leave no question in your client’s mind as to how things will play out.

Once you have the basic backup of the site and database, take a further copy and save it externally. Throughout the entire transfer process do not work on the copied site. If anything was to go massively wrong, there is nothing to fall back upon.

Perform a site audit

The last step of the majority of current online guides always state “test the site”. When the site has been transferred and the DNS change completed, it’s too late.

Before transferring a website even crosses your mind, for the love of all things holy, perform a full site audit. The results of this audit form the basis for everything else that follows in this post. Apart from basic front end functionality, ensure the site is coded to such a standard that it is secure. I’ve inherited a website that cost £7,000 plus, made by large London based agencies that fails to escape data, is wide open to SQL Injection and stores highly sensitive data about children aged 5-10 years in publicly accessible text files. Really, are these the types of websites you want on your dedicated server or VPS, or to be even responsible for? Probably not. I’ve even inherited a website that contained a vanilla install of PHP Mailer in a sub directory that allowed anyone who went to “/mailer” to add a HTML message and paste in a list of email addresses. All they had to do was press send to execute a mass mailing campaign, directly from your website. Ignoring the instant security hole, there is scope here to get the servers MX records blacklisted, which can be very costly to fix and have huge ramifications (again, this site cost thousands of pounds and originated from a Manchester design agency who rank highly for “web design Manchester”). Another site I inherited was so bad, it literally forced me to swear each time I opened a PHP file and had a nosey at the code. It was dire, the developer should not have been let loose on paying customers. The site used no framework to speak of and was a total mess. Additionally, the developer decided not to use simple file includes for any of the 70 plus PHP files and the site was a total mess (Company Media, now inspirationalinc.co.uk, you should be ashamed – that site was truly one of the worst examples of web development I’ve ever seen, I could write a whole post about the site alone explaining how god awfully it was made …). So, making a small change to how the meta title tag was formatted was a seriosuly long process, something which should have taken moments to do, took a lot longer. Thinking back, Company Media couldn’t even be arsed to bootstrap their code and decided to copy and paste MySQL connection details separately in each PHP file (yes, I had to go through 70 plus PHP files separately to change MySQL connections and add an include. I was very, very mad afterwards.

Hidden pages is something to look out for. Some (foolish …) developers leave entry points into their administration areas or certain parts of the site. Others have added extra pages to the site that is essentially SEO spam. For instance, one Magento developer who I came across decided to leave an 800 word page about Magento developer with SEO links back to his own site, on each project he worked upon. Is this something you want hosted on your server? You may also want to look out for pages that are part of link wheels or similar. Such pages usually contain thousands of links and are not good to be around – even for your other sites on the same server. They are mainly left behind by questionable SEO companies.

I digress, I’m simply trying to illustrate here that performing an audit should be first on your list of priorities as a web developer or designer. Who is responsible for the fine when the latter exploit allows a user to send out 10,000 spam emails from your website and gets your SMTP server blacklisted for all other sites on that server?

Remember, the site you inherit now forms the base of any future updates – so think ahead. In the latter example, if no audit was performed, the client may ask why the hell they are being charged for an hours work to make a simple change. An initial audit avoids this.

Using the latter examples, above, you should state in your audit (which can be sent to the client) the following:

• Removal of PHP Mailer script
• Development to ensure site is not susceptible to SQL Injection
• Site is not coded using include files. Small site wide changes result in higher costs due to time spent. Fixible at this stage for £xxx if required etc.

At this point you could lay out your charges for fixing the said issues and that fixing the issues are a condition of the hosting transfer.

Technical knowledge

The crux of a successful web transfer and website transfer guide is, as a developer, do you have the technical knowledge and experience (or, the ability to learn new skills) to manage the new site? In inheriting a website you become the point of contact to the client for updates, issues, fixes etc. If you don’t know ASP.NET then don’t agree to become responsible for a custom CRM written in ASP.NET MVC. Equally, if you’re a PHP developer and have never used the Zend Framework (which has a very high technical entry point …) or Magento, then don’t agree to take on a busy Magento store with lots of custom plugins or code. If the site is written using CodeIgniter HMVC then don’t for the love of god, agree to become the point of contact for this site if you don’t know CodeIgniter of what MVC is. Granted, you could learn (which is always a good thing in my opinion …) but learning represents a big investment of your time – do you have this time available? For instance, you couldn’t sit down one day and say “I’ll learn the Zend Framework today” – it’s just not possible. The same goes for any CMS/Ecommerce Platforms/CRMs etc – if you don’t know them then think carefully whether you’ll be able to proceed. I could go on, but I’m sure you get the idea – ensure that you are technically capable of providing support. I speak from experience too. Roughly two years ago I agreed to take on an existing Magento site. After the transfer the client came to me and asked for lots of additional functionality. Having never used Magento at the time I was frankly knackered. Granted, it did force me to learn, and in retrospect I learned a lot about Magento that I still use day to day. However, at the time I stressed and ended up dedicating a lot of time to teaching myself.

Take Magento for instance, it’s not even possible to simply download the files via FTP and then upload them to your new host – you’d be there for hours. Transferring Magento uses some assumed knowledge of how to use SSH – which is the correct way to transfer the site from host to host. Additionally, not all hosts allow SSH access, which would be a huge issue when uploading a Magento store. Then there is the issue of the admin area, clearly aimed at developers and not normal users. (I had a little rant about Magento as an Ecommerce Platform a while ago …) – By inheriting a Magento site you now become the contact point for the limitless questions about how to use the admin area. Do you charge for this advice, is it included free of charge?

“Set out your stall”, very early on …

All web companies, web developers, freelancers et al work differently. This is a fact you should be very aware of. A freelancer may be able to provide minor updates freely on a very ad-hoc basis, whereas a developer working for a full blown agency with 20 staff would have to act differently. The said updates would need to scheduled in with their project co-ordinator, the updates would be charged for and invoiced. Some people invoice on a time basis, whereas others have a flat fee. Whatever your personal situation, you need to inform your new client and the earlier the better. There should be zero doubt in the client’s mind as to how costing is structured. Another thing all clients seem to love is knowing how fast jobs can be turned around, or completed. Some clients appreciate you have other customers, others don’t. Set your stall out and leave little doubt as to how long updates typically take.

I’ve inherited my fair share of WordPress based sites, and they have illustrated another issue to heed. WordPress, like many other open source Content Management systems, requires regular updates – to the core and any associated plugins. In the past, some clients have instantly assumed I would be the one regularly checking their site, plethora of obscure plugins and nasty hacks they have running. Other do this themselves. At the end of the day, it’s all time that needs to be accounted for – ensure the client is aware of this.

Depending on the size of the site, it is a good idea to get a slightly different version of your standard web contract (you do have a contract for websites don’t you …. ) signed by the client. In essence, you need to get everything confirmed with the customer, exactly like it was a brand new customer, with a website you created. At this stage, it is also worth fleshing out any ad-hoc or ongoing agreements the customer currently has with the previous developer. For instance, it’s common nowadays for clients to have regular content updates on their site, for a flat monthly fee, or for SEO to be performed. Can you provide these services too?

Web hosting checks

Of course, taking over responsibility for an existing site involves hosting. Firstly, the client may want to use their own nasty hosting. If they want to use some oversold hosting from companies like 1&1 or Godaddy, let them but make them aware that you aren’t responsible for downtime. In the past, when there have been issues with the host that prevents the site from working, the client has called myself and expected that I call say, Godaddy’s awful support line. If you’ve had the misfortune to call them, or similar, you’ll be well aware that minutes on the telephone can quickly build up – representing lost time and money to yourself. At least make the client aware that using their own host comes with it’s pitfalls, as you don’t have 100% control over the site this way.

Simple static websites can be hosted anywhere, they don’t need any type of hosting or unique features. More complex sites will require specific features to be functional and perform. If you are transferring a basic HTML site this section can be ignored. Before transferring the site, you need to be 100% sure that the inheriting host supports all the requirements for the website. However, for arguments sake it may well be a Magento ecommerce website that you are transferring over. As any web developer (or client for that fact) will tell you, Magento is an inherently complex piece of software. Transferring a Magento site to your £10 a month oversold shared hosting simply won’t cut it. Such software needs at least a well configured VPS and use of some sort of caching, such as APC or Varnish Cache. Shared hosting rarely has such features. Other sites may require a specific minimum version of say, PHP to run. If your host doesn’t cater for this, you’ll encounter issues. Other clients will have advanced email access over the basic POP3, such as IMAP or Microsoft Exchange. If you host doesn’t support these, or they represent an extra cost, you should make your client aware.

Another common feature to take note of is SSL certificates, a feature any (good) ecommerce website will include. Normally, you can transfer the existing SSL certificate to the new host fairly easily. Some hosts will do this for free, others will charge. I’ve even come across web hosts who actually charge to provide the SSL files for reuse. Again, make sure all things like this are factored in.

One of the most common pitfalls is the short tag PHP feature not being enabled on a host, for a site that makes extensive use of them. Some hosts won’t allow such changes either, just to be awkward. Imagine how time consuming it would be to go through an entire site to use the full tag style. Short tags aren’t recommended anyway, due to portability issues. Is this time you want to charge for?

Finally, outline the ongoing charges for web hosting to the client, this avoids future issues and the classic “well you never told me I had to pay for this” from the client.

Hosting access requirements

Access required to the site is another pitfall. Third parties such as SEO companies and other developers may require direct access to the website. Do you allow this on your hosting and what happens if anything goes wrong? SEO companies in particular will usually go and let their junior staff bugger around with the website source files (those companies know who they are as they’ve commented all their changes, ahem …). At the same time, I’ve had a client give an inexperienced freelancer full access to their site, only for the said freelancer to somehow delete the site completely. Outline all these situations to the client. For instance, some hosts charge to restore backups. Personally, I try to limit access as much as possible. If a freelancer only needs access to a particular directory, create a limited FTP account for them. Don’t however, provide full Cpanel access.

Hosting Capacity

In short, does your web host have the capacity to host the site in question. For busier ecommerce sites and forums, that tend to receive a high level of sustained traffic and request, all within a short period you need a pretty decent/generous host. Some sites may well have had SEO performed recently or be part of an external advertising campaign that results in high volumes of traffic for the site. What happens if the site takes you over the bandwidth limit for the month within a couple of days for instance?

At this stage I’d always recommend quickly looking at some web stats, or even better, Google Analytics if present to get at least an idea about how busy the site is likely to get. If your host has the capacity fine, but a lot of hosts do charge for additional requests/bandwidth. Try to avoid any nasty surprises for yourself and the client later on. Hell, some sites need a dedicated server due to how busy they get. If you can’t provide this then you’d be frankly stupid to transfer and downgrade the website.

The latter nicely brings me to the final point about hosting – the hosting type. If you are going to transfer a website currently hosted on a dedicated server, then make sure you transfer it to another dedicated server. If you transfer a busy site hosted on a dedicated server, to your $3 per month oversold hosting in America, then the client and their customers will soon seen a marked negative change. For ecommerce sites, this directly results in decreased conversion rates (CRO) and ultimately, lost sales. If you can’t match the previous hosting and you’ve not informed the client they will be downgrading by transferring, then the transfer should stop at this point, immediately. Similarly, if you have transferred your client’s 5 page static HTML page about flower pots, that receives 50 unique visits per month, to your dedicated hosting that costs 30 times more for the client, you should arm the client with enough knowledge to make an informed decision.

Domain Names

Transferring a client domain name is just as part of a web transfer as the getting of an FTP backup. The transfer may be from the existing developer to yourself, or simply transferring the domain name away, so the client is in control. Either way, you’ll probably need to get your hands dirty and communicate with the previous company/individual. Whilst transferring a domain is a fairly run of the mill process to complete, it can become a minefield. For instance, depending on your hosting setup you may need to edit or add some DNS records. Can you perform this task yourself?

I’ve come across companies that flatly refused to change the IPS tag of a .co.uk domain without the client paying them £100 (yes that’s £100 to change an IPS tag, I won’t mention the name of this company, but regular readers of this blog will know exactly who they are … /fin). If the worst does happen, ensure that you make it crystal clear to the client what part you’ll take, if any. Disputes of this nature can become extremely involved and time consuming. In retrospect, I’d say get the client to perform this taks this themselves if possible.

Another, albeit less common thing to look out for is domain ownership during transfers. I’ve come across two companies that bought and registered the domain themselves and “leased” it out to the client. As the domain contained a keyword, they coined it a “premium domain name”. In short, the company wanted £250.00 +vat to transfer the domain away. Note that the domain was being used on all of the client’s printed material such as business cards and signs. At this stage, you’d need to think of using a domain name and the associated costs of buying the old domain.

Also, note the effect of DNS caching. If a transfer is planned, it is possible to lower TTL values approximately 24 hours before the change takes place, which will result in less disruption as the change will take less time to propagate. This is something that can minimise the impact of a website transfer and is essential for mission critical ecommerce sites.

Define a “switch off point” in the website transfer guide …

In reality, the latter issue about defining a point at which no further changes to a website should be made, before the transfer, is a good idea. For instance, you could state to the client that no changes should be made from a certain date and time. The defined point allows an up to date backup of the site’s content and database to be taken. For instance, if a client has a WordPress website, during the transfer they could easily add a new post with attachments after you have taken a backup. After the transfer, the client would be missing a post and files they have uploaded – not good. Granted, it;s not always possible to define such a point for all websites, but wherever possible try to do this.

This “switch off point” theme can also be applied to the client’s existing hosting. The client is almost certainly likely to ask you the perfectly valid question – “when can my old hosting be cancelled so I’m not paying for both”? Strictly, 48 hours is the quoted maximum time frame for full propagation.

If you’re like me, you are overworked and have a lot on your plate day to day with normal development matters. Anything to make my life as a developer less stressful is duly welcomed. Granted, the latter post may sound like lots of additional work, but when you compare it to the potential time spent sorting out disputes as a result of the transfer, it’s worthwhile. Planning is the key and planning is what will save your sanity.