Migrating from MID-Based ACC to MID-Less Setup with ITOM Cloud Services

Introduction

As organizations modernize their IT operations, reducing infrastructure overhead and embracing cloud-native architectures has become a top priority. In this journey, one of the most impactful shifts is moving from a MID-based Agent Client Collector (ACC) deployment to a MID-less setup powered by ITOM Cloud Services (ICS).

This blog provides customers with a practical guide to that transition:

Why MID-less matters
Key prerequisites and considerations
Step-by-step migration approach
Lessons learned from the field
Resources to help you succeed

Why Move to MID-Less?

Customers who migrate from MID-based ACC to MID-less ACC benefit from:

Simplified operations – Eliminate the need to maintain and patch MID servers for agent traffic.
Cloud-native agility – Agents securely connect to ServiceNow via ICS without relying on on-premise intermediaries.
Scalability – Easier to onboard thousands of endpoints globally.
Endpoint & DEX use cases – A must-have for Digital Experience (DEX) monitoring, where deploying MIDs per endpoint isn’t feasible.

📌 For DEX customers: see the ACC MID-less migration overview.

Prerequisites & Constraints

Before you begin, review these important considerations:

Instance must be on ADCv2 to have mTLS support
Go to Plugins page and install "ITOM Cloud Services Core (sn_itom_cloud_svc)" scoped app
Install Agent Client Collector for Visibility Content (sn_acc_vis_content) scoped app

Category	Requirement	Notes
Instance Readiness	ADCv2 must be enabled.	Confirm with ServiceNow support.
Licensing	Ensure your entitlement covers MID-less use cases (ITOM or DEX).	Validate before migration
Network Access	Agents require outbound TLS connectivity to ServiceNow gateways.	Check firewall and proxy rules.
ACC Version	Must be on a supported version (N-2 policy).	Upgrade older agents first.
Configuration	connect-without-mid: true in acc.yml required.	See Product Docs
Feature Coverage	Some discovery checks may differ from MID-based behavior.	Pilot test critical use cases

🔗 References:

Migration Approach

Here’s a recommended phased approach:

Plan & Assess

Inventory agents and current MID dependencies.
Validate feature coverage and identify potential gaps.
Enable ADCv2 and required plugins.
Prepare rollback strategy.

Phase 1: Pilot

Deploy ACC in MID-less mode (Linux one-liner or Windows installer).
Configure acc.yml with cloud parameters.
Validate connectivity, registration, and data ingestion.
Test critical use cases against current MID-based setup.

Phase 2: Production Cutover

Migrate agents in controlled waves (per region or service group).
Monitor logs, ingestion, and performance.
Retire MID server dependencies once stable.

Phase 3: Optimize

Fine-tune polling intervals and thresholds.
Monitor adoption and health dashboards.
Document lessons learned and update runbooks.

Lessons Learned & Tips

From customer pilots and community forums, here are key insights:

Clear cached keys when re-pointing agents: Remove agent-key-id in acc.yml if an agent doesn’t register to the new instance.
Watch for CnC errors: TLS or endpoint misconfiguration can block connectivity — verify certificates and gateway URLs.
Don’t assume feature parity: Some legacy discovery behaviors differ in MID-less mode. Test early.
Network egress is critical: Ensure proxies and SSL inspection don’t block ACC traffic.

What’s Next

Migrating to MID-less ACC is not just a technical upgrade — it’s a strategic step toward cloud-native ITOM.

Here’s how to move forward:

Start with a non-production pilot.
Engage ServiceNow architects to validate your setup.
Leverage KB articles and community discussions for troubleshooting.
Share your feedback and lessons with the community!

Resources

👉 Have you started your migration journey? What challenges or successes have you seen so far? Share your experiences in the comments below — your insights will help the broader ServiceNow community.