The time to discover that your agency owns your domain is before you want to leave, and almost nobody does. The usual sequence: you decide to change vendors, you ask for access, and you find the domain registered in their name, DNS in their account, the site on their reseller hosting, and your business email attached to all of it.

This is recoverable, and it is the most stressful week of a website project if you do it in the wrong order. Here is the right order.

Step 1: find out what you actually control

Before you tell anyone anything, establish the facts. Each check is free and takes minutes.

The domain. Run a WHOIS lookup (ICANN's, or whois yourdomain.com; CIRA's for a .ca). You want the registrant name, the registrar, the admin email and the expiry date. If the registrant is your agency, or the admin email ends in their domain, the domain is not yours in practice.

DNS. The nameservers in the same lookup tell you whose service answers for your domain.

Hosting. Do you have a login that reaches a control panel or deployment dashboard? A CMS admin account is not hosting access.

Email. This is the one that bites. If your mail runs through the same provider as the site, moving hosting can take it down. Find out where your MX records point before you move anything.

The code and content. Is there a repository you can reach? Do you have the CMS database or an export?

Everything else. Google Business Profile, Search Console, Analytics, the certificate, and third-party accounts — payment processor, booking tool, email platform — set up on your behalf.

Write it into one list with a column for "who holds it". That list is your project plan.

Step 2: ask for access before you give notice

Ask for the handover as a routine administrative request, separate from any conversation about ending the relationship. Some agencies become materially less helpful once they know they are being replaced, and the access you have before that conversation is the access you can count on.

Send a plain email requesting, in writing:

Transfer of the domain registration to an account in your name, or the authorization (EPP) code and registrar unlock
Administrator access to DNS
Hosting credentials, or a full backup of files and database
Access to the code repository, or a zip of the source
Owner-level access to Search Console, Analytics and Google Business Profile
A list of third-party accounts tied to the site

Set a deadline, and keep the thread.

Step 3: secure the domain first

The domain is the asset. Everything else can be rebuilt.

For a .com, .org or similar: unlock the domain at the current registrar, obtain the EPP/auth code, open an account at a registrar you control, initiate the transfer, and approve the confirmation email. Transfers take a few hours to five days. A domain registered or transferred within the last 60 days is locked and cannot move.

For a .ca, transfers run through the registrars with their own authorization step and the registrant contact must approve. Check that the registrant email on file is one you can read, or the approval goes to the agency.

Afterwards, verify WHOIS shows you as registrant. If the agency offers to "just change the contact email", that is a partial fix. Push for the registrant change.

Step 4: take over DNS without downtime

Replicate before you switch.

Export or screenshot every existing record: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC and any verification records), SRV if present. Miss a TXT record and you break email deliverability or a service verification.
Create the identical record set in your new DNS provider, without changing nameservers yet.
Lower the TTL on the existing records to 300 seconds if you still have access, and wait for the old TTL to expire.
Change the nameservers at the registrar.
Watch for 48 hours. Check the site on cellular as well as office wifi, and send a test email in and out.

Email records are the most frequently broken item here. If your mail is on Microsoft 365 or Google Workspace, copy MX, SPF, DKIM and DMARC exactly and verify mail flow before you consider the move finished.

Step 5: move the site itself

How this goes depends on what you have.

You have the code. Stand the site up on new hosting, test it on a staging URL, then point DNS at it.

You have a CMS but no code. Export the content. For WordPress that means the database plus wp-content; the built-in XML export covers posts and pages and leaves out theme settings and some plugin data. For a proprietary CMS, export what the interface allows and expect to re-enter the rest.

You have nothing but the live site. A crawler such as wget --mirror retrieves the rendered HTML, CSS, images and PDFs. The CMS, the forms and anything server-side stay behind. For a small brochure site that is often enough to rebuild from, and worth doing as an archive regardless.

Take a full copy before you give notice, whichever situation you are in.

Preserve the URLs. If any page changes address during the move, set a 301 redirect from old to new. This is where a handover quietly costs traffic — our post on moving a site without losing SEO covers the redirect mapping.

Step 6: reclaim the Google properties

Search Console. Once you control DNS you can verify ownership yourself with a TXT record. Do this, then remove their access.

Analytics. Property access cannot be self-verified. If they will not grant you ownership, your option is a new property on your own account, starting history fresh. Export the reports you care about while you still have access.

Google Business Profile. If the agency is the primary owner, request ownership through Google's process. It takes time and goes through them first. A duplicate listing creates problems rather than solving them.

When they stop responding

Options, roughly in order of cost:

Escalate in writing with a deadline and a reference to your contract or invoices. Stay factual; this email may be read by someone else later.
Go to the registrar directly. With proof the business is yours — invoices, trademark, corporate registration — some registrars will act on a disputed registrant. This varies and is not guaranteed.
Use the dispute process. CIRA has a dispute resolution policy for .ca; .com and similar fall under UDRP. Both are slow and aimed at bad-faith registration rather than contract disagreements.
A lawyer's letter. Often the fastest thing that works once a relationship has broken down.
Rebuild on a new domain. A last resort, expensive in lost search equity, and occasionally the cheapest path.

Afterwards: make this impossible to repeat

Whoever builds your site next, settle these in writing before work starts:

The domain is registered to your business, in an account you log into, with an email address you read
You hold the registrar login; the developer gets DNS access as a user
Hosting and analytics are in your name with the developer added
The code lives in a repository you own
The contract states what happens at termination and what is handed over

We put this in writing by default on every web development project in Ottawa — you own the code, the domain and the accounts — because it is the easiest promise in the industry to keep. The questions worth asking any vendor are collected in how to choose an Ottawa web development company.

Common questions

Can an agency legally hold my domain?

If the domain is registered in their name they are the registrant, and that is a real legal position even when the business name is yours. The registrant field matters more than who paid the invoice. Contracts and trademark rights can override it; that is a dispute, with a dispute's timeline.

Do I lose my search rankings?

Not if the URLs and the content survive the move and the site stays available. Rankings move when pages change address without redirects, when content is dropped, or when the site goes offline for a long stretch.

What should I do if I am not planning to leave?

Run the WHOIS lookup and check your registrant name. Two minutes, and it is the difference between a routine handover and the week described above.

how to move your website away from an agency that holds it