You're switching agencies or hosts for the website that brings in your leads, and you can't afford a quiet week. The pages can load fine while a form still sends through the old operator's account, or a tracking number sits on a subscription nobody renewed. Treat the move as a handover with a test for each route: domain, forms, phone and analytics.
On an owned network from Garrison, the microsite software from Trojan Digital Marketing, the domains are registered to your business, so that route stays in your name. If you're planning a move, the first strategy call is free, and during business hours we aim to reply within five minutes.
Identify which transition is actually happening
Changing agencies, changing hosts, moving a domain between registrars, changing the public domain, and rebuilding the website are different actions. They can happen together, but combining them unnecessarily makes problems harder to diagnose. Name the required change and the reason for it.
The owned channel framework helps separate control from operation. A business may need new administrative access without moving the site at all. It may need new hosting while keeping the same domain and URLs. Choose the smallest transition that fulfills the actual scope.
Confirm the right to receive and operate the components
Review the agreement before preparing the technical move. Identify which domains, files, content, accounts, and data exports are included. If an item is disputed, do not treat a technical workaround as a resolution of the underlying issue.
The agreement review checklist gives both teams a shared list. Record any third party subscriptions or licenses that the receiving business needs to maintain. A handover date is easier to plan when those dependencies are known.
Create a dependency inventory
List the systems that make the site work: registrar, DNS, hosting, CMS or repository, email delivery, forms, CRM, phone routing, analytics, advertising, and integrations. For each, identify the current owner, receiving owner, billing responsibility, recovery contact, and acceptance task.
The account inventory guide can provide the working format. Keep secrets in the approved credential system. The inventory should tell people where responsibility sits without exposing passwords or recovery material to everyone involved.
| Dependency | Question before transfer | Acceptance check |
|---|---|---|
| Domain and DNS | Who can manage the settings and renewals? | Receiving owner can inspect the correct account |
| Website release | Can the delivered site be maintained? | A harmless draft change can be made and reversed |
| Forms | Which service delivers the inquiry? | A labeled request reaches the intended destination |
| Phone routing | Who controls each public number? | A test call follows the approved route |
| Measurement | Which property records the live activity? | The receiving team can identify the test evidence |
Preserve a usable baseline
Save the current site files or appropriate export, configuration notes, URL inventory, and relevant reporting definitions. Confirm that the backup can be opened and that someone understands how it would be used. A file labeled “backup” is not enough evidence by itself.
Record the current contact routes and known defects. If a form already has a problem before the move, documenting it prevents confusion about what the transition caused. Keep a change log with the time, responsible person, and business effect of each meaningful adjustment.
Handle domain administration deliberately
A registrar transfer has its own process. ICANN explains the authorization code role in registrar transfers. Check the current registrar's procedure and the domain's actual status before committing to a date.
Do not assume that transferring the registrar also moves hosting or email. These services can be separate. The responsible technical team should document which settings will change and how it will verify that the required services continue working.
If only the operator changes, we'd usually skip the registrar move. Giving the new team access on the business's own account can cover it with fewer changes, and every change you skip is one less thing to test. The decision should follow the agreed handover need.
Keep public URLs stable where the project allows
A host or agency change does not inherently require a new public URL structure. If URLs do change, plan the mapping rather than sending every old page to an unrelated homepage. Google's site move guidance addresses the additional search considerations when public URLs change.
A website project should distinguish migration work from design improvements. That makes it possible to review whether the required continuity tasks were completed even if optional content changes continue afterward.
Test the complete inquiry, not just the success screen
- Relevant visit
- A person reaches the page.
- Inquiry
- The person contacts the business.
- Qualified lead
- The inquiry meets the agreed rules.
- Booked job
- The customer chooses to proceed.
This is the check we'd never skip: submit a labeled request through each important form. Confirm the destination, record creation, source information, assignment, and notification. The office should show that it can find the request and identify the next action. Remove or clearly mark test records in reporting.
Test phone routes separately, including the expected behavior when the first person cannot answer. Review integrations that depend on a departing user's authorization. An automation scope should identify the trigger, connected accounts, failure behavior, and human owner so these dependencies can be transferred deliberately.
Use a staged acceptance window
In a hypothetical handover, the receiving team first confirms access and opens the delivered files. It then tests the site and contact routes in the agreed environment. After the live change, the office verifies a labeled inquiry and checks the expected reporting evidence. Only then does the team close the transition tasks and remove access that is no longer needed.
The sequence should include a response plan for a failed check. Identify who can correct the route or restore the previous configuration, and what evidence will justify that action. A reviewable recovery plan is more useful than assuming every change will work on the first attempt.
Verify the recovery route
Ask the receiving owner to identify the approved account recovery contact and confirm that it remains available after the transition. A working login today does not establish recoverability tomorrow. Record where authorized staff obtain support and who will handle an access failure without relying on a former operator's personal inbox.
Close with responsibilities, not a final folder
Give each renewal, bill, monitoring task and vendor contact to a named person. Keep unresolved exceptions visible with due dates. The handover is complete when the receiving business can operate the channel and understands the remaining obligations.
Request a free marketing audit if a website transition is exposing unclear account control or inquiry routing. A defined review can identify the dependencies that need attention before the next transfer step.
