migration

 migration  in the context of the indieweb refers to the process of moving your indieweb site from any one or more of one CMS / web host / DNS provider / URL design / domain name to another.

Related specific aspects of migration
 * account migration
 * post migration

How to migrate webhost

 * 1) 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
 * 2) * Make a list of the domains you’re considering moving
 * 3) * Login to your domain name provider and reduce the TTL to the lowest value allowed
 * 4) ** See: TTL for more details on reducing TTL.
 * 5) 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.
 * 6) Pick a new webhost and create an account with them (using that email address).
 * 7) Export your data. At your old webhost, find the export feature to download your data to your computer. This is also a good backup to have if anything goes wrong. WordPress, Micro.blog, Tumblr, and other blog platforms all have an export feature. Make sure to keep your old web site up during the migration because some import tools may need to access it, for example for downloading images that aren't included in the export.
 * 8) Import your data to the new webhost after creating your account or creating the new blog.
 * 9) Update your DNS settings so that your domain name is now pointed to the new webhost.

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. 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.

75.119.207.166 example.com

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.

Tantek
During IndieWebCamp Austin 2019, I migrated my site from my former hosting provider (who had decided to exit the business with a 30-day notice!) to DreamHost, and was able to do so successfully during the course of the camp with some help from others there, and as a result, also got LetsEncrypt-based HTTPS setup on his sites.

Manton
migrated his personal blog manton.org and some other blogs from WordPress to Micro.blog hosting, using Micro.blog's import feature for WordPress. For his podcast, Manton blogged about writing a script to help migrate MP3 files.

DreamHost Community
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
 * redirected to https://discussion.dreamhost.com/t/installing-a-web-app/62865



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".

Brainstorming
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.

Domain Changes
The first case is where the source site notifies the target site that it has moved from:

old-source.com/note/213

to it's new home at:

new-source.com/note213

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"

IndieAuth
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

same-source.com/note/345

move to new URL structure

same-source.com/note/2014/03/f5e82

SSL Change
The next case is where a user adds an SSL certificate to their domain. This can now be seen as a different URL.

http://domain.com/

is now

https://domain.com/

Solutions
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