How to migrate webhost
- Reduce TTLs to minimum. If you’re even considering migrating your site(s) from one webhost to another, the very first thing to do is
- Confirm an email independent of domains being migrated. Make sure you have an email address that is independent of any domains you are migrating, so you can use that as your contact info while migrating.
- Pick a new webhost and create an account with them (using that email address).
Previewing your site at the new host
If you'd like to preview your site at the new host, before switching DNS or before your DNS changes have propagated, you can "trick" your computer into thinking that your domain has moved by editing your hosts file.
First you'll need to know the IP address of your new host. You can ask your new DNS servers this if you don't know it some other way:
dig +short a example.com @ns1.dreamhost.com
- Replace example.com with the domain you are moving
- Enter your new host's nameservers in place of ns1.dreamhost.com
You should see the IP address returned on the command line. If you don't get back an answer, then something isn't ready at the new web host.
Then you'll need to edit your hosts file (
/etc/hosts). This will usually have to be done by the root user on your computer. Add a line to your hosts file with the new IP address and the domain name.
Now when you visit your domain it should be pulling from the new host. You may have to close all existing tabs, or restart your browser, in order for your browser to not return the old cached IP address.
If you aren't sure whether you're looking at the new host, you can make some change on the new server and see if it's reflected. For example adding a new file to your server, or changing some text on your home page.
DreamHost moved their community discussion platform from MyBB to Discourse, and migrated their previous user accounts and forum content as well. They migrated some URLs from the old platform to the new platform, but apparently did not migrate the section under "old forums".
- archive.org snapshot of old forum: http://web.archive.org/web/20150906074546/https://discussion.dreamhost.com/forum-5.html
- redirected to https://discussion.dreamhost.com/c/customer-discussion
- archive.org snapshot of a thread: https://discussion.dreamhost.com/thread-146508.html
Welcome! (or welcome back?) You may have noticed that things look a little different around here! DreamHost has recently migrated our forums to a new software platform.
If you had an account on the old system we’ve copied that over for you, however you will need to reset your password before you’re able to login. You’ll only need to do this once! Click on the "Log In" button above and the link to "I forgot my password".
Ideally people will create their IndieWeb sites and their data will live at the same URL forever and ever into eternity.
In reality, sometimes people do change domain names (e.g. because of problems with previously trendy short-domains like .io or .ly) as well as publishing platforms from time to time. We should do our best best we can do is have a plan to handle this gracefully.
The first case is where the source site notifies the target site that it has moved from:
to it's new home at:
seems like there could be 2 approaches to this... sites crawl their own comments detecting the health of domains, or sites send notifications to others sites to "update me"
Many apps will use the IndieAuth URL as a unique identifier for your account. If you change your domain, this will appear as a new user to these apps. We need some way to tell the app that the user has changed their URL, and to be able to prove the user still controls both, so that the app can update the unique identifier.
URL Structure Changes
The next case is where a user adopts a new publishing platform that has drastically different URL structure such as
move to new URL structure
The next case is where a user adds an SSL certificate to their domain. This can now be seen as a different URL.
It seems that the right solution should be able to handle both migration cases. Some rough ideas outlined thus far inlcude:
- Using 301 Redirects
- Onus on the source to notify targets to recrawl / verify their posts
- Targets can run a refresh on their own content to update / verify