Switching agencies can grind to a halt when accounts, code and domains are controlled by the previous provider. Here are the assets and permissions you need to secure before terminating the contract.
Do you really own your website—or have you merely been granted permission to log in? If the domain, DNS settings, server or recovery address is held in the web agency’s account, the answer is simple: your company lacks the control required to switch providers on its own terms.
An agency switch can therefore come to a halt at the very first DNS change. The company may be named on the invoice, but the former agency is the registered account holder, receives password recovery messages and is the only party able to retrieve the domain transfer code. A seemingly straightforward migration then depends on a terminated provider continuing to provide assistance.
The risks are not limited to website operations. If the source code, databases, analytics accounts and integration keys are also tied to the agency, the switch may result in broken forms, lost tracking, disrupted order flows and higher costs to rebuild existing functionality. Ownership, permissions and working backups should therefore be verified before the contract is terminated.
The company must own the root accounts—not merely have a login
The company must be the registered owner and primary administrator of the root accounts that control the domain, DNS, web hosting or cloud platform, CDN, email domain, CMS, code repositories and deployments. A WordPress administrator can edit pages and install plugins, but cannot migrate the website if the agency has sole control of the server, name servers and billing.
The domain’s registrant details, the account with the registrar and the account where the DNS zone is managed may also be held by three different providers. Control must therefore be verified separately at every stage and include any EPP or transfer code. Create company-owned primary accounts using a role-based address such as webbadmin@företag.se, the company’s payment method, multi-factor authentication and at least two internal administrators. Agencies can then be given named, time-limited permissions instead of a shared password. You should also review who owns the GitHub organisation, who can modify the CI/CD pipeline and whether hosting, Cloudflare or another CDN, SSL certificates and cloud projects can be administered without the departing agency’s personal account or authentication app.
A complete handover involves more than the website files
The handover should document a functioning system environment rather than simply provide a ZIP file with unclear contents. A WordPress website requires source code or custom themes and plugins, a database dump and the complete media library from the same point in time. A file copy without the database contains no pages, users or form submissions, while a database without the uploaded files results in broken images and documents.
For an e-commerce or integrated website, the package must also make it possible to recreate product feeds, order connections, webhooks, scheduled jobs and the environment variables required to start the application. API keys, database passwords and other secrets should be inventoried in a password manager instead of being sent by email or stored in the Git repository, and the keys should be rotated when the former agency’s access is revoked. The final proof is a test restoration in a separate staging environment, where the new agency can launch the website, check the integrations and document any licences, configurations or dependencies that are still missing.
Analytics and marketing history must be transferred without restarting measurement
GA4, Google Tag Manager, Search Console, advertising accounts, Merchant Center, Meta Pixel, the consent platform and CRM integrations are company data, even when the agency has set them up. In GA4, the company needs administrator access at the account or property level, along with documented details of conversions, audiences, filters, data streams and links to platforms such as Google Ads.
Do not accept a new GA4 account as the default solution, as this breaks comparability over time and may leave previous campaign and conversion data with the provider. In Google Tag Manager, the new agency should continue working in the same company-owned container after creating a version backup, allowing form, purchase and consent events to be compared before and after launch. Search Console should have a company-owned user with full permissions and preferably domain-level verification via DNS. Advertising, Meta, Merchant Center, consent and CRM accounts should also be reviewed to ensure that audiences and integrations do not remain dependent on the agency’s internal accounts.
Plan a controlled transition before revoking the former agency’s access
Treat the agency switch as a technical cutover with a named person in charge, clear approval points, test protocols and a defined rollback threshold. Ideally, do not move the domain registration, DNS, hosting and email at the same time, as separate steps make it possible to isolate an issue and roll back without affecting the entire digital environment.
Lower the DNS records’ TTL well in advance and export the entire DNS zone before repointing it, paying particular attention to MX, SPF, DKIM and DMARC so that a website migration does not disrupt the company’s email. Content changes should be frozen during the final database synchronisation. Forms, purchases, payments, logins, email delivery, redirects, analytics and webhooks should then be tested in the new environment before DNS is repointed. The former agency’s users should only be removed once operations and tracking have been approved. Passwords and API keys should then be rotated, and an access register should be retained showing exactly which permissions were revoked.
Criteria for a secure agency switch
Assess the planned transition in terms of ownership, handover, data continuity and implementation. Require responsibilities, permissions, deliverables and approval points to be documented before the switch begins.
Ensure that the company owns all root accounts
The company must be the registered owner and primary administrator of the domain, DNS, web hosting, CMS, email and other business-critical services. A standard user login is not sufficient, as it can be restricted or removed by the agency that still controls the primary account.
Indicator: Confirm that the accounts are registered using the company’s legal details, payment method and email address, and that at least two internal users can change permissions and complete account recovery.
Require a complete and verifiable handover
The handover needs to include databases, source code, uploaded files, integrations, licences, themes, plugins, documentation, backups and relevant agreements. The material must be restorable and usable without requiring the former agency’s server, private GitHub account or proprietary licence keys.
Indicator: A well-planned provider transition includes a written inventory and allows the new agency to verify the files, database, licences and backup in a staging environment before the contract ends.
Preserve analytics and marketing history
Existing GA4, Google Tag Manager, Search Console, Google Ads and Meta accounts should be assigned new company-owned administrators instead of being replaced without technical justification. This preserves historical data, audiences, conversion definitions and the ability to compare performance over several years.
Indicator: Be cautious if a provider proposes entirely new analytics or advertising accounts without first explaining who owns the existing accounts and why their history cannot be preserved.
Plan a controlled transition with an overlap period
The plan should specify when backups will be taken, when content will be frozen, which tests will be performed, when DNS will be changed and under which conditions the environment should be rolled back. The former agency’s permissions need to remain in place until the new provider has verified both technical operations and data collection.
Indicator: Confirm that the schedule includes named owners, clear approval points, contact channels during launch and a contingency plan that can be activated without first having to negotiate it.
Revoke permissions without creating new risks
Once the transition has been approved, old users, API keys, integration accounts and shared passwords should be removed or replaced. At the same time, the company needs to document its current administrators, recovery addresses and backup codes, and implement multi-factor authentication wherever the service supports it.
Indicator: A reputable provider carries out a joint final review of permissions and supplies an updated access register that the company can review and manage itself.
Start here—secure access, data and a controlled agency switch
-
Map and verify all digital assets
Create an asset inventory in Google Sheets covering the domain, DNS, web hosting, CMS, databases, email, Git repositories, third-party licences, GA4, Google Tag Manager and Search Console. Log in to each service using a company-owned account and document the actual owner, internal administrators, recovery address, payment responsibility and missing permissions. The result should be a verified map of what must be transferred or secured before giving notice—not a list based solely on information from the departing agency.
-
Transfer ownership to company-controlled accounts
Create role-based administrator accounts on the company’s own email domain and store login details and backup codes in a tool such as 1Password or Bitwarden with multi-factor authentication. If the company is FLAR AB, FLAR AB should be listed as the registrant with the domain provider and have owner or administrator permissions in WordPress, Cloudflare, GitHub, GA4, Google Tag Manager and Search Console. Once at least two internal users can invite and remove users, the current agency is no longer the company’s only access point.
-
Create complete and verified backups
Export the website files, database, media library, DNS records, form data and configurations using the web host’s tools and, if necessary, a WordPress plugin such as UpdraftPlus. Store at least two copies in separate environments, such as Google Drive and an encrypted local drive, so that closing an agency account does not also make the backup inaccessible. Restore the material in staging and document the date, software versions, test results and any errors until you have a proven, working recovery point.
-
Complete the handover using a signed checklist
Use Asana, Trello or Jira to assign an owner and deadline to code, design files, licences, integrations, documentation, outstanding issues and provider contacts. The departing agency should confirm what has been delivered, while the incoming agency verifies that the material can be opened, deployed and maintained. When both parties approve every item in writing, any remaining dependencies become visible before they develop into urgent additional work.
-
Make a controlled switch and monitor the site after launch
Lower the DNS records’ TTL to 300 seconds, for example, at least 24 hours before the migration and carry out the repointing during a period of low traffic. Test critical flows using tools such as Screaming Frog, PageSpeed Insights and GA4 DebugView, as well as real form submissions or test purchases, while also confirming that email authentication, redirects and webhooks work correctly. Monitor availability with UptimeRobot and track traffic, conversions and server errors for at least seven days so that functional or tracking issues are detected while the rollback plan is still viable.
Do not terminate the existing agency’s contract until ownership, backups and a tested restoration have been confirmed. Once the new environment has remained stable for at least seven days, old permissions can be removed, passwords and API keys rotated, and the handover formally completed.
