diff --git a/cloudron-server-migration.md b/cloudron-server-migration.md
index 75edaf4..7ac0111 100644
--- a/cloudron-server-migration.md
+++ b/cloudron-server-migration.md
@@ -55,10 +55,23 @@ needed to restore are inside the thing being restored.
       key; if not, retrieve it from the Infomaniak console.
 - [x] New host capacity: **4 CPU, 12 GB RAM, 250 GB disk** (given 2026-10-30) — ample for
       ~6 GB of app data plus images. Old box used ~17 GB of 58 GB.
-- [ ] OS: the new box is **Ubuntu 26.04 LTS**. Confirm Cloudron 9.x supports 26.04 *before*
-      installing — an unsupported release can be refused by the installer. Install version
-      must be ≥ the old box's (9.0.4).
-- [ ] Confirm the Cloudron subscription can be moved to a new server.
+- [x] OS: **Ubuntu 26.04 LTS is supported** — Cloudron's install docs specify a fresh
+      Ubuntu 26.04 x64 server. Minimums are 2 GB RAM / 20 GB disk; the new box has
+      12 GB / 250 GB. Resolved 2026-10-30.
+- [ ] **Version floor: install Cloudron ≥ 10.1.5**, the platform version this box runs
+      (`/api/v1/cloudron/status` → `10.1.5`; backup manifests read `box_v10.1.5`). The
+      earlier note of "9.0.4" was the *CLI* version, not the platform — a restore cannot go
+      backwards.
+- [ ] **Install now, stop before the wizard.** `cloudron-setup --domain my.inference.coop`
+      installs Docker, the platform and the CLI, and needs no DNS of its own — certificate
+      issuance will simply fail and retry until DNS moves (harmless, but it does mean ACME
+      attempts against a hostname still pointing at Hostinger; watch Let's Encrypt rate
+      limits). **Leave the browser setup wizard for cutover day**: that is where the
+      restore-from-backup and the subscription/plan are chosen, and completing it early
+      risks moving the subscription off the live server. Verify that risk before touching
+      the wizard — it is the one step worth reading twice.
+- [ ] Confirm the Cloudron subscription can be moved to a new server (do it at cutover,
+      not early).
 - [ ] **IPv6: DECIDED — repoint.** The new box has `2001:1600:18:206::89`, so all 18
       AAAA records move with the A records (§3 originally left this open). The zone carries
       **AAAA records on 18 hostnames** — everything that has an A record — all pointing to
@@ -68,10 +81,15 @@ needed to restore are inside the thing being restored.
       the A records leaves every IPv6-capable client — including other Matrix
       homeservers and mail senders — still reaching the old box.
 - [ ] Set **rDNS/PTR → `my.inference.coop` on BOTH `179.237.86.116` and
-      `2001:1600:18:206::89`**. The console lists reverse DNS as unconfigured for both.
+      `2001:1600:18:206::89`**. Cloudron cannot do this — PTR belongs to the IP owner and
+      exists only in the Infomaniak console. The console lists reverse DNS as unconfigured for both.
       Not time-sensitive — do it now. If IPv6 sending causes trouble later, disable v6
       egress for SMTP rather than removing the AAAA.
-- [ ] Open on the new box: **22, 80, 443, 465, 587, 993, and 25 inbound** (mail delivery
+- [ ] **Open these in the INFOMANIAK console, not on the host** (measured 2026-10-30: 22
+      answers, 80/443 are silently dropped — a provider firewall default). Cloudron manages
+      the host's own iptables but explicitly does not touch the provider firewall: its docs
+      say "ensure the firewall does not block port 80 (HTTP) and 443 (HTTPS)". Ports:
+      **22, 80, 443, 465, 587, 993, and 25 inbound** (mail delivery
       — test from outside, e.g. `telnet my.inference.coop 25` once DNS moves; note that
       many networks block *outbound* 25, so a closed result from inside another server is
       not conclusive). **8448 is intentionally closed** — federation is delegated to
@@ -92,6 +110,8 @@ needed to restore are inside the thing being restored.
       **RESOLVED 2026-10-30:** the host mount is Nextcloud's `/var/lib/nextcloud`, **3 MB**,
       holding only `preview/` (regenerable thumbnails) — not a data-loss risk. Re-run this
       audit only if apps change before the cutover; it is now a confirm, not an unknown.
+- [ ] Leave the **single snapshot slot free** for a post-restore, pre-DNS-switch snapshot —
+      a bad restore then becomes a revert instead of a rebuild.
 - [ ] Record the highest backup run number before the freeze. (As of 2026-10-30 the
       newest run is healthy at ~4.6 GB and the backup space was enlarged, so the quota
       pressure that produced the `EntityTooLarge` failures is relieved — but run growth