A client has asked me to propose taking responsibility for their websites and related IT services. I'm comfortable handling some web work, but I'm unclear about the usual process for taking over from an existing provider.
My own sites are hosted through IONOS, and I understand the importance of controlling the domains. The client has not provided many technical details yet; I only know that the existing website needs significant improvement and that another provider is currently paid annually to maintain it.
Before preparing a proposal, what information and access should I request? Should I simply maintain the existing hosting and website, or is it usually better to migrate everything? What should I check regarding domains, DNS, email, backups, source code, third-party services, contracts, and ongoing support?
4 Answers
First establish the scope. Are you only maintaining the deployed website, or are you also responsible for hosting, servers, email, DNS, backups, and other infrastructure? If the current provider and hosting are staying in place, you may only need appropriate credentials and a clear maintenance agreement. A migration is a separate project with its own risks and costs.
Before changing anything, create an access and asset inventory. Request the registrar and DNS details, hosting account, SSL certificates, email configuration, CDN, analytics, repositories, licenses, renewal dates, scheduled tasks, and every third-party service connected to the site. Get written authorization from the client and ask for current website and database backups. Ideally, verify that the backups can actually be restored on a staging system.
Ask whether the client wants a hosting migration or simply ongoing development and maintenance. If the current hosting is adequate, moving the site just because you prefer another provider may create unnecessary risk. Ideally, you should receive access to the existing source repository. If there is no version control, make creating a repository and establishing a backup and rollback process part of the initial work. For site builders that do not support a normal code workflow, use separate user access rather than sharing passwords.
I haven’t used version control before, but setting up a proper backup and rollback process sounds like an essential first step. I recently damaged a site’s email setup during a hosting change, so I can see why this matters.
Keep the client as the domain registrant and billing owner wherever possible. Document the existing DNS records and have a rollback plan before making changes. If you do migrate, lower DNS TTLs beforehand, confirm where email is routed, and move one part at a time rather than changing hosting, nameservers, and mail all together. After the cutover, test HTTPS, forms, outgoing mail, redirects, scheduled jobs, analytics, backups, and administrator access. Keep the old setup available for a short overlap period, then revoke the previous provider’s access only after the client confirms everything works.
That makes sense. I need to know exactly what I’m taking responsibility for before I can price the work properly.