The website works, but another team will maintain it. An owner may have a live address, an archive and several logins without knowing whether they are enough. Start with an assessment of the existing state rather than moving the domain or promising to fix everything quickly.
This guide concerns a new provider taking over an existing site. Handover of a newly commissioned website and ongoing support are separate topics. Changing agencies does not automatically mean redesigning or moving hosting.
Define the task and preserve the starting record
Record why you are changing providers and what you need now: content updates, a particular fault fixed, a new feature or planning a rebuild. Separate existing bugs from new wishes. Give each problem a URL, reproduction steps and actual outcome.
List important journeys that must remain available: enquiries, booking, sales or publishing, only where they actually exist. Record the assessment date and known limits. This supports comparison after changes; it does not certify the whole project as working.
Map materials rather than listing passwords
Mark each item available, awaiting verification or missing. Record absences honestly rather than treating approximate answers as confirmed facts.
| Area | What to establish | What may remain unknown |
|---|---|---|
| Live website | Domain, platform and current public version | Where and how it is published |
| Code or platform project | Repository, export or account with necessary rights | Whether the package matches the live version |
| Dependencies | Email, forms, payment, booking and other actual services | Who manages them and what stops without them |
| Materials and backups | Content, images, instructions and backups | Currency, completeness and usage conditions |
Check permissions before changes begin
Establish which accounts the business controls, who can invite the new team and recover access. Agree necessary rights for an initial assessment rather than handing over every account at the first meeting. Do not put passwords or secrets into a public form or shared document.
Services have their own roles. For example, Search Console distinguishes owners and users; access to website files does not establish the necessary access to search data. Check services separately.
Use the domain, hosting and email account map to organise control. Agree ending the previous provider’s access alongside the transition so you do not lose control before verifying the new team.
Ask for evidence that the package can be maintained
The new agency needs to establish whether the available package can run or be restored in an agreed test environment, how changes are published and how to return to the previous version. Separately compare it with the live site. An old archive or successful local build alone does not establish this.
Backup contents depend on the platform. For example, WordPress backup documentation separates files and database; a typical restoration requires both. This illustrates a check rather than assuming your website uses WordPress.
Use safe test data and agreed access. Do not copy actual enquiries into an unnecessary environment or restore over the live site just for a demonstration. If missing material prevents verification, record an open question with an owner.
Clarify limitations and material conditions
Ask for dependencies that affect continued work: subscriptions, modules, account links, special settings and undocumented changes. Each important limitation needs a consequence: what cannot be checked or what must be agreed separately.
Possessing code does not explain permitted use. GitHub describes repository licences; collect known conditions for the particular project and resolve disputed points separately. Do not assume every third-party asset can automatically be transferred.
Educational example: an archive opens, but form notifications depend on the previous provider’s account. The team records the dependency and the decision needed before assessing changes. This is hypothetical, not an XEVOR case study or a reason to replace the entire platform immediately.
Separate assessment from future improvements
After initial checks, ask for a short finding: what is confirmed, what remains untested, which access is missing and which tasks can be assessed. If further investigation is needed, agree its outcome and limits first. Do not combine unknown existing faults with a promise of unlimited maintenance.
- Existing fault: reproduction, expected behaviour and a fix check.
- New feature: a separate scenario and dependencies.
- Missing material: who requests it and what it blocks.
- Ongoing support: agreed tasks and a contact channel.
If the assessment identifies wider changes, use the redesign guide to distinguish them. Changing provider and choosing a rebuild are separate agreements.
Record the transition point and acceptance
Agree who maintains the current version until transition, who may publish changes and who makes decisions during a fault. Add the return process and post-handover actions. Meeting a new agency does not by itself authorise DNS or email configuration changes.
- Assessment date, version and checked journeys.
- Received materials and access with actual roles.
- Known faults, unknown dependencies and owners.
- First agreed task, outcome and verification method.
- Publication, return and fault-reporting procedure.
- Responsibility before and after transition and ending old access.
Accept the first change against the agreed journey on the final website. Arrange any actual test enquiry with the recipient and label it as a test. An on-screen message does not replace checking receipt.
Discuss taking a website into support · Send a URL and task description without secrets
Changing agency FAQ
Is an admin password enough?
Not always. The package depends on the platform, publication process and services. Check it against the particular task.
Must hosting move immediately?
No. Establish the need and dependencies first. Agree a move separately, with checks and a way back.
What if code or access is missing?
Record what is absent and the checks it blocks. Agree how to obtain it or a different scope rather than assuming full readiness.
Does a new agency mean a complete redesign?
No. Initial assessment should help separate support, targeted fixes and wider restructuring.