Changing the person who looks after your website can feel more complicated than changing the website itself. The domain may be in one account, hosting in another, and business email connected to settings nobody has looked at for years.
A careful transfer begins with understanding those dependencies. If you are moving a Cheltenham business website to a new developer, the first task is to establish what exists and who can access it. A new design can follow once the handover is understood.
This is a practical planning checklist, not advice about interpreting or ending a contract.
Clarify what is actually moving
"Move the website" can mean several things: giving a new developer access to the existing setup, transferring hosting, changing platforms, or replacing the site entirely.
Ask the incoming developer to describe the proposed change in plain language. Retaining the current hosting and improving a few pages is different from rebuilding on another system.
Write down what should stay operational throughout the transition. This may include the public site, business email, online bookings, forms, downloads and any customer account areas. Each needs an owner during the change.
Build an account and access map
List the services connected to the site without collecting passwords in a shared document.
- Domain registration and renewal.
- DNS management, where domain records are controlled.
- Website hosting or platform account.
- Site editor or administration access.
- Business email service.
- Forms, booking tools and payment services.
- Analytics and Search Console, if used.
- Source code, design files and content storage.
For each, record the provider, account owner, authorised users, renewal date if relevant and recovery contact. Mark unknowns for investigation.
These responsibilities may all sit with one supplier, but do not assume that they do. A website login alone does not necessarily provide domain or email control.
Check the outgoing arrangement
Review the agreed notice, handover process and deliverables with the current provider. Ask for a written list of what can be transferred and what is included.
Some setups use software, subscriptions or assets with specific conditions. Identify those before scheduling a move. If you are uncertain about contractual rights, seek appropriate advice rather than asking a new developer to make assumptions.
Keep the request factual: you need access, a copy of agreed materials and confirmation of services that will stop. A clear handover list is more useful than starting with blame about how the current site was built.
Preserve the material before making changes
Ask the incoming developer what needs backing up and how the copy can be checked. Depending on the site, that could include files, content, a database, configuration and media.
Also record important page addresses and working contact routes. For a rebuild, these form part of the migration plan even if the new site looks very different.
If addresses will change, ask for an old-to-new URL map and permanent redirects to the relevant replacement pages. After launch, test important old addresses, including those used by other websites, to check that visitors reach the right content. Google’s site-move guidance explains the mapping and redirect process.
Do not move customer information unnecessarily just because it appears in an export. Establish what is required for the work and how authorised access will be handled. The transfer should preserve the information the business needs without spreading it across casual copies.
Keep email and the website separate in the plan
The website and business email may use the same domain but rely on different services. Changing where the website is hosted should not be treated as permission to replace every domain record.
Have the developer identify which settings need to change and which must remain. Record the existing configuration and agree a way to recover if something goes wrong.
Test email sending and receiving after any relevant domain changes, as well as testing the website itself. A working homepage is not sufficient evidence that the whole business setup survived the move.
An illustrative transfer sequence
Imagine a Cheltenham consultancy moving an existing brochure site to a new developer. This is a hypothetical example.
The owner controls the domain, the outgoing supplier controls hosting, and email is provided separately. The incoming developer first reviews a copy of the site, confirms what can be maintained and prepares a preview. The owner approves the content and enquiry route before any live change.
At launch, only the necessary website settings change. The team checks the public pages, sends a test enquiry and confirms email still works. The old service remains available for the agreed transition period, and is cancelled only after responsibilities and recovery needs are understood.
That sequence makes the decisions visible instead of treating launch as a single unexplained switch.
Finish with a useful handover
Confirm who now receives renewal notices, holds administrative access and handles updates. Remove access that is no longer needed through an agreed process, after checking that the business retains its own working access.
Our website ownership and handover guide covers the records worth keeping. If the move includes substantial changes, use the redesign guide to decide what should be retained or rebuilt.
Singularity Shift offers website development in Cheltenham, including discussions about existing sites. Send James the site address and the reason for the move. You can describe the access you have without sharing passwords in the initial enquiry.