I spent no less then 3 years discussing this internally with my colleagues & managers running both side by side.
For some context, we only manage servers, but do so in a global environment with API based automations.
Our takeaway is there is NO clear winner. It’s all based on the business goals and requirements, Period, full stop. They both suck and are awesome in their own rights. Neither fixes all problems and both have their stregths and weakness.
We went with BigFix. A few reasons why. Cost (was NOT our primary driver), much easier operational management of the infrastructure, less infrastructure requirements (server specs, mainly), BigFix can do things NOW much better then SCCM, cross platform capable, REST API & other API, less integration requirements/limitations within AD. We also like the plugins to SNOW, VMware, AWS, Azure, Google, but are till building that stuff out. What’s not as good? Patch validation reporting for Windows (based on our needs), the fact that patches sometimes lag behind or are missing from BigFix while available in WSUS (this is normally not an issue but occasionally, like last month, a patch was missing for 9 days post release due to bad relevance), propriety Actionscript & Relevance (but then SCCM has that weird OS SQL stuff and MOF we don’t have to deal with), and it’s way easier to just turn something around quickly in our experience.
I think it’s worth mentioning again… the BigFix infrastructure is cakewalk in comparison to SCCM to maintain. I am sure if you are an SCCM super admin, you may not agree, but in my opinion a large organization requires nearly a full time person to just maintain SCCM. With BigFix, it is only a small portion of an administrators time. For example, we run a failover (DSA) environment. I can upgrade BigFix and all clients to a new release starting in the morning and be completed by lunch.
