expand on service portability

architecture.md

@@ -206,7 +206,15 @@ To reach our goals, we aim to implement the following interactions between [acto
 
 ![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/interactions.svg)
 
-### Entity relationships
+### Service portability
+
+The process of migrating one's applications to a different host encompasses:
+
+1. domain registration: using dynamic DNS
+1. deployed applications: using the reproducible configuration module
+1. application data:
+    - back-up/restore scripts [using SelfHostBlocks](https://shb.skarabox.com/contracts.html)
+    - application-specific migration scripts, to e.g. reconfigure of connections/URLs
 
 Relationships among the entities used to model migrations are as follows, using the crow's foot notation to denote cardinality:
 
@@ -220,7 +228,6 @@ Whereas the core abstraction in Fediversity is a NixOS configuration module, a m
 
 ![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/host-architecture.png)
 
-
 ### Sample configuration schema
 
 Whereas Nix(OS) option modules use Nix to specify types, in order to communicate the expected schema to other tools such as web applications, we use [JSON Schema](https://json-schema.org/) as an intermediate format, building upon [earlier work converting between such schemas by Nix collective Clan](https://clan.lol/blog/json-schema-converter/).