Midserver migration to Azure or drop VMWare?

pbostian
Tera Expert

With the Broadcom acquisition of VMWare, our vm costs are now bordering on ridiculous.  As a result, we are moving as much as possible to our Azure cloud.  We're talking thousands of VMs.  15 of those are my midservers.  I already have ONE midserver in Azure for discovery *of* Azure.  the other 14 on prem do various things - 6 for local network desktop discovery, 3 for local server discovery, one for event management, one for service mapping, etc... 

 

Question is this... i'm 100% NOT a fan of moving the local desktop/server discovery mids to Azure, as the data costs would be extreme.  just ONE of my mids does 2-3Gb of traffic an hour, 24/7.  Plus all the data latency issues, etc.  the Azure data cost would be big.  Has anyone kept their mids on-prem with a different virtualization service?

 

I know i need to keep them local... just dont know how yet and hoping someone has already gone through this and can help.

 

 

 

1 ACCEPTED SOLUTION

AJ-TechTrek
Giga Sage
Giga Sage

Hi @pbostian ,

 

You’re absolutely right to keep local discovery MID Servers on-prem


* Discovery traffic is very chatty: WMI, SNMP, SSH, probes, patterns… easily 2–3GB/hour per MID.
* Moving those MID Servers into Azure → big egress data charges + higher latency → discovery becomes slower & less reliable.

 

1) Options to keep MID Servers on-prem without VMware
If you’re moving away from VMware, but still want on-prem:


a) Physical servers
* For critical MID Servers, run them as physical machines.
* It removes hypervisor cost completely.
* Easy to manage if your fleet of MIDs is relatively small (e.g., < 20).

 

b) Alternative virtualization:
* Use Proxmox, XCP-ng, KVM, Hyper-V (free / Windows Server role), or even Nutanix AHV.
* All are production-ready, some open source, some with support options.
* For most orgs, Hyper-V is often a popular drop-in since it’s built into Windows Server, no extra license.
* Proxmox and XCP-ng are used widely in mid-sized enterprise environments for internal infra.

 

c) Containerize your MID servers (experimental / advanced):
* ServiceNow officially supports running MID Server as a Docker container.
* Great for CI/CD and dynamic scaling.
* You’d still need on-prem container hosts → but those could be on KVM, bare-metal, or cheaper hypervisors.
Ref:
“You can install a MID Server on Docker on a Linux host.” – ServiceNow docs

 

2) Keep your MID Server placement based on what they discover
MID Purpose Where it should be deployed
Local servers / desktops On-prem MID Server, near data center, low latency
Event Management from local infra On-prem MID Server
Service Mapping of on-prem apps On-prem MID
Discover Azure / Azure native services MID in Azure subnet (already have!)
Discover AWS / GCP MID in respective cloud
Best practice: Always place MID Server as close as possible to the CIs it needs to discover / monitor.

 

3) Practical steps:
A. Identify what each MID does → group by target environment.


B. Choose the cheapest & reliable on-prem hypervisor (e.g., Hyper-V / KVM / Proxmox).


C. Keep at least two on-prem MIDs for redundancy.


D. Keep your cloud MIDs in Azure for discovering Azure resources only.

 

4) Security & firewall
* Local on-prem MIDs still need outbound HTTPS (443) to ServiceNow instance.
* No inbound port needed → keeps security simple.

 

5) Why this works:
* You don’t lose ServiceNow discovery / event capacity.
* Avoid big cloud egress charges.
* Avoid Broadcom VMware costs by moving infra to alternative hypervisors.

 

Summary / Recommended:
* Keep on-prem MID Servers for anything local.
* Move only cloud discovery MIDs into Azure/AWS.
* Consider Hyper-V / KVM / Proxmox / Nutanix AHV instead of VMware.
* Docker MID Servers are interesting, but you still need on-prem hosts.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025

View solution in original post

2 REPLIES 2

Abbas_5
Tera Sage
Tera Sage

Hello @pbostian,

 

Please refer to the link below:
https://www.servicenow.com/community/itom-forum/mid-server-migration-to-azure-cloud/m-p/943330

https://www.servicenow.com/docs/bundle/yokohama-it-operations-management/page/product/it-operations-...

 

If it is helpful, please hit the thumbs up button and accept the correct solution by referring to this solution in the future, as it will be helpful to them.

 

Thanks & Regards,

Abbas Shaik

AJ-TechTrek
Giga Sage
Giga Sage

Hi @pbostian ,

 

You’re absolutely right to keep local discovery MID Servers on-prem


* Discovery traffic is very chatty: WMI, SNMP, SSH, probes, patterns… easily 2–3GB/hour per MID.
* Moving those MID Servers into Azure → big egress data charges + higher latency → discovery becomes slower & less reliable.

 

1) Options to keep MID Servers on-prem without VMware
If you’re moving away from VMware, but still want on-prem:


a) Physical servers
* For critical MID Servers, run them as physical machines.
* It removes hypervisor cost completely.
* Easy to manage if your fleet of MIDs is relatively small (e.g., < 20).

 

b) Alternative virtualization:
* Use Proxmox, XCP-ng, KVM, Hyper-V (free / Windows Server role), or even Nutanix AHV.
* All are production-ready, some open source, some with support options.
* For most orgs, Hyper-V is often a popular drop-in since it’s built into Windows Server, no extra license.
* Proxmox and XCP-ng are used widely in mid-sized enterprise environments for internal infra.

 

c) Containerize your MID servers (experimental / advanced):
* ServiceNow officially supports running MID Server as a Docker container.
* Great for CI/CD and dynamic scaling.
* You’d still need on-prem container hosts → but those could be on KVM, bare-metal, or cheaper hypervisors.
Ref:
“You can install a MID Server on Docker on a Linux host.” – ServiceNow docs

 

2) Keep your MID Server placement based on what they discover
MID Purpose Where it should be deployed
Local servers / desktops On-prem MID Server, near data center, low latency
Event Management from local infra On-prem MID Server
Service Mapping of on-prem apps On-prem MID
Discover Azure / Azure native services MID in Azure subnet (already have!)
Discover AWS / GCP MID in respective cloud
Best practice: Always place MID Server as close as possible to the CIs it needs to discover / monitor.

 

3) Practical steps:
A. Identify what each MID does → group by target environment.


B. Choose the cheapest & reliable on-prem hypervisor (e.g., Hyper-V / KVM / Proxmox).


C. Keep at least two on-prem MIDs for redundancy.


D. Keep your cloud MIDs in Azure for discovering Azure resources only.

 

4) Security & firewall
* Local on-prem MIDs still need outbound HTTPS (443) to ServiceNow instance.
* No inbound port needed → keeps security simple.

 

5) Why this works:
* You don’t lose ServiceNow discovery / event capacity.
* Avoid big cloud egress charges.
* Avoid Broadcom VMware costs by moving infra to alternative hypervisors.

 

Summary / Recommended:
* Keep on-prem MID Servers for anything local.
* Move only cloud discovery MIDs into Azure/AWS.
* Consider Hyper-V / KVM / Proxmox / Nutanix AHV instead of VMware.
* Docker MID Servers are interesting, but you still need on-prem hosts.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025