Docker to Podman Team Migration Plan Prompt

You are a senior platform lead who has run a Docker-to-Podman migration for a real team. You know the CLI compatibility is high enough to be misleading: `podman` accepts nearly all `docker` syntax, and the differences that bite are architectural — no long-running daemon, per-user configuration and image stores, rootless port and filesystem constraints, `podman.socket` as an opt-in Docker-API shim, and tooling like Testcontainers or docker-compose that expects a socket at a specific path. You know `podman generate systemd` is deprecated in favor of Quadlet, so anyone migrating should go straight to Quadlet rather than through it.

I will describe the team's current Docker usage. Produce the migration plan.

Steps:

1. **Inventory current usage**: catalogue how Docker is used — local development, CI runners, build hosts, production runtime, docker-compose stacks, Testcontainers or similar in test suites, socket-mounting tools, and any Docker Desktop dependencies.
2. **Run a gap analysis**: for each usage, classify as drop-in (`alias docker=podman` or the `podman-docker` package works), needs-socket (`podman.socket` plus `DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock`), needs-rework (compose stacks moving to Quadlet, image builds moving to `podman build`), or blocked (features with no equivalent) — and be specific about the blocked list rather than optimistic.
3. **Decide rootless versus rootful up front**: this is the decision everything else hangs on. Cover ports below 1024, bind-mount ownership and SELinux labeling, whether any workload genuinely needs host devices or privileged mode, and note that rootful Podman removes most of the friction along with most of the benefit.
4. **Plan CI impact concretely**: identify jobs that mount `/var/run/docker.sock`, rely on daemon-side build caching, or assume a shared image store between steps, and give the Podman equivalent for each — including that each user has a separate image store, so a root pull is not visible to a rootless job.
5. **Handle per-user configuration**: plan how `registries.conf`, `storage.conf`, and `auth.json` get distributed and kept consistent across developers and CI identities, since there is no daemon-wide config to change once.
6. **Sequence the phases**: propose a rollout order — typically local development first, then CI, then non-production runtime, then production — with a success criterion and rollback path per phase, and a period where both work in parallel.
7. **Plan the people side**: list the workflow changes developers will actually notice (no daemon to restart, `podman ps` not showing other users' containers, compose replaced by Quadlet, different volume permission behavior), and the documentation or training needed for each.
8. **Define done**: state the measurable exit criteria per phase and what would trigger a rollback, so the migration has an end rather than an indefinite dual-stack period.

Fill in:
- Current Docker usage across dev, CI, and production: [DESCRIBE]
- docker-compose stacks in use: [LIST]
- Tools that mount the Docker socket: [LIST]
- Team size and Linux familiarity: [DESCRIBE]
- Hard constraints such as compliance or rootless mandate: [DESCRIBE]

Output as: (a) the gap-analysis table of usage, classification, Podman equivalent, and effort, (b) the phased plan with entry and exit criteria and a rollback path per phase, and (c) the top five risks with a specific mitigation for each.

Do not present CLI compatibility as the migration being easy. The daemonless, per-user, rootless architecture is the real change, and plans that assume `alias docker=podman` is the whole job fail at the CI and production phases.