Guide
Can you change website providers without losing your domain, email, Google visibility or bookings?
Yes. A practice can move its website to a new provider and keep its domain, its email, its Google rankings and its booking tool, provided the domain, the DNS records, the page addresses and the booking embed are handled in that order. This page gives the order and what Monograph does on a migration.
| What to keep | Where it lives | How it moves |
|---|---|---|
| Domain name | Your registrar account | It does not move. Only the records that point it at the website change. |
| MX, SPF, DKIM and DMARC records in your DNS | Copied exactly to the new DNS; nothing deleted | |
| Google visibility | Your page addresses and Search Console | Same addresses, or a permanent redirect for each old one; sitemap resubmitted |
| Search Console verification | A TXT record in your DNS | Stays; never removed during a move |
| Booking tool | The vendor's embed code or link | The same code placed on the new pages |
| Content and images | The old site | Exported or rewritten before the old plan is cancelled |
Your domain
Everything else depends on who controls the domain. If it is registered in your practice's own account, you can point it wherever the new site lives and nothing else in this guide is at risk. If an agency registered it in its own account, ask for a transfer to an account in your name before you change anything, cancel anything or announce anything. A transfer takes a few days and needs an authorization code from the current registrar; the agency should provide it without conditions.
Your email
Email does not live on the website, but it lives in the same DNS zone, which is why it is the thing most often broken by a website move. Four records carry it: MX, which says where mail is delivered; SPF, DKIM and DMARC, which prove your mail is yours and keep it out of spam folders. Before anything changes, every record in the zone is written down. When the new DNS is set up, those records are copied exactly, and the Search Console verification record and any other verification records are left in place. Nothing is deleted. If you also want to move your email to a new provider, that is a separate project with its own plan.
Your Google visibility
Google ranks pages, not websites, and it finds them by their addresses. Keep the same addresses on the new site wherever you can. Where an address must change, give the old one a permanent redirect (a 301) to its replacement, one for one, so a patient's bookmark and Google's index both land in the right place. Resubmit the sitemap in Search Console on launch day, and check that no page on the new site is set to noindex, which is a common leftover from a preview build.
The most common cause of lost rankings after a rebuild is a new site with new addresses and no redirects. It is also the most avoidable.
Your bookings
An embedded booking tool such as Jane, Cortico or OceanMD lives at the vendor, not on your website. It moves by placing the same embed code or link on the new pages; appointments and patient records stay where they were. A scheduler that was built into the old website platform is different: it will stop when the old plan is cancelled, so export the upcoming appointments and the patient list before you cancel, and choose a standalone tool for the new site.
The order of operations
- Lower the DNS time to live a day ahead.So that when the records change, the change reaches everyone within minutes rather than a day.
- Map every record and every page.Every DNS record with its purpose, and every old page address with where it will go.
- Build the new site on a preview address.Test it fully there, including the booking embed and every form, before it touches your domain.
- Switch the website records when the new site is ready.Change only the A or CNAME record for the website, or the nameservers if the whole zone is moving with every record already copied.
- Keep the old host live for a week.Watch Search Console and the redirects, then cancel the old plan once nothing is falling through.
What Monograph does on a migration
Every Monograph rebuild includes this work: an inventory of every address on the old site, a permanent redirect for each one tested before launch, DNS changes made in your own account with the email and verification records left alone, the sitemap submitted to Google and Bing on launch day, and Search Console watched for errors in the weeks that follow. The commercial page is Moving your website without losing search, and it is included in every build.
Questions practices ask
Can I change my web hosting provider and still keep my domain name?
Yes. Hosting and the domain are separate services. If the domain is registered in your own account, you keep it and point it at the new host by changing the DNS records. If your old provider registered it in their account, ask for a transfer to your own account before you cancel hosting.
Will we lose our Google rankings if we rebuild the site?
Not if every page keeps its address, or is given a permanent redirect to its replacement, and the new site is submitted to Search Console without a noindex tag. The most common cause of lost rankings after a rebuild is new page addresses with no redirects.
Will our email stop working during the move?
It should not. Email is carried by the MX record and protected by the SPF, DKIM and DMARC records. If those are copied exactly to the new DNS and nothing is deleted, mail keeps flowing while the website changes. Moving email itself to a new provider is a separate project.
How long does a move take?
The build takes as long as the build. The switch itself is a day: the DNS time to live is lowered a day ahead, the records are changed when the new site is ready, and the old host is kept live for about a week in case anything was missed.
- Applies to
- Practices in Canada moving a website from one agency, host or platform to another
- Primary source
- Monograph's migration checklist, used on every rebuild, and Google Search Central's documentation on site moves with URL changes
- Source date
- 30 September 2026
- Last reviewed
- 30 September 2026
- Reviewer
- Behnaz Alijani, Pharm.D.
- What this page does not cover
- Moving a patient portal or a clinical record system, and the terms of your contract with the provider you are leaving