Why your SCCM estate is a liability in 2023
Configuration Manager (SCCM) is still running in tens of thousands of organisations. For many of them, it's becoming a liability rather than an asset.
I want to make a case that might annoy some people: if you're still running a large SCCM (Microsoft Endpoint Configuration Manager) estate in 2023, you have a liability, not an asset.
I say this as someone who has spent years delivering SCCM implementations and who has genuine respect for what the product achieved. But the context has changed.
The maintenance burden
SCCM requires on-premises infrastructure: servers, SQL instances, distribution points, management points. That infrastructure needs to be maintained, patched, capacity-managed, and backed up. The SCCM product itself has a regular update cadence (about three major releases a year) and staying current requires planning, testing, and change management.
For organisations that have a dedicated SCCM team or at least a dedicated SCCM administrator, this is manageable. For the majority of organisations running SCCM with part-time attention from an IT generalist (which is most of them), the maintenance burden is quietly accumulating as technical debt.
The security exposure
SCCM's infrastructure components are high-value targets. A compromised SCCM server is a mechanism for deploying malicious code to every managed device in the estate. This isn't theoretical. There are documented attack techniques targeting SCCM infrastructure.
The product has improved significantly in recent versions (current branch from 2019 onwards has substantially better security posture than earlier versions), but the attack surface of on-premises infrastructure is inherently larger than cloud-managed alternatives. And if you're running older versions of SCCM because of the migration backlog I described in an earlier post, you may have known vulnerabilities in your management infrastructure.
The skills gap
SCCM expertise is becoming less common among working IT professionals. The skills are still there in more experienced practitioners, but the pipeline of new SCCM-skilled engineers is narrowing. Junior IT staff are being trained on Intune and modern cloud management, not on SCCM hierarchy design and SQL replication.
As your SCCM-knowledgeable staff move on, the institutional knowledge of your SCCM environment moves on with them. The documentation is usually sparse. The environment is usually complex. That's a risk.
The licensing signal
Microsoft has moved the product's future clearly toward co-management and eventual Intune-primary management. The investment in SCCM features and new capabilities has slowed compared to Intune. The product isn't being abandoned, but the direction of travel is unambiguous. Continuing to invest heavily in an SCCM estate is investing in the declining end of a migration path.
What I'm not saying
I'm not saying everyone should have abandoned SCCM already. There are legitimate reasons why complex organisations are still in co-management and moving gradually. OSD sequences for zero-touch imaging of complex builds, software metering, specific compliance reporting requirements: there are scenarios where SCCM still does things Intune doesn't.
What I am saying: if you're still primarily SCCM-managed with no migration plan, the liability is growing. Every month that passes without a plan is a month of accumulated technical debt, security exposure, and skills risk.
The migration is hard. I've written about that elsewhere. But the cost of starting now is lower than the cost of starting later, or worse, having the decision made for you by an incident or a resignation at the wrong time.
