We pull a single snapshot of your current control panel: domains, mailboxes, databases, users, DNS zones. Read-only - nothing changes on your side.

All settings (domains, databases, mail accounts, DNS, crons, etc.) are carried over. We keep as much the same as possible: often even mail passwords don't change.

Before you change DNS, we test whether the site or application works on Core (for the technically minded: that it returns an 'HTTP 200'). All good? Then DNS flips. Immediately after, we create a Let's Encrypt certificate (if applicable).

Assign a project owner for decisions and planning, a technical lead for the checks, and a point of contact for communication. Smaller team? One person takes on multiple roles - as long as it's clear who does what.

Everything migrated? Don't cancel the old environment right away. If something does come up later, we still have access to the old configuration and data.

Resist the urge to combine a migration with major application updates. Both are complex enough on their own. Exception: database versions like MariaDB sometimes need to move to a more recent version as part of the migration, but those differences are usually small. Everything else can wait.

Migrate outside peak hours, test thoroughly before any DNS change, and plan carefully with everyone involved. When it goes well, people only notice that things got faster.

Start communicating well before the technical work begins. Two to three updates is usually the right balance - enough to keep people informed, not so many that they stop reading.

Faster load times, stronger security, features that weren't there before - that's the story. Tell your clients. A migration presented as an investment, rather than a hassle, is also a logical moment to revisit your terms and pricing.

Want to let your customers understand the advantages? Share our hosted-by page →