It’s hard to find a great web developer – and even more difficult to find one who can keep up with you as your business grows and your goals expand.
If you’re in a place where you need to transition away from your current web developer, it’s critical that you get your ducks in a row first, so you can avoid the all-too-common worst-case scenarios that come with a rocky transition.
I’ve seen web developers totally ghost their clients, leaving them without access to critical infrastructure and forcing them to start all over, at great expense. Even worse, I’ve seen a shocking number of web developers hold their clients hostage (albeit, politely and without using those exact words), forcing them to continue paying fees to get access to a site that was rightfully theirs.
Before you talk to your web developer about the end of your contract, follow these steps to make sure you’ve got the ownership and control that will ensure a smooth transition.
Compile and change your passwords
Grab a password management tool like 1Password or LastPass, and set yourself up with a vault where you can store all your critical passwords. These tools are crucial because they encrypt all your passwords and allow you to share your vault with trusted team members, which means you’re never insecurely sending passwords via e-mail, text message or voicemail (all of which can be hacked any time in the future).
You or your web developer will almost certainly have used all of the below services – so make sure you compile passwords for all of them and store them in your vault:
- Web Hosting (e.g. WP Engine, GoDaddy or Amazon Web Services)
- Domain Registrar (e.g. GoDaddy, Network Solutions or NameCheap)
- DNS or Caching Service (optional, usually Cloudflare)
- E-mail (sometimes provided by the web host, sometimes via Google or another third party)
- Github, Bitbucket or any code repositories the developers has used
- Any paid plugins or marketplaces where your developer has purchased commercial themes, plugins or other software used on your site
If you’re not on great terms with your developer, you can frame these requests as a “password and security inventory” that you’re conducting to make sure you have everything you need in case of an emergency.
Generally speaking, as you grant new people access in the future, you should follow the one person, one account rule. That means never sharing passwords, and instead using features that allow you to add new users to your account (this is possible via WP Engine hosting, GoDaddy and Cloudflare, for example), where each user will have their own login and password.
Test and change all passwords, and set up 2-factor authentication
Once you’ve compiled your passwords, test that they all work, then change them to something that’s only in your vault. You can then give your developer a new password temporarily if they request it prior to your transition (e.g. if they need to make an edit to the site). You can also create a separate, individualized account for them where possible, which you can easily delete in the future.
Pro Tip: Many of these accounts offer or require 2-factor authentication. Make sure that you verify that your developer’s phone number is not hooked up to 2-factor authentication on any of these accounts (change it to your mobile phone instead). If you leave 2-factor hanging anywhere, you’ll have to go back to your old developer to get access, which is bad news.
Once you’re done, you should have new passwords for all your accounts, and everything should be hooked up to your mobile phone for 2-factor authentication. Use the LastPass random password generator to create hard-to-guess passwords (and never re-use the same password in two places). Don’t use passwords that include your address, company name, the current year, or anything else that’s easy to remember … that just makes it easier for hackers to guess.
Understand your tech stack, and make sure your new developer does too
After you’ve confirmed you own and have the keys to all your accounts, ask your developer for a briefing on your tech stack. Key questions include:
- Which content management system does the site use?
- Which programming languages and database does the site use?
- Which commercial software is in use on the site that we need to upgrade or maintain?
- What’s your process (if any) for running periodic software updates?
- How do I manage [insert key pages or sections of the site] myself?
- Which sections of the site require custom coding if we want to make updates?
If possible, pay your developer to create a 20- or 30-minute video tutorial using an easy screensharing tool like Loom, or have a Zoom meeting with them and record it. This is usually much faster and more helpful than creating written documentation (which is laborious for most developers and hard to understand for most clients), and you can download it and easily share it with your future developer to make on-boarding easier.
Make a backup!
Most hosting providers will provide you with the ability to download a complete backup of your site (all files and your full database) to your local computer. If they’re not able to do that, you can use an inexpensive tool like ManageWP or CodeGuard. Having a full backup is critical, just in case anything goes south during your transition, accidentally or otherwise.
After you’ve made a backup, put it in a cloud storage service like Dropbox or Google Drive so you have multiple copies stored in multiple safe locations. In other words, make a backup of your backup.
Break the news
Odds are, your web developer will be honest and won’t make your life too difficult when you let them know you’re moving on. But I’ve also seen bad things happen, both intentionally and by accident, because neither the client nor the web developer had done a good job of keeping their key infrastructure organized. By crossing your t’s and dotting your i’s in advance, you’ll be in a much better place to dictate fair terms for your exit, and to transfer everything seamlessly once you bring a new and improved web development team on board.