diff --git a/cloudron-server-migration.md b/cloudron-server-migration.md
index d420f3c..5af205b 100644
--- a/cloudron-server-migration.md
+++ b/cloudron-server-migration.md
@@ -86,7 +86,13 @@ needed to restore are inside the thing being restored.
       `sudo cloudron-support --troubleshoot`. The version needs no guessing: a fresh install pulls the
       current release, which is 10.1.5 or newer, and anything ≥ 10.1.5 restores this backup.
       **Ports on the new box: 25 inbound CONFIRMED OPEN** (operator, via the Infomaniak portal, 2026-11-01 — this is the receive path, and it is the half that cannot be replaced by a relay).
-      Still to confirm: 465, 587, 993, 995, 4190. Outbound 25 is **not needed**: RFC-wise, a smarthost relay carries our sending, and Scaleway Transactional Email is being set up for exactly that. Do not spend a support ticket on outbound 25.
+      Opened by the operator on 2026-11-01 (4190 is not offered by the provider — ManageSieve, not needed; leave it).
+      **Do not read a timeout from the agent host as "blocked".** Checked 2026-11-01 on both address families:
+      465/587/993/995 all time out while 80/443 answer in ~2 ms, and the same probe reaches the OLD box on those
+      ports instantly. But the new box has no mail app yet (the wizard is unsubmitted), so nothing is listening,
+      and Cloudron's own firewall drops rather than refuses by default — a permitted-but-empty port and a blocked
+      port are indistinguishable from outside. The 2026-10-30 IPv6 observation is the better evidence: those ports
+      were REFUSED there, which means the packet arrived, i.e. permitted. Verify for real once the mail app exists. Outbound 25 is **not needed**: RFC-wise, a smarthost relay carries our sending, and Scaleway Transactional Email is being set up for exactly that. Do not spend a support ticket on outbound 25.
       (Previous note, kept for the date: "Ports still to open on the new box (checked 2026-10-30): 25, 465, 587, 993, 995, 4190.")
 
       **Provider tier — confirmed 2026-11-01: Infomaniak VPS Cloud** (not Lite; the two differ
@@ -206,7 +212,7 @@ Status as of 2026-10-30:
       whole; the master password is what makes the restored contents readable. Note the shape of this:
       `vault.inference.coop` runs `com.github.bitwardenrs` — **Vaultwarden**, the open-source Bitwarden
       server — so official Bitwarden clients already work against it. There is nothing to sync.
-- [ ] **S3 `secretAccessKey`** — **confirm it is in the KeePass vault.** This is the one credential
+- [x] **S3 `secretAccessKey`** — **confirmed 2026-11-01: held externally by the operator along with the rest of the Infomaniak backup keys.** (A restore is unreadable without it, which is why it was flagged.) This is the one credential
       absent from the co-op's own off-box JSON (that carries `accessKeyId` only), and a restore begins
       by pointing the new Cloudron at the backup target — so it must be typeable before the window.
 - [ ] **Vault export** (optional insurance) — the contents already ride in the Cloudron backup, so this
@@ -307,7 +313,7 @@ by pre-cutover DNS plus port 25 — the point is that no *unexplained* failure a
   permanent data loss if they do not. Confirm against Cloudron's docs or the
   dashboard's backup contents before the freeze. This is now the most consequential
   open question in this runbook.
-- Whether the Vault export (§3 blocker) has actually been done.
+- ~~Whether the Vault export (§3 blocker) has actually been done.~~ **Closed 2026-11-01:** the operator confirms access to all relevant passwords outside the server. The full Vault export remains optional — the vault's own database is inside the Cloudron backup, so a restore returns it.
 - The Cloudron host's OS version, disk and RAM (not visible over the API).
 - Whether any provider API key is bound to our current IP.
 - Whether the subscription permits a server move.