How to Protect Website, Domain and Analytics Access During an Agency Change

By Blackbird Marketing
Keep the domain, website, hosting and measurement accounts under the trade business’s control when changing agencies. Create named access for the new people, take usable backups, check customer contact routes and remove the outgoing supplier only after the replacement access has been tested.
Do not assume that an agency login equals ownership. A supplier may manage a registrar, website platform or analytics property without the business having the recovery details needed to renew, update or move it.
In short: Map every account, confirm the business owns the important ones, use named users with multi-factor authentication, preserve the data and test the website before closing the old access.
Which accounts should the business control?
Start with an asset register. For each platform, record who owns it, who can administer it, how access is recovered, who pays for it and when the next renewal is due.
Domain registrar and renewal account
Website hosting or server platform
Content management system or website builder
Business email and the DNS records supporting it
Google Analytics 4 and Google Search Console
Google Business Profile and other important listings
Google Ads, Microsoft Advertising or other paid-media accounts
Forms, booking, call-tracking, cookie-consent and email platforms
Backups, security tools, plugins, themes, licences and integrations
Not every business will use all of these. The point is to document the actual setup rather than treating the website as one account with one password.
Put the domain first
The domain controls the address customers use and often connects to the website, email and verification records. The business should be able to access the registrar with a business-controlled email address, without depending on a former supplier.
Check the renewal date, payment method, recovery details, two-factor authentication and any transfer lock. Keep a copy of the current DNS records before making changes, including entries for email, website hosting and third-party verification.
Do not change nameservers as a routine handover step. A seemingly small DNS change can affect both the website and email, so establish what each record does and test the result after any alteration.
Check hosting and the website platform
Ask where the site is hosted, who pays for the account and whether the business has administrator access. Obtain a current copy of the website files and database where the platform uses one, stored somewhere the business can reach.
A backup is not fully useful until its contents and restoration route are understood. Record the platform, server or PHP requirements where relevant, active plugins, themes, licences, integrations and custom code so the incoming provider can judge whether the existing site is maintainable.
If the old supplier uses a proprietary or shared system, clarify what can be exported. The answer may affect whether the business keeps the current site, moves it or commissions a replacement.
How should access be transferred securely?
Use each platform’s invitation system to create named accounts. Avoid a single shared administrator login, because it makes it difficult to see who has access and impossible to remove one person without changing the password for everyone.
Give people only the permissions needed for their work. The business owner or nominated manager may need the highest level, while someone producing reports or editing content may not need billing, user-management or security control.
Keep an access register, not a password list
Record the following in a restricted password manager or other secure system:
Platform and account name
Business owner and primary administrator
Named users and permission levels
Recovery email and phone details
Multi-factor authentication status
Billing owner and renewal information
Date the details were last checked
Do not put live passwords into an ordinary spreadsheet or send them by unprotected email. Use platform invitations or secure password-manager sharing instead.
Replace shared credentials and keys
If a former agency used a shared password, change it after the new access has been confirmed. This applies to the registrar, hosting, CMS, email, databases and third-party platforms.
Review API keys, application passwords and tokens as well. They may be used in plugins, scripts, tracking tools or automations without being obvious from the main account screen. Ask which credentials need revoking, then have the continuing provider create replacements where required.
Store recovery codes with the business. If a password or recovery detail has already been sent insecurely, treat it as exposed and rotate it once the new arrangement works.
What data should be retained during the handover?
Access alone is not enough. Retain the information needed to operate the site, understand previous work and diagnose a problem if tracking or customer contact routes change.
Website files and database backup
Current DNS records and notes about unusual entries
Analytics property, data stream and conversion details
Search Console ownership, users and verification methods
Business Profile ownership and managers
Advertising access, billing details and campaign history
Form, phone and booking tracking settings
Redirects, recent technical changes and important scripts
Content, brand files and image licences
Hosting, plugin, theme and software renewal details
A PDF report is not a substitute for account access. It may show selected figures, but it will not normally allow the next provider to inspect settings, diagnose tracking or continue existing work.
Review analytics and tracking connections
Check that the business can administer the Google Analytics 4 property and that the correct data stream is receiving information. Record important events, conversions, referral exclusions, linked advertising accounts and custom definitions that affect reports.
Then trace how data reaches the property. Tracking may depend on Google Tag Manager, a consent platform, call tracking, a booking system or code placed directly into the site. Removing one part without checking the connection can stop measurement while the pages still appear to work.
For a separate comparison of website and paid-advertising figures, see How Should a Trade Business Compare Website Analytics with PPC Reports?
Keep search and local listing ownership
Search Console should include a business-controlled owner or administrator, not just an agency user. Check the verified methods, users, sitemap settings and any important historical information before changing permissions.
Where the business uses a Google Business Profile, confirm the primary owner account, website address and telephone number. Remove former users only after the replacement access has been confirmed.
Do not delete historic analytics properties, advertising accounts or listings simply because the supplier is changing. Preserving the account can retain useful history for comparison and troubleshooting.
How can the change avoid downtime?
Deal with the assets that can interrupt enquiries first: the domain, DNS, hosting, forms, telephone links, email and any booking or payment route. Make one change at a time where practical and record the date, person responsible and result.
Map the setup. List every platform, account, owner, user, recovery method and renewal date.
Create new access. Invite the business and incoming provider through named accounts.
Verify permissions. Log in and check that the required settings and historic data are visible.
Take backups. Save files, databases, configuration details and key content outside the outgoing supplier’s system.
Test customer routes. Submit forms, check telephone links, review email notifications and inspect important pages on mobile and desktop.
Check DNS and email. Confirm that website, mail, verification and other necessary records remain present.
Remove old access. Revoke former users, rotate shared passwords and replace sensitive keys after testing is complete.
If the outgoing supplier controls technical systems the incoming provider has not yet seen, a short managed overlap may reduce risk. The business should still remain the account owner and decision-maker during that period.
Keep a change record
Note what changed, when it changed, who made it and what happened afterwards. This gives the business a starting point if a form stops working, email is delayed or reported traffic changes.
Keep copies of redirect lists, DNS records and tracking settings before editing them. That record is particularly useful if the new provider recommends replacing part of the existing setup.
What should be agreed with the outgoing agency?
Request a written handover covering account ownership, access, backups, licences, outstanding work and known technical issues. Keep the questions tied to identifiable business assets rather than accepting a general statement that everything has been transferred.
Which accounts are owned by the business and which are held by the supplier?
Are any domains, hosting packages, licences or subscriptions due for renewal?
Are there transfer locks, unpaid invoices or contractual restrictions affecting access?
Where is the latest backup, and when was it created?
Which forms, phone numbers, tracking tools and automations connect to the site?
Are any administrator accounts, passwords or API keys shared?
Which redirects, tags, plugins or custom scripts were added?
Are there known security warnings, broken functions or unfinished changes?
Contract terms may affect ownership of code, content, licences or hosting. If there is a dispute, retain evidence of payments, account ownership and correspondence, and obtain appropriate professional advice instead of attempting a rushed technical transfer.
When is a rebuild worth considering?
A new site is not automatically needed because the agency is changing. Keeping the existing one may be sensible when the business controls the domain, the platform is maintainable, reliable backups exist and the incoming provider can work on it safely.
A replacement deserves consideration when the site is tied to an inaccessible proprietary system, uses unsupported software, has unknown administrator accounts, lacks dependable backups or cannot be updated without the former supplier.
Before deciding, account for redirects, existing URLs, forms, analytics, content and any useful history. Blackbird Marketing’s published business website information says its sites for small businesses are designed to be clean, fast and mobile-friendly; if the handover reveals that the current platform cannot be maintained, the business can review the published business website service information and ask whether it suits the job.
Ask how the domain will remain under business control, how existing URLs will be handled, what happens to measurement and forms, and which parts of the current site can be retained. A visual redesign does not solve an ownership or access problem by itself.
Final checks before removing old access
Complete these checks only after the new business and provider accounts have been tested:
The registrar account is controlled by the business.
Renewal dates and payment details are understood.
Hosting and CMS administrator access work.
A recent backup is available outside the former supplier’s system.
Forms, calls, email notifications and booking routes have been tested.
Analytics, Tag Manager and Search Console access are correct.
Advertising and local listing ownership is confirmed where relevant.
DNS records and email operation have been checked.
Shared passwords have been replaced and multi-factor authentication is active.
Former users, old keys and unnecessary integrations have been removed.
The aim is not to make the outgoing agency inaccessible immediately. It is to ensure the trade business can operate, renew, update and measure its online presence without depending on a supplier that no longer manages it.
Need help deciding whether the current site can be retained? If the handover has exposed gaps in ownership, access or maintenance, discuss the requirements through Blackbird Marketing’s business website service.
.png)
.png)
.png)


