A Wiki Migration Is Mostly a Verification Problem
Changing a service name looks like a tiny job: add a hostname, point a proxy at the application, and move on. In practice, a Wiki.js cutover reminded me that the change is mostly a verification problem.
The work began as an internal move. That meant the new name had to resolve where it was intended to resolve, the Nginx proxy had to be able to reach the Wiki.js backend, and the TLS endpoint had to serve the expected application. Only after those checks were clean was public access deliberately enabled.
Test the route from the place that will use it
A healthy backend is necessary but not sufficient. The reverse proxy needs its own successful backend check, because that is the path visitors actually traverse. Likewise, an internal DNS answer says nothing about what a public client will see. Each layer deserves a check in the context where it operates.
Make the access boundary explicit
The initial route was intentionally internal-only. Opening it to the Internet was a separate, explicit change rather than an accidental consequence of adding a hostname. That separation makes review easier: the routing change can be validated first, and the exposure change can be decided and tested on its own terms.
Verify after reload, not just before it
Configuration tests and a clean Nginx reload are useful gates, but they are still only gates. The post-change checks were the important evidence: HTTPS reached the expected site, the old hostname no longer served the Wiki.js route, and the new public endpoint returned successfully.
The small takeaway is simple: treat a service cutover as a chain of independently testable claims. Name resolution, proxy reachability, TLS, access policy, and the rendered application are different things. Checking each one turns a nervous DNS-and-Nginx change into a boring, reversible operation—which is exactly what infrastructure work should be.
