Moving to new hardware, and why Windows to Linux is a rebuild

[Progressiverobot]

Moving to new hardware is a restore onto fresh metal. Chapter 15 is the prerequisite, and the first time, rehearse onto a test machine.

The plan (§33.2)

1. Check the new machine against the chapter 3 checklist. Size the disk for the mail store you have now, not the one you had at installation.
2. Install the same version, in the same path. The database records absolute paths to message files, so a different version or directory is where these go wrong.
3. Back up the old server. The built-in backup does not include messages unless you tick the option. For a large store, stop the service, copy Data\, dump the database natively, and take hMailServer.INI, Events\ and your DKIM keys.
4. Stop the old service for good and set it to Disabled. Anything it accepts after the backup is stranded.
5. Restore the data directory, the database and hMailServer.INI, in chapter 15's order.
6. Re-enter the protected secrets.
7. Keep the host name if you can. Update the A record with a lowered TTL, get a PTR on the new IP, re-run the firewall rules, repoint your port forwards, and run Utilities, Diagnostics last.

Leave the old machine powered off but intact for a week or two. It is the rollback.

Budget for step 6. With ProtectStoredSecretsWithDPAPI=1, the default, stored passwords are encrypted with machine-scoped Windows DPAPI and cannot be decrypted on the new machine. Re-enter the database connection password with Bin\DBSetup.exe, then route, smart-host relayer and external-account passwords in the Control Panel. Forget this and you get a server that cannot reach its own database. Linux to Linux is easier: secrets sit under <DataFolder>/.hmailserver-secret-key, so copy that file too, preserving mode 0600 and its ownership.

Windows to Linux is not a migration

It is not supported and the project does not claim it is. The schema is the same on both, 6.3.3 needs 6040 either way, and the message store's on-disk format is the same. What is missing is a tested path: nobody has run a Windows installation onto Linux and verified the result (§35.14).

What is known to break:

• SQL Server. An INI with Type=MSSQL or Type=MSSQLCE is refused by name. Move to PostgreSQL or MySQL on Windows first.
• Every DPAPI secret. Route, fetch-account and per-domain relay passwords, private-key passphrases and the administrator's TOTP secret. Each is reported once as HM6414 and answers empty.
• Event scripts and COM integrations. Neither exists on Linux.
• DKIM key paths. The per-domain key-file setting holds a Windows path such as C:\keys\mail.pem, which resolves to nothing on Linux. Copy the keys and re-point every signing domain.
• Directory case. The Linux build lower-cases directory names derived from an address; Windows leaves them as found. A store carrying Test.com is one this server looks for under test.com, and everything under it must end up owned by hmailserver.

So treat it as a rebuild and a cutover. A new installation on Linux, accounts and mail brought over at mailbox level by mirroring folders over IMAP from the running Windows server. The Import Tool is not an option here: it is a Windows .NET program that drives the COM API, and Linux has neither (§33.8), verified against a still-running Windows server, DNS moved last.