diff --git a/nextcloud/readme.md b/nextcloud/readme.md
index 6896651..e13e1dd 100644
--- a/nextcloud/readme.md
+++ b/nextcloud/readme.md
@@ -450,6 +450,29 @@ rsync -aP --rsync-path='sudo rsync' monoco:/var/lib/nextcloud/ ~/nextcloud-copy/
 rsync -aP ~/nextcloud-copy/ emily:~/podman-data/nextcloud/
 ```
 
+### If you ran the playbook before copying
+
+Running this play against an empty `~/podman-data/nextcloud` does not fail — it
+creates the webroot, writes the environment file, starts the image, and the
+entrypoint initialises a **fresh, uninstalled** instance there: the image's own
+code rsynced in, `data/.ocdata` created, and no `config.php`, because there is no
+`NEXTCLOUD_ADMIN_USER` to install with.
+
+That is not a usable instance, and worse, copying monoco's tree on top of it
+**merges two versions of the code** — the drift this page spends the rest of its
+time warning about, produced silently by a play that reported success. The role
+now warns when it finds a webroot with no `config/config.php`, but the recovery is
+to start from a clean webroot:
+
+```bash
+ssh emily 'systemctl --user stop nextcloud.service
+           rm -rf ~/podman-data/nextcloud'
+```
+
+`rm -rf` needs no `podman unshare`: the role creates the webroot as the connection
+user, and under `keep-id:uid=33` everything the container writes lands on that same
+user. Then take the copy in step 3 and come back to step 4.
+
 ### 4. Deploy
 
 ```bash
diff --git a/nextcloud/roles/nextcloud/tasks/main.yaml b/nextcloud/roles/nextcloud/tasks/main.yaml
index 14cc50c..cbf788c 100644
--- a/nextcloud/roles/nextcloud/tasks/main.yaml
+++ b/nextcloud/roles/nextcloud/tasks/main.yaml
@@ -13,6 +13,36 @@
     group: "{{ podman_user }}"
     mode: '0755'
 
+# A migration target should already hold config/config.php, because the webroot is
+# copied from monoco before this play runs (readme.md, "Migrating the data from
+# monoco"). Two situations leave it missing, and both are worth saying out loud
+# before the container starts rather than discovering afterwards:
+#
+#   - the copy never landed, so the image initialises a fresh instance and the
+#     site comes up empty;
+#   - this play was run *before* the copy, so the image's own rsynced code is now
+#     in the webroot. Copying monoco's tree on top of that merges two versions of
+#     the code — the drift the rest of this role warns about — and the play
+#     reports success either way.
+#
+# It warns rather than fails because installing a new instance through the web UI
+# is a legitimate use, and that instance has no config.php until the installer
+# finishes.
+- name: Check whether the webroot already holds an instance
+  ansible.builtin.stat:
+    path: "{{ host_directory }}/config/config.php"
+  register: nextcloud_config
+
+- name: Warn if the webroot has no config.php
+  ansible.builtin.debug:
+    msg: >-
+      {{ host_directory }}/config/config.php does not exist, so this webroot is
+      not a restored Nextcloud instance. Migrating? Stop the unit, delete
+      {{ host_directory }}, copy /var/lib/nextcloud from monoco first, and run
+      this play again — see readme.md, "If you ran the playbook before copying".
+      Installing a new instance through the web UI? Ignore this.
+  when: not nextcloud_config.stat.exists
+
 # The entrypoint takes an flock on this path using a root-owned shell redirect
 # (`) 9> /var/www/html/nextcloud-init-sync.lock`, in the nextcloud/docker
 # entrypoint). Creating it here means it belongs to {{ podman_user }} and stays