Hello Everyone, Following SolarWinds' transition to subscription-based licensing, I need to break down our long-standing SolarWinds platform into two separate platforms: one for Self-Hosted Observability and one for Basic NPM. Each platform will manage a specific portion of the current inventory. However, my alert configurations and ServiceNow integrations are relevant to all nodes, and I want to avoid recreating them from scratch. I am wondering if the following "split" strategy is possible: * Perform a full migration/clone of the legacy database and application to a new server (Server A). * Perform the same migration/clone again to a second new server (Server B). * On Server A, delete the inventory meant for Server B. * On Server B, delete the inventory meant for Server A. Each new platform would have its own unique IP, hostname, and database. Has anyone tried this? Are there major risks in "cloning" a database this way, or is there a less painful method to split the environment while keeping the alerts and integrations intact? I would appreciate any insight into whether this is a viable path.

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Splitting one SolarWinds platform into two separate instances?

Hello Everyone,

Following SolarWinds' transition to subscription-based licensing, I need to break down our long-standing SolarWinds platform into two separate platforms: one for Self-Hosted Observability and one for Basic NPM.

Each platform will manage a specific portion of the current inventory. However, my alert configurations and ServiceNow integrations are relevant to all nodes, and I want to avoid recreating them from scratch.

I am wondering if the following "split" strategy is possible:

Perform a full migration/clone of the legacy database and application to a new server (Server A).
Perform the same migration/clone again to a second new server (Server B).
On Server A, delete the inventory meant for Server B.
On Server B, delete the inventory meant for Server A.

Each new platform would have its own unique IP, hostname, and database.

Has anyone tried this? Are there major risks in "cloning" a database this way, or is there a less painful method to split the environment while keeping the alerts and integrations intact?

I would appreciate any insight into whether this is a viable path.

Find more posts tagged with

Accepted answers

All comments

Lofstrand

Hi @thealexo

Interesting approach. I think it will work! Just mind to clear the license store as you normally do when migrating to a new server.

Thinking about the ServiceNow integration, how that will react. I would pause that integration before cloning and when on the new instance, make sure the two have at least separate accounts in ServiceNow so there is a way to separate them.

bourlis

Yes, you can do that. In fact, last year we took 500 nodes from our SWOSH instance and we're going to do just that. However, at the last moment we chose to do a fresh built just to prevent "gremlin" migration from one system to the other.

I don't know the cost or if it's functionally feasible in your environment, but you might be able to use SW EOC as a bridge for your two new instances. You can then have NOC view of both environments with EOC and possibly use that as a single ServiceNow connection point.

HerrDoktor

it‘s possible, I have done that multiple times. The „gotchas“ with the licenses have been mentioned by @Lofstrand . However if you are comfortable with the API, you can write migration scripts to move data from your old instance to the new insinstances. With that you „start fresh“.

thealexo

Thanks bourlis!

Could you please share how you migrated everything to the fresh instance?

Thanks!

thealexo

Thanks!

Could you please shed more light on API migration?

I'm pretty comfortable with the API and already use it for automated discovery of nodes/interfaces.

Thanks in advance :)