Yes, Virtualmin → Server Configuration → Transfer Virtual Server makes it possible to transfer domains / Virtual servers between Virtualmin systems. Using this is easier than migrating a domain / virtual server manually.
It is this question of yours that I am unable to understand. Are you certain that your old invoice server is Webmin and not Virtualmin?
Is it very complicated to convert Webmin to Virtualmin?
Does there install script install all required software automatically or would you need to install every software such as webserver, database etc manually?
The short answer is yes. It is very, very complicated to convert Webmin to Virtualmin.
The Virtualmin install script is supposed to be used only on a fresh server with just the OS installed. I cannot overemphasize this point. If you make the mistake of running the Virtualmin install script on an existing Webmin system then all the configuration and apps installed on the Webmin system may stop working normally. You should therefore not do this on your system, @LionKing .
Please understand that Webmin and Virtualmin are two entirely different things.
Webmin is a web based server management system.
Virtualmin is a web based shared hosting management system.
See shared hosting:
Virtualmin runs on top of Webmin so you are not entirely incorrect in that a Virtualmin system has more features than a Webmin system. However, most of us who use Virtualmin install it on a fresh server with just the OS installed.
I will put it to you like this: I get a fresh server with just the OS installed on it and then I run the Virtualmin automated install script. This installs Webmin + Virtualmin.
My idea was to install Virtualmin on the existing server which only runs webmin and then install a fresh copy on the new Virtualmin to then migrate over the old server in its current web app to it.
That’s more complicated than it needs to be, almost certainly. There are at least two ways to do this, one is very generic and will work no matter what (and Webmin is irrelevant in the generic solution). One would only be easy if your system already kinda looks like the way Virtualmin sets up a hosting system. I’ll cover the latter at the end, as it’s maybe wishful thinking…there are a lot of ways to setup a hosting system, the odds you set yours up to look like our way of thinking seem pretty slim (though we’ve always tried to adhere to current best practices, there’s disagreement about what makes a practice best).
Here’s how I’d do that:
Forget about Webmin on the old server. Webmin doesn’t provide anything useful here, and installing Virtualmin on a production system is…tricky, to put it mildly, and potentially even risky (though not overly so). You’re going to have to hit the command line.
Install Virtualmin on your new system with a freshly installed supported OS. Choose a new-ish OS. Don’t install CentOS 7 or something else stupidly old.
Now…create a new domain in Virtualmin on the new server (same name as your old website). This is the new home for your old website.
Copy all the data from the web root on the old server over to the new server into /home/domainname/public_html.
Dump the database(s) on the old server. You can use Webmin for this, if you’re not comfortable with the MySQL command line client. You just need to export the data in a format that can be imported into the new system. If you’ve got a recent MySQL version on your old server, you’ll need to back up a few steps and switch the new server to MySQL because there are likely incompatibilities. But, of the old server is old, and with an old version of MySQL, a dump from that will import into Mariadb on the new server just fine. Copy the databases over and import them into databases owned by the new domain you created in Virtualmin (you can create as many as you need, if you have more than one).
Update the password in the app config file(s) to the new database password (or reset the Mariadb password for the new domain user to the one you’ve been using, but I prefer to change passwords every time I migrate).
Test your app and whatever other website stuff you brought over to the new server, by adding the new IP to your local hosts file so you can browse the new site and poke around. It probably needs some tweaks to stuff like .htaccess files, paths in your application config, etc. Mail sending and receiving from the app probably won’t work yet.
Once the app is working, make notes of any changes you made, since you may need to do an rsync of data or files once all the rest of the migration is done, and that would undo your changes that made the app work.
Now move on to…other stuff. If you’ve got mail, you’ll need to bring it over. How you do that depends on a lot of factors. Mail is the most widely varying element of hosting on a Linux system and nobody does it the same way. You may need to convert from mbox to Maildir (Virtualmin’s preferred format, though we also support mbox, if you must). We even have code to do that translation, but I can’t for the life of me remember how to go about it. You’ll have to dig into the forums (they go all the way back to 2005 when mbox was a reasonable way to store mail, so we’ve discussed conversion several times).
Once you’re on Virtualmin on your new system and you’re doing things the way Virtualmin does them, you never really have to think about all these differences again. You can always move a Virtualmin backup to a same-version or newer Virtualmin system (same OS version or newer, too, that’s even more important than Virtualmin version) without much hassle, as we try to accommodate all the minor changes we’ve made over the years to how things are done and default configs. And we can much more easily help you when things go wrong with migrations from one Virtualmin server to another, because we are familiar with all the various versions of Virtualmin and the way it’s done things over the years. Your old system is a total mystery to us. You’ll have to understand it to migrate out of it.
Now, on to the wishful thinking option. The one that involves installing Virtualmin (but not running the automated install, because that would be incredibly dangerous on a production server and is not something you should ever do). This is only worth doing if your LAMP stack and the way you configure things is kinda similar to the way we do things in Virtualmin.
You have Webmin on the old, but Webmin doesn’t come with a stack of applications and a default configuration, and having Webmin tells us literally nothing about what your hosting stack looks like. The way you setup your server could be wildly different from what a Virtualmin system looks like.
But, if you have your domain in its own home directory (preferably in /home, but you can configure around it being in /var/www, as long it has its own user), you could install the Virtualmin module into Webmin (it’s just one Webmin module, installable like any other Webmin module), and if (this is a big if) you did most things in your LAMP stack (and mail stack) similar to the way Virtualmin does it, you could use the Import Virtual Server feature.
Here’s where I think this method is likely to fail:
If you’re using mod_php to run your app. That was a mistake back when you built the server, and it continues to be a mistake today, but it’s a mistake that’s hard to work around when using a Virtualmin backup/restore, since Virtualmin will expect to be able to restore the app as it was…mod_php stupidity and all. You probably have to install mod_php on the Virtualmin server, restore the domain(s), and then switch to a good execution mode (php-fpm) and then uninstall mod_php (because you absolutely should not have mod_php on any server).
You probably didn’t create a user for the domain, you probably just put your site into /var/www and made it the default site. Easier just to create a new domain in your Virtualmin server, copy the app and databases over to the new domain user’s home and databases, and fix permissions.
Mail is probably a mess. I won’t even try to guess what you did, there are too many possibilities. Virtualmin will probably guess wrong, too, because there are too many variables.
I’ve rambled a lot, mostly because I have incomplete information. The fact that you installed Webmin tells us literally nothing about how you’ve configured your system, what servers you’re using, etc. and that’s what determines whether you can import the domains into Virtualmin on that old server in a reasonable way and a way that would lead to backups that could be restored on a new Virtualmin server. It might work. It might even be easy. But, that depends on so many variables shaking out in the right way (and I know what kind of crazy complicated and insecure shit is out there on the internet in terms of guides for setting up a LAMP stack).
Wow, thanks a bunch for this awesome write up @Joe and sharing all this information which is very appreciated.
Well we are have setup this production server with our invoice system (Runs Invoice Ninja: https://shorturl.gg/Invoice-Ninja), which runs on a Linux Ubuntu server:
and it is manually installed with php 8.1, mariaDB, Apache webserver, Lets Encrupt SSL certs and then Webmin to ease the pain of using Linux and make it faster/easier for daily admin task.
We are not forced to move as the old host is shutting down and being mergered with the new one and they are forcing us to move to new server, (Well not us of course, but all old customers). So obviously we are looking for a way to move this server quickly as we have very few days left to do it. I saw that Virtualamin had some interesting functions so I thought I would look closer into it which is also why I ended here.
One little bit of light in your situation: MariaDB makes the database part of migration easy, since it’s the default database in a fresh install of Virtualmin. Restoring a MySQL database into MariaDB can be tricky these days since MySQL has begun diverging in incompatible ways in the past couple of versions.
