Will my site go down during the move?

It should not, and the method is what prevents it. The new site is built and fully tested while the old one keeps serving traffic, and the switch is a DNS change made in a planned window. What varies between visitors is which copy they reach during propagation, which is why both sites stay live and working until the change has fully settled.

My old agency controls my hosting and domain. Can you still move it?

This is one of the most common reasons people ask, and usually yes. What is needed is registrar access or an authorisation code for the domain, and either hosting access or a recent full backup. If neither can be obtained, a site can often be rebuilt from a crawl and the archive, but that is a different job with a different price and we would say so plainly.

Will my email keep working?

Only if it is treated as its own task, which is how we treat it. Email attached to the old hosting is the single most dangerous part of any move, because a DNS change made for the website will take the mailboxes with it. MX and authentication records are recorded before anything changes and migrated deliberately, on their own schedule.

Will I lose my Google rankings?

A same-platform hosting move should not touch them at all, since the URLs do not change. A platform or domain change does move things, and the protection is a complete crawl of the old site, a redirect for every URL, and Search Console watched afterwards. There is usually a brief unsettled period on a domain change even when everything is done correctly.

How long does DNS propagation actually take?

Most visitors see the change within hours, and the tail can run to a couple of days depending on what TTL was set beforehand. Lowering the TTL a day ahead of the move shortens that tail considerably, which is why it is scheduled as its own step rather than remembered on the day.

What if something goes wrong halfway through?

The old environment stays intact and untouched until the new one has been verified, so reverting is a DNS change rather than a rebuild. The rollback route is written down before the move begins, along with what it costs in time, so the decision is not being improvised under pressure.

Web Development & Engineering

Website migration

A move of host, platform or domain done in a planned window — with the new site fully tested before a single DNS record changes.

From: $400–$3,000
Typical time: 1–3 weeks
Usually bought by: Growing businesses

What this actually solves

Three situations bring people here, and they feel very different from the inside.

The first is money and speed. The hosting bill has crept up, or the server is the slowest part of an otherwise fine site, and moving is cheaper than optimising around it. The second is change in the business — a rename, a merger, a rebrand — and the domain has to follow.

The third is the one that arrives with real anxiety attached. The site was built by an agency or a freelancer who put it in their own hosting account, under their own domain registration, with their own logins, and that relationship has ended. The owner does not hold the keys to their own website. Every request for access is a favour. This is far more common than anyone admits, and getting out of it is the whole job.

Whatever the reason, the risk is identical and it is concentrated in two places. Search engines have addresses for your pages and expect to keep finding them there. And the domain that points at your website usually also points at your email — so a change made carelessly for the site takes the mailboxes down with it. A website coming back an hour late is an inconvenience. Email going dark for a day is the thing people never forget.

What we do, and in what order

Take a complete backup and a complete inventory, before touching anything. Files, database, email settings, and a full export of the current DNS zone — every record, not just the ones we expect to change. Alongside it, a crawl of every existing URL. This happens before any new environment is created, because the value of a backup is decided by when it was taken. Half a day.
Build and test the new environment while the old one keeps serving. The site is stood up at the new host and exercised properly — forms submitted, checkout run if there is one, admin logins tried, images and fonts confirmed loading. Crucially this is done at the temporary URL, or by pointing a local hosts file at the new server, so the testing is against the real destination rather than a hope. No DNS is changed yet. Two days to two weeks, depending on whether the platform is changing.
Prepare the cutover. TTL on the relevant DNS records lowered a day in advance so the change propagates quickly rather than lingering for days. A window agreed with you, in your quietest traffic period. The redirect map finalised if URLs are changing. And a written rollback — what we revert, in what order, and how long it takes. Half a day, plus the day of lowered TTL.
Cut over, in a fixed order. Website DNS first, then the SSL certificate issued and confirmed on the new host, then the redirects verified by re-crawling the old URL list. Email records are handled as a separate, deliberate step with their own verification — sending and receiving both tested from outside the organisation, not just from a mailbox that happens to be open. dig and nslookup are used to check what DNS is genuinely answering, rather than trusting a control panel that shows what it was asked to do. Half a day to a day.
Watch for two weeks. Search Console re-registered for the new property where the domain changed, sitemap resubmitted, coverage and 404 reports checked repeatedly, uptime monitored, and mail flow confirmed over several days rather than once. Anything that surfaces gets fixed while the old environment is still available to check against. Periodic checks across two weeks.

What moves the price

The range is $400–$3,000, and it moves on three things.

Whether the platform changes or only the address. Moving the same WordPress site to better hosting is the cheap end — the content arrives in the same shape it left. Moving between platforms means content has to be transformed, and every page type, custom field and embed has to be rebuilt or mapped. That is a different order of work entirely.

Whether email is coming too. Migrating mailboxes carries a level of risk and responsibility that website files do not. Historic mail has to arrive intact, authentication records have to be reissued so messages are not treated as spam afterwards, and a mistake is immediately visible to everybody in the business. It is priced separately because it deserves separate attention.

How much traffic and history there is to protect. A site nobody visits can be moved quickly. A site with years of accumulated rankings and inbound links needs a full crawl, a mapped redirect for every URL, and post-launch verification — care that is worth buying precisely because there is something to lose.

What usually goes wrong

DNS is switched before the new environment was properly tested. The move looks done, traffic starts arriving at the new server, and only then does anyone discover the contact form is not sending, or the payment gateway keys were never copied across. Now it is breaking in public and the pressure is on. The whole point of testing at a temporary URL or through a hosts file is that this is discovered while it is still nobody's problem.

Email is treated as part of the website move. The hosting is changed, the DNS records are updated to point at the new server, and the mail records go with them because they lived in the same zone. Mailboxes stop receiving. Old messages may be sitting on a server that has just been cancelled. This is the failure that damages the relationship, and it comes from thinking of the domain as belonging to the website when it belongs to both.

No lowered TTL and no rollback plan. The cutover happens with records still cached for a long period, so a problem discovered ten minutes in cannot be reversed quickly — the correction takes as long to spread as the mistake did. Twenty-four hours of foresight and one written page describing how to go back is the difference between a bad hour and a bad day.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Will my site go down during the move?: It should not, and the method is what prevents it. The new site is built and fully tested while the old one keeps serving traffic, and the switch is a DNS change made in a planned window. What varies between visitors is which copy they reach during propagation, which is why both sites stay live and working until the change has fully settled.
My old agency controls my hosting and domain. Can you still move it?: This is one of the most common reasons people ask, and usually yes. What is needed is registrar access or an authorisation code for the domain, and either hosting access or a recent full backup. If neither can be obtained, a site can often be rebuilt from a crawl and the archive, but that is a different job with a different price and we would say so plainly.
Will my email keep working?: Only if it is treated as its own task, which is how we treat it. Email attached to the old hosting is the single most dangerous part of any move, because a DNS change made for the website will take the mailboxes with it. MX and authentication records are recorded before anything changes and migrated deliberately, on their own schedule.
Will I lose my Google rankings?: A same-platform hosting move should not touch them at all, since the URLs do not change. A platform or domain change does move things, and the protection is a complete crawl of the old site, a redirect for every URL, and Search Console watched afterwards. There is usually a brief unsettled period on a domain change even when everything is done correctly.
How long does DNS propagation actually take?: Most visitors see the change within hours, and the tail can run to a couple of days depending on what TTL was set beforehand. Lowering the TTL a day ahead of the move shortens that tail considerably, which is why it is scheduled as its own step rather than remembered on the day.
What if something goes wrong halfway through?: The old environment stays intact and untouched until the new one has been verified, so reverting is a DNS change rather than a rebuild. The rollback route is written down before the move begins, along with what it costs in time, so the decision is not being improvised under pressure.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Website migration All Web Development & Engineering services