Plan a migration of a CI fleet and developer laptops from Docker to Podman. An engineer has proposed aliasing docker to podman and calling it done. Where does that break?

1. Acknowledge what the alias does cover: the common CLI surface is compatible, so most interactive commands keep working, which is exactly why the migration feels finished when it is not. 2. Image references: Podman does not assume Docker Hub, so unqualified image names fail in pipelines — fully qualify every image or configure the registry search list explicitly. 3. Test harnesses that expect a daemon socket (testcontainers and similar) need to be pointed at the Podman socket, with the rootless socket path differing from the root one. 4. Lifecycle after reboot: there is no daemon to restart containers, so restart policies alone are insufficient — generate systemd units (quadlet) and let systemd own startup. 5. Compose files need podman-compose or conversion to Kubernetes-style manifests, and behaviour differences in networking and volume defaults will surface here. 6. Rootless implications: port binding below 1024, user namespace id mapping on bind mounts, and file ownership inside volumes all change. 7. Sequence the rollout — CI first behind a flag, then non-critical services, then laptops — with a documented rollback and a compatibility test suite as the gate. 8. Name the payoff so the cost is justified: no single daemon whose failure loses control of every container, and rootless containment reducing the reach of a compromised container.