What I call a ‘Hosting Hostage’ is a customer who doesn’t have access to the hosting and/or domain name control panel of their website.
It can be that the previous web developer signed them up for hosting themselves and never passed on the login details. Or worse, that they are hosting the customer’s website on their ‘personal’ hosting account , in which case they will never grant you full access.
Where’s the problem? Why ‘hostage’?
‘Hostage’ because you fully depend on the previous developer’s goodwill and availability to get access to your customer’s current website, which you will need most of the time when you want to deliver a new one.
This is NOT a problem IF AND ONLY IF all of the conditions below are met:
- you do at least have access to the domain name settings (login details to the domain name provider)
- the client is OK starting a new contract with a hosting company
- you are starting their website from scratch (not re-using any content or the CMS of the current website)
In any other situation, inheriting a hosting hostage is an issue.
What’s the impact on your work?
If the previous developer is dragging their feet or is simply not available, the work of your developer will get delayed. You will also have to spend lots of time chasing people around for info!
How to avoid all that?
First of all, anticipate the eventuality by asking the login details to hosting and domain name settings as early as possible (I’d say at least 2 weeks before the start of the development stage).
If possible, try to put your web developer directly in touch with the previous one. It will speed things up if they can work it out among techies.
When you ask the client whether they have access to their hosting, don’t just take ‘yes’ for an answer. Ask them to send over the actual login details in full (that means URL to the login screen, username and password). Very often, what you’ll receive are the login details to their CMS – most customers are not fully aware of what hosting is. Similarly, the previous web developer might send you FTP details. In most scenarios that is not enough – your developer will probably need access to the database as well as the website’s files and therefore need full access to the host.
If you cannot get full access (e.g. the site is hosted on the previous developer’s personal hosting account), ask to be sent a copy of the website (site files and database export). You will not be able to use the current hosting.
Sort it out for the client
By now, your customer must be realising that what felt convenient at first (having someone else take care of purchasing hosting) is a hindrance in the long run. It is even worse for domain names as they might end up not officially owning them.
If you can’t re-use the current hosting, get the client to sign up for a new hosting contract. Personally, I always have a provider to recommend and I send brief instructions to the client so they can make the purchase themselves. That way they own the contract, and I work with providers I am familiar with.
Most hosting providers also provide domain names. Ask your developer or the client’s IT consultant if they can transfer the domain names to the new hosting provider so that everything is in the client’s name, and under one roof. Now THAT is convenient.