Renaming a live website is more than replacing one label in a control panel. If you change a domain name in Virtualmin without checking DNS, email, databases, and certificates, visitors may see errors even though the files are still on the server. This guide explains how to change a domain name in Virtualmin, what each setting does, and how to test the result before you retire the old address.
The process is usually straightforward when you plan it first. You will review the current virtual server, create a backup, use Virtualmin’s domain-renaming tool, update DNS, check application settings, and keep the old domain available long enough to redirect visitors.
What changing a domain name in Virtualmin actually does
Virtualmin manages websites as virtual servers. A virtual server connects a domain or subdomain to website files, a system user, email addresses, databases, DNS records, and other hosting settings. Renaming that virtual server changes the name Virtualmin uses for those services, but it does not automatically fix every reference inside your website.
Think of the domain as the street address for a building. Virtualmin can update the address on its server records, but signs inside the building—such as WordPress URLs, email signatures, database values, and hard-coded links—may still show the old address.
Before you start, write down:
- The current domain and the new domain.
- The virtual server’s administrator username and home directory.
- The names of databases, database users, and email accounts.
- Whether DNS is managed in Virtualmin or by a separate registrar or DNS provider.
- Whether the site uses HTTPS, a content delivery network, an external email service, or third-party integrations.
Do not delete the old domain before testing the new one. Keeping the old virtual server name available makes it easier to troubleshoot and redirect existing visitors.
Prepare a safe domain rename
A backup is the most important preparation step. Make a copy of the website files and export each database before using the rename function. If your hosting provider offers server snapshots or automated backups, confirm that the latest backup completed successfully and that you know how to restore it.
Put the site into maintenance mode if a busy application could lose data during the change. For a small brochure site, a short maintenance window may be enough. For an online store or membership site, plan the change when orders, payments, and account updates are least likely to occur.
Next, check where DNS is controlled. If the domain uses nameservers supplied by your registrar, DNS changes may be made at the registrar. If the domain uses Virtualmin’s nameserver records, the changes may be made in Virtualmin. The correct location depends on your setup, so inspect the current nameserver delegation before editing records.
Make sure the new domain is registered and that you can manage its DNS. A domain rename on the server cannot make an unregistered domain resolve on the public internet.
How to change domain name in Virtualmin
Virtualmin’s labels can vary slightly by theme or version, but the main workflow is similar. Sign in with an account that can manage the virtual server, then select the domain you want to rename.
- Open the Virtualmin control panel and sign in.
- Select the existing domain from the virtual server list.
- Open Server Configuration.
- Choose Change Domain Name.
- Enter the fully qualified new domain, such as
yournewdomain.com. - Review the options for the administrator username, home directory, username suffix, and group name.
- Confirm the rename only after checking the summary and your backup.
For the new domain, enter the complete hostname rather than only the first part. For example, use yournewdomain.com, not yournewdomain. Avoid adding a protocol such as https:// or a path such as /store.
Virtualmin may offer automatic choices for the administrator username, home directory, user name suffix, and group. Automatic values are often the simplest option for a standard site, but review them carefully if scripts, scheduled tasks, file permissions, or deployment tools depend on the existing account name or path.
If the panel shows a button labeled Rename Now, use it after reviewing the changes. The operation can update the virtual server configuration, but the website itself may still contain the old domain in its settings.
Review users, files, and application settings
After the rename finishes, check the home directory and file ownership. The files should remain in the expected location, and the web server should be able to read them. If you changed the system username or home directory, review scripts, scheduled jobs, deployment keys, and configuration files that refer to the old values.
WordPress sites need special attention. The site address and WordPress address may still use the old domain. You can update them in the WordPress dashboard when the site loads, or use a controlled database or command-line method if the dashboard is unavailable. Always back up the database before changing URL values.
For a WordPress installation with WP-CLI available, a typical URL update may look like this:
wp option update home 'https://yournewdomain.com'
wp option update siteurl 'https://yournewdomain.com'Use the command from the correct WordPress directory and as the appropriate system user. A broad search-and-replace can damage serialized data if it is performed with a basic text replacement tool, so use a WordPress-aware method and test links afterward.
For example, imagine a photography site moving from oldgallery.example to newgallery.example. The files may work immediately after the Virtualmin rename, but image captions, canonical URLs, XML sitemaps, and social sharing metadata could still point to the old address. These are application-level settings, not just server settings.
Update DNS and verify the new domain
DNS tells browsers and mail systems where to find a domain. After the server-side rename, create or update the records needed by the new domain. A common website setup uses an A record for the root domain and a CNAME or A record for www, but the exact values depend on your server and DNS provider.
Check these records carefully:
- Root domain: Confirm that the A or equivalent record points to the correct server address.
- www host: Confirm that
www.yournewdomain.comreaches the intended site. - Mail records: Keep or recreate MX, SPF, DKIM, and DMARC records if the domain sends or receives email.
- Verification records: Recreate records required by analytics, advertising, payment, or other services.
- IPv6: Review any AAAA record so it does not send visitors to an unconfigured server.
DNS changes may not appear everywhere at the same time because resolvers cache records. Test from more than one network, but do not assume a temporary failure means the rename failed. Check the actual DNS response and compare it with the records you intended to publish.
A practical example: a company changes its website domain but leaves the old MX records behind. The website works, yet customer email stops arriving because the new domain has no mail routing. Treat website DNS and email DNS as separate checks.
Configure SSL, redirects, and canonical URLs
HTTPS certificates are issued for specific domain names. A certificate for the old domain does not automatically cover the new one. In Virtualmin, request or renew a certificate for the new domain and its required hostnames, then test both HTTPS and HTTP behavior.
Also check whether the certificate includes both the root domain and the www version. If only one hostname is covered, visitors using the other hostname may receive a certificate warning.
Keep the old domain active when possible and redirect it to the matching page on the new domain. A page-level redirect is better than sending every old URL to the new homepage because it preserves a visitor’s intended destination.
oldsite.example/page-a → https://newsite.example/page-aDo not create a redirect loop. Test the old HTTP address, old HTTPS address, new HTTP address, and new HTTPS address. If a content management system also forces HTTPS, make sure the web server and application agree about the final URL.
Update canonical tags, sitemap URLs, robots.txt references, analytics settings, webmaster tools, social profiles, documentation, and important external listings. Search engines need consistent signals, and visitors should not be sent back to the retired address.
Check email, databases, and scheduled tasks
Email accounts deserve a separate review because a domain rename can affect both incoming and outgoing mail. Confirm that required mailboxes exist under the new domain, then send a test message from an external account and reply to it. Check spam folders as well as the inbox.
If the old domain must continue receiving mail, keep its mailboxes or aliases active for a transition period. Tell users whether they should sign in with the old address, the new address, or both. Also update SMTP settings in websites, mobile apps, contact forms, and business software.
Databases usually keep working when the database name and credentials stay the same, but applications may store the old domain in database rows. Search the application’s documented settings first. Do not change every matching text value blindly, because some values may be data rather than URLs.
Review scheduled tasks and integrations. A cron job may call an old URL, a backup script may use the previous home directory, and a payment provider may reject requests from an unregistered domain. Keep a short checklist of each external service and mark it complete only after a real test.
Common mistakes after a Virtualmin rename
The most common problem is assuming the control panel changed everything. It changes the hosting configuration, but it cannot know every place where an application, email client, external service, or document contains the old domain.
- Changing DNS too early: Publish records only after the new virtual server and website are ready.
- Skipping backups: A rename is not a substitute for a restore plan.
- Forgetting SSL: Test the new hostname over HTTPS before announcing it.
- Removing the old domain immediately: This can break old links, email, and redirects.
- Changing usernames without checking dependencies: Scripts and file permissions may rely on the original account.
- Updating only the homepage: Test contact forms, login pages, images, downloads, and important landing pages.
- Using an unsafe database replacement: Use application-aware tools and keep a database backup.
If the new site shows a default page, inspect the selected virtual server and DNS target. If it shows a permission error, review ownership and permissions. If it redirects repeatedly, inspect both web server rules and application URL settings.
Domain rename checklist and test walkthrough
Use this order for a small website or a staging rehearsal. It separates server changes from public DNS changes, which makes errors easier to identify.
- Record the existing domain, DNS provider, virtual server, home directory, databases, mailboxes, and integrations.
- Create and verify file and database backups.
- Prepare the new domain’s DNS records without removing the old domain.
- Use Virtualmin’s Server Configuration and Change Domain Name screen.
- Keep automatic account and directory choices unless your deployment depends on custom values.
- Check file ownership, application URLs, database connections, and scheduled tasks.
- Issue an SSL certificate for the new domain.
- Test the root domain,
www, HTTP, HTTPS, contact forms, logins, images, and downloads. - Configure page-level redirects from the old domain.
- Monitor access logs, mail delivery, and error logs while users begin using the new address.
For example, after renaming a small business site, open a private browser window and test https://yournewdomain.com/contact. Submit the form, confirm that the message arrives, open an image-heavy page, and log in if the site has an account area. This catches more problems than checking only the homepage.
FAQ about changing a domain in Virtualmin
Can I change a domain name in Virtualmin without moving the files?
Usually, the rename operation changes the virtual server’s domain settings rather than requiring a manual file move. Still, verify the home directory, ownership, application configuration, and links after the operation.
Will changing the domain name change my database?
It may not change the database name or credentials, but your application can store the old domain inside database content or settings. Back up the database and update only the values required by the application.
Do I need a new SSL certificate after the rename?
Yes, you should provide a certificate that covers the new domain. Test both the root and www hostnames, along with any other hostname that visitors will use.
Should I keep the old domain after the change?
Keep it active while you test the new site and set up redirects. It may also be needed for old links, search traffic, customer email, and services that have not yet been updated.
Final steps for a smooth domain change
A successful rename has three parts: the Virtualmin virtual server uses the new domain, public DNS points visitors to the correct server, and the application plus related services recognize the new address. Check all three instead of treating the panel operation as the entire migration.
Your next step is to make a written inventory and complete a backup before opening Virtualmin. Then rename the virtual server, update DNS and SSL, test real user actions, and keep the old domain available for redirects and email during the transition. For related server work, see the Nginx with PHP-FPM guide and the guide to checking PHP information on a site.
