From Wix to Hetzner: A Complete Website Migration Case Study

bywiawithheart.com is a small Austrian brand with a clear promise: handmade bags and accessories, one piece at a time. The website had grown with the business, but it lived inside a closed website builder. That worked while the brand was small. It became a liability when the site needed to become a real business asset: own the domain, own the content, own the mailboxes, own the measurement, and know exactly who can change what.

This is the story of moving the brand from Wix to a self-managed Hetzner stack — not as a lift-and-shift, but as a controlled migration across six layers: domain, DNS, website, email, analytics and secrets.

In this article · 8 min read

1. The brief
2. The target architecture
3. Domain, DNS and email
4. Rebuilding the website
5. Analytics without surveillance
6. Secrets and access
7. Operations and go-live
8. What we learned

Key takeaways

The brief

The starting point was a working Wix site with a clear identity and a practical problem: the brand wanted a website it could evolve on its own terms, with professional email on its own domain and a measurement layer that respects visitors. “Move it to Hetzner” was the short version. The long version had five requirements:

Those requirements shaped the architecture before a single page was rebuilt.

The target architecture

We did not replace one monolith with another. The new platform separates concerns so each layer can be changed, observed and recovered independently:

Domain, DNS and email

The domain was the first dependency to remove. We transferred the registration to Hetzner and moved the authoritative DNS zone into the same account as the server and the mail system. That does not make the setup less redundant — it makes the responsibility explicit: one owner, one place to audit records.

Before changing the public records we prepared the complete target zone: an A record for the apex and www, the MX record for the Hetzner mail server, SPF, DKIM and DMARC. The sequence mattered. TLS, mail and the website each depend on a different record being correct; changing them one by one without a checklist is how migrations produce “it works on my laptop” incidents.

We verified the mail path in both directions: SMTP submission and IMAP retrieval, internal delivery, DNS records and message authentication. A mailbox that can receive but cannot send (or lands in spam) is not a finished mailbox.

Rebuilding the website

The new website is a WordPress installation, but the design is deliberately not a generic theme demo. The visual system keeps the brand’s warmth: generous whitespace, a calm palette, large product imagery and a clear path from “what is this?” to “show me the portfolio” to “contact”.

Content and media were migrated into the new installation, the WordPress address was set to the production domain, and internal links were checked after the search-and-replace. The staging hostname remained available during validation and was retired from the public path after acceptance.

Analytics without surveillance

We replaced the old tracking with a self-hosted Umami instance on the same server. Umami records page views, referrers, devices and countries without cookies or cross-site profiles. For a small brand with Austrian and EU visitors, that is a much better fit than an advertising-driven analytics product.

Secrets and access

A migration creates a new inventory of credentials: server access, database users, WordPress administrators, mailbox passwords, analytics accounts, DNS access. If those live in a note, a chat or a theme file, the migration has moved the website but not the risk.

We use Infisical as the central secret store, with separate environments and a mirrored project for the client’s instance. Vaultwarden holds the human-facing credentials the team uses day to day. The repository contains documentation and secret names, never secret values. DNS and mail records are documented next to the infrastructure, so the next person can verify a claim instead of guessing.

Operations and go-live

Go-live was a checklist, not a moment. Before the public cutover we verified:

• the production hostname resolves to the server and the server returns the expected site;
• the certificate chain is valid for the apex, www and the service subdomains;
• www redirects to the canonical hostname without a redirect loop;
• MX, SPF, DKIM and DMARC are present and the mailboxes can send and receive;
• the analytics tracker is loaded from the production domain and records a test visit;
• DNS and HTTPS are monitored while the resolver caches settle;
• the client can log in and the team can recover access.

We kept a rolling check on DNS and HTTPS during the cutover window and retired the transitional monitoring once the new state was stable. The important part is not the dashboard; it is knowing which signals would make us roll back.

What we learned

1. The migration order is the product. Domain, DNS, TLS, website and mail are coupled. A checklist with a named owner beats heroics on cutover night.

2. “No downtime” is not a design goal; recoverability is. Resolver caches and TTLs are part of the change. We plan for propagation, verify from multiple resolvers and keep a rollback path.

3. Privacy can be an architecture decision. Cookieless analytics is not a feature bolted on at the end. It changes what data exists, which tools are allowed and what the client has to disclose.

4. Access is part of the deliverable. A site is not handed over until the client can log in, recover the account and understand which secret belongs to which service.

The result is a website that is faster to operate, easier to explain and fully owned by the brand. The Wix subscription can end when the client is ready; the new platform does not depend on it.

More engineering notes from our team: GitLab CE vs. Premium for a self-managed team, how we built capacity planning on GitLab CE, and the PM-Suite management cockpit.