How can I merge 2 instalations of NPM?

You might as well just call support now on that one.  :P

I had the same need.  I did contact support.  They were UTTERLY USELESS not very helpful.  I am feeling buyers' remorse.  I thought I would update this record just as caution or warning to others.

I do not think that you can merge NPM databases... More than likely, you will end up having to perform discovery jobs for the nodes you wish to "move" to the new NPM instance.  However, there are may variables to consider before even attempting to do a massive move of nodes to the new NPM instance...

• SQL server sizing --  Does the SQL server has enough CPU, RAM, disk space, etc. so it can support all the new nodes?
• Additional Polling engines -- Do you have enough of these or will you need to purchase more before proceeding?
• Are all the new nodes configured to accept SNPM-based polling from the new NPM servers (and polling engines)?
• Are the new nodes configured to send SNPM traps and/or Syslog messages to the new NPM servers?
• Are there any modules that you need to migrate from the "old"  NPM instance to the new one? i.e. IPAM, SAM, NTA, etc.
• Are there any firewall changes needed, allowing SNMP, ICMP and Syslog, etc. traffic between the nodes an the new NPM server?
• Will there be any Active Directory concerns to be addressed?
• Polling alerts , Syslog alerts and/or SNMP traps -- Do you need to export some of these to the new NPM instance?
• Other issues -- i.e. Custom scripts, integration w/third party apps, etc.

As you can tell, there are too many variables to consider before offering "best approach".  You should have answers to the above questions before do you anything else.  Perhaps your SW account manager might setup a call between yourself and the SW application engineers and/or NPM developers, which might help you visualize what you need to do.  However, this is no small feat; I sure do not envy you, but I wish you the very best on this project.

I had this whole thing written, but then the internet ate it. Here we go again:

I think this is do-able on some level, with some caveates and work-arounds.

First, let's level set: One of your SolarWinds instances is "it" - the one you will keep and add everything into. The other instances are "not-it".

As mentioned by Ecklerwr1, all your instances should be on the same version of software, should have all the same custom properties, etc.

You will NOT be able to import statistic data. Period.

But wait. There may be a work-around. (read to the bottom for that).

Now, let's get to work with merging the systems. You have two options: simple and complicated. I would personally opt for simple, but I'm giving you both. You will need SQL skills to do some of this - especially Complicated.

YMMV, Caveate Script-or, E Pluribus Unum, Objects may be closer than they appear, blah blah blah.

Simple

1. Export the node name, IP, and all your custom properties (including "oldnodeid").
   1. You COULD just pull the whole nodes table, but it's overkill.
2. Set up a new discovery, and use the IP's addresses from step 1 and import all those boxes.
3. Add interfaces, disks, application monitors, etc.
4. Now in SQL, you can update the custom properties of those old nodes by joining the IP address from the two sources.
   

Complicated
In this example, you are going to force-stuff entries into the Nodes, Interfaces, and Volumes tables.

Do I need to mention? backup! test with one row! Proceed with caution!

Disclaimer: I've never actually tried this at home.

1. In the "not it" system, add a new Node custom property named "newnodeid"
2. Also in the "not it" system, add two custom properties to the interfaces table: "newintid" and "newnodeid"
3. Do the same thing with volumes - two custom properties named "oldvolid" and "newnodeid"
4. Go to the "it" system. Find the largest nodid number (select max(nodes.nodeid) from nodes).
5. In the "not it" system, update "newnodeid" using sequential numbers starting from the next number after the result from step #4
   1. what you are doing is force-feeding node ID numbers into the "it" solarwinds instance
6. Do the same thing for interfaces - find the largest number in the "it" interfaceid field of the interfaces table, and then sequentiall update "newintid" field.
7. Ditto for volumes
8. Now, in the "not it" interfaces table, you need to update the "newnodeid" field. You'll do that by joining "not-it" nodes to "not-it" interfaces. The query would look something like:
   update interfaces
   join nodes on interfaces.nodeid = nodes.nodeid
   set interfaces.newnodeid = nodes.newnodeid
9. And do the same for volumes

NOW what you have are 3 tables - nodes, interfaces and volumes that are set up with the new ID numbers and pre-associated for volumes and interfaces.

From here, you just (JUST! HA!) import these rows into the tables of your "it" instance of Solarwinds. If all goes well, you should have new nodes and their interfaces/volumes.

Honestly? For the risk and hassle, I would definitely go with the "simple" solution.

So what was that workaround you mentioned?
So you want to still have all that old data around? It's really not that hard.

At it's simplest, just keep the database and run queries against it.

"But I have all these reports!!"
No, you have queries. Open any of those .OrionReport files and you will find nothing but glorious SQL-y goodness inside.

Still not good enough? You *can* load those reports into your "it" instance of SolarWinds and modify the reports. They would need to be converted to SQL reports, and you would need to use the "use" command at the start to connect to the other database. But with a little configuring, it can work.

I know that's not a complete answer, but hopefully it's a point in the right direction.

reading  this blog post it should be possible to copy nodes from one NPM install to another using the API:

Thanks to all who responded!  It looks like since I didn't initiate this question I am not able to mark answers and award points.  If that matters to those whom have taken the time to respond please let me know and we will find some way to make it right.