split migration procedure into one doc per service

doc/migration-format.md

 # IndieHosters migration format
 
-# Version 0.3
+## Deprecated
 
-### General
-
-An IndieHosters migration archive is a directory structure (probably packaged up as a tar file or zip file).
-There should be an 'indiehosters.json' file in the root of the archive. It should contain at least the following fields:
-
- * format: the URL of this spec (probably https://indiehosters.net/spec/0.3)
- * application: a string, which determines what the rest of the folder contents should be imported into.
-
-
-## Known
-
-When migrating a Known application, the 'indiehosters.json' file should furthermore contain the following fields:
-
-  * application: 'known'
-  * version: the version of Known as a string, for instance '0.6.5'
-  * database:
-    * engine: the database engine used, either 'mysql' or 'mongodb'
-    * name: the database name inside the dump file, for instance 'known'
-    * file: the database dump file inside the archive, for instance 'dump.sql'
-  * uploads: the uploads folder name inside the archive, for instance 'uploads/'
-  * plugins: the folder with any non-standard plugins for instance 'plugins/'
-
-
-## WordPress
-
-(to be determined)
+Deprecated by the [web app migration procedure](../proc/webapp.md)
 
 
 ## Version 0.2.2 (deprecated)

doc/migration-procedure.md

 # Migration procedure version 0.3
 
-## Introduction
-
 The IndieHosters network aims to allow users to easily migrate their hosted services from one hosting provider to another.
 To this goal, we describe a number of services which a hosting provider may offer, and a migration procedure for each of these.
 In this document, we will say the "user" migrates "services" from the "old hoster" to the "new hoster".
@@ -24,68 +22,10 @@ If the old hoster offers this product, but the new hoster does not offer email f
 possible. The user will then have to accept that their email forwarding will stop working. Presumably, the user is OK with
 that, since they picked the new hoster themselves. But it's worth mentioning that this is then only a partial migration.
 
-## Basic hosting services
-
-### Domain name registration
-
-How to migrate a domain name from one hosting provider to another depends on the extension, and even for a given extension, there
-are serveral possibilities. In version 0.3 of this migration procedure, we will only consider one basic case, which is quite easy
-to deal with:
-
-* the domain name registration is in an account at a well-known registrar (e.g. NameCheap)
-* this registrar account is under control of the old hoster (not of the user directly)
-* the new hoster also has an account at this same well-known registrar, or is willing to create one
-* the registrar offers a "Transfer to another account" option
-
-The migration process is then as follows:
-
-* user has a service of type "domain name registration" with old hoster. Registrant is well-known and all above points apply
-* old hoster is listed in the IndieHosters migration network as supporting emigrations with type 'domain name registration'
-* new hoster is listed in the IndieHosters migration network as supporting immigrations with
-  * type: 'domain name registration'
-  * registrar: 'NameCheap' (or whichever well-known registrar)
-* user contacts old hoster, stating clearly and unmistakably that they want to migrate to new hoster
-* old hoster contacts new hoster to:
-  * confirm they will accept the migration
-  * agree on compensation for registration fee for months left until the domain is up for renewal at registrar
-  * agree on possible transfer of user's prepaid credit, e.g. if they were paying yearly at old hoster
-  * double check the new hoster's account identifier at the well-known registrar
-* old hoster transfers the domain name registration into the new hoster's account at the well-known registrar
-* old hoster notifies new hoster and user that this has been done, to reconfirm to the user what the next upcoming renewal date
-is for the domain name registration, and if any account credit was transferred
-
-### DNS hosting
-
-The migration of DNS hosting will usually result automatically when transferring a domain name registration and/or other hosted
-services. However, if the user had custom DNS records, then these may be transferred as a text file.
-
-### Email forwarding
-
-The old hoster tells the new hoster what the user's forwarding address is.
-
-### TLS certificate
-
-The old hoster sends the certificate to the new hoster as one or more .pem files, where the .pem file containing the private key is
-encrypted with a passphrase.
-
-The old hoster sends the passphrase over a different and secure medium, in an unrelated message. For instance, if the .pem files were sent via
-scp, the passphrase may be sent via PGP-encrypted email.
-
-### Web application (simplistic procedure)
-
-* The old hoster puts the site in read-only mode by changing the permissions of the database user to read-only
-* The old hoster creates the migration archive as per the [IndieHosters migration format](migration-format.md)
-* The old hoster sends the migration archive to the new hoster
-* The new hoster imports the migration archive
-* Once DNR, DNS, and TLS have also been migrated, the old hoster terminates the service.
-
-### Web application (advanced procedure)
-
-* The TLS certificate is sent ahead first
-* The old hoster programmatically creates the migration archive, and immediately *posts* it to the new hoster via a webhook
-* The webhook programmatically imports the migration archive, and returns the IP address
-* The old hoster programmatically configures the new hoster's public IP address into their load balancer
-* The old hoster's load balancer now forwards (at the TCP level) all traffic to this new IP address
-* Once DNR and DNS transfer are complete, the old hoster terminates the TCP forwarding service.
-
+Migration procedures:
 
+* [Domain name registration](../proc/dnr.md)
+* [DNS hosting](../proc/dns.md)
+* [Email forwarding](../proc/email.md)
+* [TLS certificate](../proc/tls.md)
+* [Web application](../proc/webapp.md)

proc/dnr.md

+# Migration procedure version 0.3
+
+## Domain name registration
+
+How to migrate a domain name from one hosting provider to another depends on the extension, and even for a given extension, there
+are serveral possibilities. In version 0.3 of this migration procedure, we will only consider one basic case, which is quite easy
+to deal with:
+
+* the domain name registration is in an account at a well-known registrar (e.g. NameCheap)
+* this registrar account is under control of the old hoster (not of the user directly)
+* the new hoster also has an account at this same well-known registrar, or is willing to create one
+* the registrar offers a "Transfer to another account" option
+
+The migration process is then as follows:
+
+* user has a service of type "domain name registration" with old hoster. Registrant is well-known and all above points apply
+* old hoster is listed in the IndieHosters migration network as supporting emigrations with type 'domain name registration'
+* new hoster is listed in the IndieHosters migration network as supporting immigrations with
+  * type: 'domain name registration'
+  * registrar: 'NameCheap' (or whichever well-known registrar)
+* user contacts old hoster, stating clearly and unmistakably that they want to migrate to new hoster
+* old hoster contacts new hoster to:
+  * confirm they will accept the migration
+  * agree on compensation for registration fee for months left until the domain is up for renewal at registrar
+  * agree on possible transfer of user's prepaid credit, e.g. if they were paying yearly at old hoster
+  * double check the new hoster's account identifier at the well-known registrar
+* old hoster transfers the domain name registration into the new hoster's account at the well-known registrar
+* old hoster notifies new hoster and user that this has been done, to reconfirm to the user what the next upcoming renewal date
+is for the domain name registration, and if any account credit was transferred

proc/dns.md

+# Migration procedure version 0.3
+
+### DNS hosting
+
+The migration of DNS hosting will usually result automatically when transferring a domain name registration and/or other hosted
+services. However, if the user had custom DNS records, then these may be transferred as a text file.

proc/email.md

+# Migration procedure version 0.3
+
+### Email forwarding
+
+The old hoster tells the new hoster what the user's forwarding address is.

proc/tls.md

+# Migration procedure version 0.3
+
+## TLS certificate
+
+### Without a passphrase
+
+The old hoster sends the certificate to the new hoster over a secure channel, as one or more .pem files.
+
+### With a passphrase
+
+The old hoster sends the certificate to the new hoster as one or more .pem files, where the .pem file containing the private key is
+encrypted with a passphrase.
+
+The old hoster sends the passphrase over a different and secure medium, in an unrelated message. For instance, if the .pem files were sent via
+scp, the passphrase may be sent via PGP-encrypted email.

proc/webapp.md

+# Migration procedure version 0.3
+
+## Web application (simplistic procedure)
+
+* The old hoster puts the site in read-only mode by changing the permissions of the database user to read-only
+* The old hoster creates the migration archive as per the IndieHosters migration format (see below)
+* The old hoster sends the migration archive to the new hoster
+* The new hoster imports the migration archive
+* Once DNR, DNS, and TLS have also been migrated, the old hoster terminates the service.
+
+## Web application (advanced procedure)
+
+* The TLS certificate is sent ahead first
+* The old hoster programmatically creates the migration archive, and immediately *posts* it to the new hoster via a webhook
+* The webhook programmatically imports the migration archive, and returns the IP address
+* The old hoster programmatically configures the new hoster's public IP address into their load balancer
+* The old hoster's load balancer now forwards (at the TCP level) all traffic to this new IP address
+* Once DNR and DNS transfer are complete, the old hoster terminates the TCP forwarding service.
+
+## IndieHosters migration format, version 0.3
+
+### General
+
+An IndieHosters migration archive is a directory structure (probably packaged up as a tar file or zip file).
+There should be an 'indiehosters.json' file in the root of the archive. It should contain at least the following fields:
+
+ * format: the URL of this spec (probably https://indiehosters.net/spec/0.3)
+ * application: a string, which determines what the rest of the folder contents should be imported into.
+
+
+### Known
+
+When migrating a Known application, the 'indiehosters.json' file should furthermore contain the following fields:
+
+  * application: 'known'
+  * version: the version of Known as a string, for instance '0.6.5'
+  * database:
+    * engine: the database engine used, either 'mysql' or 'mongodb'
+    * name: the database name inside the dump file, for instance 'known'
+    * file: the database dump file inside the archive, for instance 'dump.sql'
+  * uploads: the uploads folder name inside the archive, for instance 'uploads/'
+  * plugins: the folder with any non-standard plugins for instance 'plugins/'
+
+
+### WordPress
+
+(to be determined)