I decided to perform the migration from scratch because I had spent too much time experimenting in my temporary environment.
While running on Windows, I deleted the data directory and copied back the original data directory from version 0.15.5.
When I log in (version 0.16.7 by http://localhost:8080/admin/login) with incorrect credentials, I receive an authentication error as expected. However, when I use the correct credentials, the login is accepted, but I end up in a redirect loop and am repeatedly returned to the login page.
Since my original data directory comes from a Linux environment, the logging configuration is not in a Windows format. When running the service from a terminal, I see the following message:
2026-06-02T14:49:30Z INFO Authentication successful (auth.success) listenerId=“http-recovery”, localPort=8080, remoteIp=::1, remotePort=55769, accountName=“admin”
Based on this log entry, authentication appears to be successful, but the web interface keeps redirecting me back to the login page.
The redirect loop after a successful login is a well-known issue documented in the FAQ, and the root cause in your case almost certainly comes from one of these:
The most likely culprit: the OAuth callback URL scheme mismatch. The 0.15 data directory (which contains your server’s stored configuration) was originally configured with a defaultHostname and public URL for a Linux environment. When 0.16 authenticates you, the OAuth flow redirects back to the URL derived from that stored configuration - if that URL is https:// (or some other hostname), but you’re actually running on http://localhost:8080, the browser ends up in a redirect loop because the callback never resolves correctly.
Things to check/try:
Use a private/incognito browser window - clear any cached cookies or session state from previous visits.
Access via http://localhost:8080/admin specifically - the docs note this URL is exempt from the hostname/OAuth binding check. If you’re already doing this, try a different browser entirely.
Check the stored defaultHostname / public URL in your 0.15 data. The 0.15 config stored in that data directory likely references the original Linux hostname or an HTTPS URL. The WebUI OAuth flow redirects to that URL after login, which doesn’t exist on your Windows machine. From the docs:
A reverse proxy is terminating HTTPS but talking HTTP upstream and the discovery URLs end up pointing at the wrong scheme or port.
Even without a reverse proxy, if the stored configuration says your server’s public URL is https://mail.example.com, the OAuth callback will try to redirect there instead of back to localhost.
The fix: After getting into the server via the recovery/HTTP port (http://localhost:8080/admin with a private window), navigate to the server settings and update the defaultHostname and public URL to match your current Windows environment.
Also important: a 0.15 data directory is not directly compatible with 0.16 - the upgrade involves breaking changes. The upgrading guide on GitHub (linked from the 0.16 release notes) must be followed for a proper migration.