Move Your Domain to a New Web Host

Part of a diagram showing the overview of server migration

Web host migra­tion is like sky­div­ing: you know there’ll be a lot of adren­a­lin, and you hope there won’t be a loud thud at the end.

I’ve migrat­ed a few domains recent­ly for myself and oth­ers. So far, no thuds. Here’s the process I used.

The fol­low­ing assumes (1) you already have a web­site host­ed some­where and (2) you want to move it to a new web host, keep­ing the same domain name. (You’ll prob­a­bly find this guide help­ful even if one of those two assump­tions is wrong.)

The Scenario

So. Let’s say you’re going to move your nonprofit’s web­site:

  • Your orga­ni­za­tion: Peace & Treez
  • Your domain name:
  • Old web host:
  • New web host:


  1. Pick a good web host.
  2. Sign up for an account.
  3. Set up the new web host.
  4. Pre­pare the new host to receive email.
  5. Change your domain to point at the new web host.
  6. Watch for the change to hap­pen.
  7. Do some final test­ing and tweak­ing.
  8. Kick back and bask in your geek­i­ness.

Important Background: Domain Name Servers

Com­put­ers on the Inter­net don’t refer to each oth­er by name. They refer to each oth­er by their Inter­net Pro­to­col (IP) address­es. The most com­mon inter­net address­es look like four num­bers sep­a­rat­ed by peri­ods, some­thing like

When you enter in your browser’s address bar, or when you send an email to, some­how that human-friend­ly domain name has to get con­vert­ed into a com­put­er-friend­ly IP address.

The gad­get that han­dles the con­ver­sion is called a Domain Name Serv­er (DNS). It sits on a com­put­er some­where out in the Inter­net, and it has an enor­mous table of entries say­ing “requests for domain name X should be rout­ed to IP Address Y”. At most recent count there were just over 2.3 gajil­lion domain name servers scat­tered around the Inter­net.

Some DNSs are cool­er (more author­i­ta­tive) for cer­tain things than oth­ers, but let’s not get into that right now. For now all you need to know is that when any­one uses a domain name for any­thing, there’s a DNS some­where that decides which com­put­er that request should get rout­ed to.

So to start with you have one web host, and all of the DNSs in the Inter­net point at it. Your world looks like this:

Your initial setup: you have one web host and all of the world's DNSs are pointing at it.

Your ini­tial set­up: you have one web host and all of the world’s DNSs are point­ing at it.

Pick a Good Web Host

A good host makes all the dif­fer­ence if migra­tion turns ugly.

A good host makes all the dif­fer­ence if migra­tion turns ugly. There’s a good chance you’ll hit some glitch or anoth­er: prob­a­bly minor, and pos­si­bly your fault. Maybe you can fig­ure it out your­self, but a good host might fig­ure it out it faster. And often you’ll need the host’s help to actu­al­ly fix it.

Your best way to find a good web host is to find some­one you know who has sim­i­lar needs and ask whether they’re hap­py with their host. There are also many, many web­sites that review web hosts (search for “web host review”), but treat them with cau­tion: most of them oper­ate on paid adver­tis­ing from the very web hosts they’re review­ing.

Information you need

Your new host,, should have giv­en you the fol­low­ing infor­ma­tion. If not, ask for it:

  • The loca­tion of a web page (often called a “con­trol pan­el” page) where you can man­age things like email accounts, file access, etc.
  • Login infor­ma­tion for the con­trol pan­el
  • Infor­ma­tion on trans­fer­ring files to/from the site using File Trans­fer Pro­to­col (FTP)
  • The address­es of the new host’s DNSs

Limbo: Set Up The New Web Host

Once you’ve cre­at­ed an account with you have two hosts:

  1. Your active host,, which every­one is using for’s email and web­site, and
  2. Your dor­mant host,, which no one knows about but you.

For the next steps you’ll need some way to move infor­ma­tion from your cur­rent host and to your new host. FTP is the most wide­ly avail­able way to do this is through. When you signed up for an account, should have pro­vide you with infor­ma­tion on con­nect­ing to your account via FTP.

If you don’t have this infor­ma­tion for your old or new web hosts, you’ll need to con­tact them to get it.

Some hosts offer oth­er file trans­fer meth­ods. In the worst case you can down­load your cur­rent web­site by using a web copi­er pro­gram, or (ugh) by vis­it­ing every page through your web brows­er and doing a “Save As” to save the page on your local hard dri­ve. But only do this if there’s no oth­er way around it.

1. Back up your site.

Down­load all of your con­tent from your cur­rent web host. You should make a back­up on your local com­put­er plus addi­tion­al copies just in case—to CDs and/or DVDs and/or a sec­ondary hard-dri­ve and/or an online back up ser­vice.

Be sure to get all of the con­tent from your site, for exam­ple:

  1. Web pages;
  2. Log files;
  3. Oth­er files from your site that you’d like to keep;
  4. The con­tents of any data­bas­es; for exam­ple, if you use a blog­ging tool or a Con­tent Man­age­ment Sys­tem (CMS) fol­low the tool’s back­up instruc­tions;
  5. Maybe oth­er stuff: poke around thor­ough­ly in your cur­rent account to see what’s there

2. Upload your site to your new host

Remem­ber every­thing you did in step 1? Now do it back­wards.

Upload the files to your new web host, prob­a­bly using FTP, and set up and restore data­bas­es as need­ed.

If your upload will over­write exist­ing files on the new host, down­load copies of those files and save them some­where safe just in case. You’re prob­a­bly not over­writ­ing any­thing crit­i­cal, but if so you’ll want to be able to revert.

If you’re using a CMS or anoth­er data­base-based appli­ca­tion, you’ll need to either cre­ate login accounts for the data­base, or update your con­fig­u­ra­tion files to use the new logins cre­at­ed by your new host.

3. Test

Prob­lem: nobody knows about your account but you. Not only does that mean the world is still vis­it­ing your cur­rent (awful) web host, but you can’t test your new site sim­ply by vis­it­ing doing that will just take you to the web­site files stored on In oth­er words, your world looks like this:

You have an account with your new web host, but nobody knows it has anything to do with

You have an account with your new web host, but nobody knows it has any­thing to do with

Since you can’t pre­view your site using your usu­al domain name, should have giv­en you an ugly-but-func­tion­al URL you can vis­it to test your web­site on the dor­mant host. For exam­ple, this might look some­thing like You can vis­it this URL to con­firm your web­site looks good before you make the big leap and tell every­one else about it.

Test your entire site, and spend spe­cial time test­ing any­thing tricky: for exam­ple, a part of your site that reads from or writes to a data­base, or that col­lects infor­ma­tion through a web form, or that sends email. You could run a pro­gram that checks whether every link is bro­ken, but you’ll be safer (and prob­a­bly feel bet­ter) if you man­u­al­ly click every link in the site, assum­ing that’s prac­ti­cal.

You might have trou­ble test­ing some sim­ple parts of the site (like hyper­links) or more com­pli­cat­ed parts (like entry forms) if they redi­rect you to your cur­rent domain name: right now any­thing that takes you to will take you to your current/old host, since the Inter­net doesn’t know yet that has any­thing to do with your new host Take this catch into account when you’re test­ing.

4. Leave a Trace

Make some small change to your web­site and upload it to your new host, but not to your old host. That way you’ll be able to tell when your new host becomes the active host: as soon as you browse to your web­site and see the small unique change, you’ll know you’re look­ing at the files on your new host.

Email Springs Eternal: Prepping the New Host

Besides upload­ing your web­site files to your new host, you need to pre­pare it to receive’s email.

Just as with web traf­fic, right now any­one send­ing an email to is send­ing it to your old web host, Again, that’s because all of the world’s Domain Name Servers only know about, and don’t know yet that you’re about to switch to a new host.

1. Create mailboxes

Before telling all the DNSs about your new host you need to cre­ate mail­box­es there for all of your email accounts. All good web hosts will give you a nice admin­is­tra­tive web page where you can add, edit, and delete mail­box­es. The details vary great­ly from host to host, but your new host should have sent you infor­ma­tion about this when you signed up.

2. Test mailboxes

Once your mail­box­es are set up you won’t be able to test them ful­ly: any email you send to your domain name will still go back to the mail­box­es on your old host. But your new host prob­a­bly pro­vides a web-based way for you to check email, so if noth­ing else you can at least log into your mail­box via the web to con­firm it’s set up.

3. Gather connection information

If you plan to down­load your email from the web host to a mail pro­gram like Out­look or Apple Mail you’ll need some infor­ma­tion about access­ing your new mail­box. This is most com­mon­ly done via the Post Office Pro­to­col, which is almost always referred to as “POP” or “POP3”. This infor­ma­tion is nor­mal­ly:

  • Incom­ing (POP) mail serv­er name
  • The port num­ber for email (110 unless spec­i­fied oth­er­wise)
  • User name
  • Pass­word
  • Maybe: whether the serv­er requires encryp­tion
  • Maybe: the type of encryp­tion it uses

Your web host should be able to give you this infor­ma­tion. In fact, if they have an FAQ page you’re almost cer­tain to find help there since these ques­tions are, you know… fre­quent­ly asked.

Once you have the infor­ma­tion it would be an excel­lent idea to test your email pro­gram using the new host, just to be sure every­thing works as you would expect. You should do this by adding a new account in your email pro­gram rather than by replac­ing your cur­rent email account infor­ma­tion, since you aren’t yet ready to switch over to the new host for your email.

After set­ting up the new accounts in your email pro­gram, send your­self an email using the new account/host. The email will be rout­ed to your old host, but that’s ok. If you were able to do this it means (1) your email pro­gram is able to send mail via your new host, and (2) your email pro­gram was able to log in to your new host and check for email, even though none was there yet.

4. Download email

If you’ve been using web­mail direct­ly through your old web host, or if you’ve been using an email pro­gram like Outlook/Apple Mail but leav­ing the email on the web host rather than down­load­ing it to your local com­put­er, you’ll want to down­load some or all of the infor­ma­tion from your cur­rent web­mail account so you can access it lat­er. Con­sid­er not only email but con­tacts, cal­en­dar entries, and oth­er notes that your cur­rent host lets you save in your email account.

Taking the Leap: Changing Your DNS Entry

You’ve cre­at­ed your account with, uploaded and test­ed your web files, and cre­at­ed and test­ed your new mail­box­es, so now it’s time to tell the rest of the world that your web­site lives at instead of

1. Schedule a time

The DNS update process shouldn’t cause sig­nif­i­cant prob­lems with peo­ple reach­ing your site, but to min­i­mize the risk you should pick a time when your web­site traf­fic is low. Maybe you know when this is already, but if not you could review your website’s log files if you have the tools to do that.

You should also take into account when your email traf­fic is high­est. Dur­ing the domain tran­si­tion it’s pos­si­ble you could lose email unless you pro­tect your­self. See the side­bar (“Email Through the Cracks”) for steps you can take to pre­vent that.

You might want to inform peo­ple who vis­it your site or who email you, though if all goes well they shouldn’t see a dis­rup­tion. You’d main­ly be warn­ing them so they’re braced in case all doesn’t go well.

2. Update Your DNS Entry

How do you update the DNS entry for your domain? In the old days you had to call, email, or some­times even ground mail instruc­tions to the orga­ni­za­tion that man­ages your domain—the domain reg­is­trar. Today most DNS changes can be made by the per­son who owns the domain (hope­ful­ly you) by com­plet­ing a sim­ple web form.

In most cas­es you can make these changes whether or not you’re for­mal­ly list­ed as the domain’s Admin­is­tra­tive Con­tact: if you have the login infor­ma­tion for the site, you can make the changes. This can be a sig­nif­i­cant issue for non­prof­its, where turnover in cer­tain roles is some­times high. But even if the per­son who reg­is­tered the domain is no longer with your non­prof­it, any­one else work­ing there who has the login infor­ma­tion can make the change—even a (trust­ed!) vol­un­teer or con­sul­tant.

Maybe you’re an orga­ni­za­tion­al guru, and just after you orig­i­nal­ly reg­is­tered the domain name, you filed away the loca­tion of your registrar’s web page and your login infor­ma­tion. If so, you’re gold­en. Make the change at the time you’ve sched­uled.

  1. Log into your registrar’s web site.
  2. Find a page that lets you edit your DNS entry for the domain.
  3. Find the place on the page that lists the cur­rent DNSs for your domain. You’ll most like­ly find two DNSs, one pri­ma­ry and one sec­ondary.
  4. Replace these old DNS names with the DNS names that your new web host pro­vid­ed.

3. Can’t figure out how to update your DNS entry?

If you don’t have login infor­ma­tion for the site that lets you man­age your domain name, you’ll need to con­tact your domain reg­is­trar for help.

This will almost cer­tain­ly throw a delay into your domain trans­fer process, so allow extra time: cer­tain­ly days, but to be safe a week or two in case you need to resort to old-school meth­ods like ground mail con­fir­ma­tion. If you’re not sure who your reg­is­trar is, see the side­bar “WHOIS My Reg­is­trar?”

4. Wait

As I men­tioned ear­li­er, there are gajil­lions of DNSs sprin­kled around the inter­net. You’ve spec­i­fied which two servers are the coolest (most author­i­ta­tive) for your par­tic­u­lar domain, but all of the oth­er DNSs in the world need to grad­u­al­ly get word of the change. So the change you made above real­ly just kicked off a process of infor­ma­tion prop­a­gat­ing through the Inter­net to all the oth­er DNSs. Prop­a­ga­tion takes a while to com­plete.

It’s rea­son­ably like­ly that you and peo­ple near you will see the new host with­in 3–4 hours, but 12 hours isn’t unheard of, and it might take 72 hours before all the DNSs in the Inter­net are up to date. In the mean time your world will look like this:

Part-way through the update process, not all DNSs will know about your site's new location.

Part-way through the update process, not all DNSs will know about your site’s new loca­tion.

That means for a while some peo­ple will be see­ing your old host and some will be see­ing your new host.

It also means some people’s email will go to your old host, and some to your new host. Which is poten­tial­ly ugly: once the DNS update is com­plete for you, you might not be able to get to your email on your old host any more: vis­it­ing (for exam­ple) will now take you to your new host. See the side­bar for a tip on deal­ing with that ugli­ness.

While you wait for the changes to take effect, don’t make any changes to the site. If you absolute­ly have to, make the changes to both the old and the new site since both sites will be in use by some peo­ple for the next few hours or days.

All Done… Mostly

You’ll know you’re look­ing at the new web host as soon as you can browse to your domain and see the unique new change you made above (“Leave a Trace”). So now your world looks like this:

All DNSs are pointing at your new host. Goodbye old host!

All DNSs are point­ing at your new host. Good­bye old host!

As soon as pos­si­ble, do a good re-test­ing of the site, again pay­ing spe­cial atten­tion to the most tricky or com­pli­cat­ed parts of the site. If your site pro­duces any RSS feeds, check those too. If something’s wrong, well… fix it.

If you have a local email pro­gram like Out­look or Apple Mail, you should update it to start using your new web host. As dis­cussed above, your host should have pro­vid­ed the nec­es­sary set­up infor­ma­tion. If you don’t have it, con­tact your new web host for help, and in the mean time use your new host’s web­mail option. Test your email pro­gram by send­ing a mes­sage to your­self at your domain name.

If you’re using Google Web­mas­ter Tools or anoth­er web ana­lyt­ics pack­age, you might need to re-ver­i­fy that the pack­age rec­og­nizes your site in its new loca­tion. (If you don’t know what I’m talk­ing about, ignore this para­graph.)

Once your new host is live you should leave your account active with the old host for at least a week, and ide­al­ly a month. This is main­ly in case you real­ize you’ve left some­thing behind. Once you can­cel your old host, your files will become inac­ces­si­ble.

And once you’ve can­celled your old host account, con­grat­u­la­tions!

You’re done!

Other Resources

You might find some of these pages help­ful in pro­vid­ing oth­er tips and details.

Registration is required to comment.

You aren't currently logged in. You can use the fields below to post a comment without logging in or registering, or you can log in or register now.

By submitting a comment here you grant Blazing Moon a perpetual license to reproduce your words and name/web site in attribution. Inappropriate comments will be removed at admin's discretion.

Blazing Moon RSS Feed