How do I move my website to a new provider?

The move is a procedure, not a negotiation

Most owners approach a provider change as though they need permission. They do not, provided one thing is true: the domain is registered in their name. Everything else in a website move is a copy operation.

The rules here are international and published. Under the ICANN Transfer Policy, Registered Name Holders must be able to transfer their domain name registrations between registrars, and transfer processes must be clear and concise [1]. A registrar of record may deny a transfer only in a short list of enumerated instances — evidence of fraud, a reasonable dispute over the identity of the holder, no payment for a previous registration period, a request made within 60 days of the creation date, or a request made within 60 days after a previous transfer — and on denial it must give the reason both to you and to the gaining registrar [1]. Where a registrar has applied a ClientTransferProhibited lock, that lock must be removed, or an accessible method of removing it provided to the holder, within five calendar days [1].

Read that last sentence again, because it converts the most common stalling tactic into a deadline. "We'll get to it" is not a policy position.

None of this helps if the registration is in someone else's name, which is why this is worth checking today rather than on the day you decide to leave. We cover the ownership question in who owns my website and my domain?.

The order of operations

1. Establish what you actually hold. Four things: the domain registration and the account it lives in, the DNS records, the website files and content, and the email. They are frequently at three different companies even when one invoice arrives.

2. Get a copy before you give notice. Text, images, testimonials, your logo files in a usable format, and an export of the site if one exists. Ask while the relationship is normal. If the honest answer is that no export exists because the site lives inside a proprietary builder, that is a real switching cost and it should be priced into the decision.

3. Build and test the new site first. Nothing public changes at this stage. The new site is assembled and reviewed while the old one keeps taking calls.

4. Move email as a separate, deliberate step. Email is what breaks. Hosting and mail are commonly sold together, and the DNS records that route mail are different from the ones that route the website. Confirm where mail is currently delivered, decide where it will be delivered, and test with a real message before and after. An hour of lost email costs more than a day of lost website.

5. Switch DNS. Lower the record lifetimes in advance if you can, make the change, and expect a period where some visitors see the old site and some the new. This is normal and short.

6. Cancel last. Keep the old service running for a couple of weeks after the switch. Cancelling first is how sites disappear for a weekend.

Keeping your addresses working

If your page addresses change during the move — a common side effect of changing platforms — do not let the old ones simply 404. The correct signal is a permanent redirect: RFC 9110 defines 301 (Moved Permanently) as indicating that the target resource has been assigned a new permanent URI and that future references ought to use one of the enclosed URIs, with the server suggesting that a client capable of link editing can permanently replace the old reference [2]. Keep those redirects in place for at least a year. Cards, invoices, other people's links and old search results all point at the old paths.

Two files deserve a look on launch day. First, robots rules: crawlers match the group whose product token corresponds to their own name, and where no rule in the matching group applies, or the group has no rules, the URL is allowed [4]. A blanket disallow carried over from a staging copy is the classic way a freshly migrated site quietly vanishes from results. Second, the sitemap: the protocol expects a urlset with one url entry per page, entity-escaped, UTF-8, with all URLs from a single host, plus a documented way of informing crawlers it exists [5]. Regenerate it after the move rather than migrating a stale copy. More on all of this in how do customers actually find my website?.

What a move should cost you in downtime

Done in the order above, close to nothing. The website itself never goes dark, because the new site is finished and tested before a single public record changes; the switch is a DNS edit, and visitors move across as their networks pick up the new record. Email is the only part with real exposure, and even that is measured in minutes if the destination is set up and tested first rather than at the same moment the site moves.

What does take time is calendar time, not outage time. A domain transfer between registrars is not instant, a lock can legitimately take up to five calendar days to come off [1], and a transfer requested within 60 days of the domain's creation or of a previous transfer can be refused outright [1]. So start the domain step early and treat everything else as parallel work. The mistake that causes actual downtime is almost always sequencing: cancelling the old service, or letting a registration lapse, before the new one is proven.

The data nobody remembers to move

Old contact-form submissions, quote requests and mailing list records are personal information sitting in an account you are about to abandon. PIPEDA's Schedule 1 requires knowledge and consent for collection, use and disclosure, says information must not be used or disclosed for purposes other than those for which it was collected without consent, and provides that information no longer required should be destroyed, erased or made anonymous, with organizations developing guidelines and implementing procedures to govern destruction [3]. Practically: export what you still need, ask the old provider to delete the rest, and get the confirmation in writing. See does my small business website need a privacy policy?.

Why this matters more than it sounds

Switching cost is not really a technical question. It is the reason people stay somewhere they are unhappy. As of December 2024 there were 1.10 million employer businesses in Canada and 1.08 million of them — 98.2 per cent — were small businesses [6]; in New Brunswick, 20,256 of 20,631 employer businesses are small [6]. A very large number of them are paying for a site they cannot edit, from someone they cannot reach, because leaving feels like it might break something.

The honest answer is that leaving is a checklist. The parts that feel frightening — the domain, the email, the old links — all have defined, published mechanics. The part that is genuinely difficult is a site locked inside a builder with no export, and the way to avoid that one is to ask about it before you buy, not after.

Where we sit

A maple.website build starts at $50, covering 20,000 characters of copy, 4 custom images and 2 hours of work; beyond that, extra copy is $0.20 per 1,000 characters, extra custom images are $2 each and extra hours are $40 per hour, always quoted in advance. Hosting is $10 CAD per month including SSL, a CDN and daily backups, on a domain you own and control. All prices CAD; HST extra where applicable. Turnaround is 48 hours from brief to live.

The domain being yours is the point, not a feature. It means your ability to leave rests on a published international transfer policy rather than on our goodwill, and it means the worst case if we disappear tomorrow is an inconvenient afternoon rather than starting over. If you are moving to us, we will do the checklist above with you in that order, and we will not touch your mail routing without telling you first. If you are moving away from us, ask and we will hand over what we hold.

Before you commit to any provider, ask the leaving question first: what do I get if I go, and how long does it take? A supplier who answers that plainly is telling you something about the whole relationship. So is one who does not.