When changing agencies, establish when the new partner takes over each task. They need more than CMS access: connected services, ongoing contracts, the published version and outstanding work.
The domain, hosting and CMS access inventory helps define ongoing roles. A handover additionally needs to establish when each responsibility changes.
Start with a system inventory
You can prepare the handover with an inventory of domain administration, hosting, the CMS, source repository and connected services. Including each system’s contract holder, contact and the new partner’s agreed role shows who can authorise changes and where responsibility is still unclear. Transfer credentials through a protected channel rather than this general inventory.
Scheduling, form delivery, image storage and payment services may also form part of the website. Including these connections matters because a move can affect functions that are easy to overlook when reviewing only the visible pages.
Turn the inventory into handover checks:
| Component | Handover check |
|---|---|
| Domain | Company retains administration; agree the new agency’s DNS role |
| CMS | Check personal accounts and editorial roles |
| Mailing service | Record responsibility for errors and recipients |
| Extension licence | Clarify continuation or replacement with its contract holder |
Identify the services that actually move
You can change the team maintaining the website without moving the domain to another registrar. Establish which accounts will stay and where a move is actually necessary.
ICANN describes a separate authorised process for the domain transfers it covers. Your domain extension and provider must follow the relevant rules. Confirm the actual transfer route instead of cancelling every service at once.
A mailbox or DNS record may remain necessary after the website moves. Knowing these dependencies before cancelling services helps you retain the connections still needed. Each actual migration needs a time, responsible person and a controlled fallback.
Give the new partner usable documentation
Alongside access, provide the currently published version, instructions for running and releasing it, known faults and planned work. For custom files and designs, clarify the agreed rights to use and modify them. Possession of a copy does not establish those rights.
The incoming team should first be able to reproduce the inherited setup. A limited trial involving a content edit or publication to a test environment shows whether important connections work. This makes handover problems visible before further changes obscure their cause.
Close the handover
During the transition, you need a named contact for failures so the previous and incoming teams do not each assume the other is responsible. After confirmed takeover, the responsible administrator adjusts access that is no longer needed. A handover record keeps outstanding issues visible and shows whether recurring invoices and reminders already reach the right person.
If the next step is maintaining the existing website, add that agreed scope to the handover record. Keep new design or development requests in a separate task list.
