Patch Management Solution

We are using a trial version of "Patch Management" to see if it will function for us in our environment, and do what we need.
We are wanting badly to scrap SCCM. We mostly need to know where our computers are at with security patches, critical patches or fixes, etc. related to the OS and major software and then have a nice handy even fairly automated way to patch computers (about 300) plus a couple dozen servers.
.
I was trying to do this evaluation quickly as far as not wasting time and found we had a VM server that wasn't, I thought, over-taxed and which was stable.
At least I thought it was an ok server........... 
However, in the middle of this all, I found this server not so stable. It was built a few months ago by someone no longer here and there are many mistakes with it.
The server itself, a Microsoft 2012 Server, needs to go away when I'm all done - the other apps on it are struggling just to run, this product is running, but quite slow mostly due to server issues we knew about.

The Patch Management (and underlying notification server or whatever it's actually called) point to a SQL database on our dedicated SQL server that's on a totally different server.
We have a dedicated SQL server, that's all it does. All SQL-based apps and management services utilize databases on the dedicated SQL server. That server is fine and stable.

We will be bringing up a solid stable VM from my own more reliable template and it will be a 2012R2 server. It would be dedicated to this Patch Management product, or one other server-based product at the most.

I am assuming that IF we do find that this product will do what we need and is EASY TO USE, is hopefully much more easy and more reliable than SCCM, we'll make the purchase and we COULD simply apply the full purchased license to the existing setup using the Install Manager/SIM and just keep going, add all the rest of our computers to management under this.

Ah, but with the flaky server Patch Management is installed on now I'd rather not do that.
So the basic question would be - if we like this product and purchase the real license, how hard would it be to "move" it over to a newly built 2012R2 server from the not very good 2012 server it's on now - and not go through a full reinstall and configuratin from scratch again?

Can it be moved - or can it be installed on the new server, pointed to the existing SQL database and just pick up and go from where we left off?

Thanks.

Like any other piece of software, you can't just "move" it. You'd need to reinstall it on the new Server. However, nearly all of the config is held in the database but you'd need to point the agents that you've already installed towards the new server.

LOL - yeah, I knew that first bit but then of course I didn't exactly say that, did I? Sorry, yes, I knew/assumed that you can't just copy the files. I need to say what I mean.

OK, so understanding it's like most other products, would you, say just for example, compare it to SEP management where you can just run the install on a different server, plug in the information needed to connect it to an EXISTING database, and it could connect, read the data or specifics from SQL on the SQL server, and move forward without further configuration needed?

If you are a SEP user, you'll know exactly how very very simple it is if a server DIES - OR if you need a server OS upgrade it's a whole lot easier to create the new server, install SEPM new on that server, plug in the SQL information and you are basically done (well, perhaps there is security data, keys, certs, whatever but NO software configuration is needed)

Is it that simple?
What I'd like and I'll try to make sure I say what I really mean - thanks for your patience -
This server is nasty, no fault of Symantec. It's 2012 anyway and our new standard is 2012R2.  
I want to pull up a new VM (virtual server from template I create this summer) which would be 2012 R2, patch it, get it just right, *then* install the Patch Management to the NEW server.
But I'd like to not have to spend half a day starting all over again -
I assume I'd need to install the basics, get all the "plug-ins" installed as well, apply the licenses using the Installation Manager?
Is that pretty much it?
Ah, but the PCs with the agents or plug-ins or whatever they are (sorry, this is ALL new to me, two people have left and I'm wearing 4 hats now, not just the 2 I already had)

HOW does one point the agents to the NEW server, or can one simply give the new server the old server's name and IP address????
Is that a killer right there?

IF this thing passes muster, and if I find it's that easy to move, well, our purchasing decision will be based on many factors - and ease of maintenance is among them, not just how well it deals with our PCs and keeps them current, or how easy it is to keep our PCs current. I look at SUPPORT and ease of install and product maintance, not just can it do the job.

Thanks -

I'm not familiar with SEP but it sounds like a similar process. Run the install on the new server and point to the existing database. Minimal configuration is then required on the new server. To get the existing agents to point to the new server you can do a few things: 1/ Run a job on the old server to move the agents across, aexagentutil /server:newservername. But the new server needs to be contactable for that command to work. 2/ Use a manual DNS record for the old name to point to the new IP address Or I think you should just be able to build the new server with the same name and IP address as the old one, I can't think of any immediate problems.

It would seem to me that any of those 3 options would be fairly simple. The first is a nice ability - a utility to tell the client computer agents to talk to the other server. But the others are very "doable" as well.

OK, it sounds like it's not bad at all, I can accept those as reasonable methods, not complex at all - other than with the first the computer must be online to make that work and in our environment we struggle to get people to keep computers on or on the network, however, that's where the other 2 options could be used to catch and strays in case an office connection is down or people on vacation, or whatever.

Thanks - this is something I'll print and save with the book I've started for documentation. That was helpful, exactly the sort of information I was looking for, and confirmation that it's not difficult at all.