Your PSA Is Not Your Problem — Your Configuration Is

I talk to MSP owners every week who are convinced their PSA is the problem. ConnectWise is too complicated. HaloPSA is missing features. Autotask is too rigid. The platform is holding them back.

Sometimes they're right. Platforms have real limitations, and sometimes a migration is the correct answer. But in my experience — and I'll put a number on this — about 70% of the time, the frustration isn't with the platform. It's with the configuration.

The platform can do what they need. It's just not set up to do it.

The configuration vs. platform distinction

Here's a simple test: when you describe the problem you're having, is it "this platform cannot do X" or is it "X doesn't work the way I want in our setup"?

"ConnectWise can't auto-route tickets" is a platform claim — and it's wrong. ConnectWise absolutely can auto-route tickets. It just requires workflow rules to be configured.

"Our tickets don't get auto-routed" is a configuration reality. The capability exists. It's just not turned on or configured for your specific environment.

I hear the second one dressed up as the first one constantly. "ConnectWise doesn't handle our billing correctly" usually means the agreements aren't configured to match the billing model. "HaloPSA's SLAs don't work for us" usually means the SLA policies aren't set up to reflect actual service tiers. "Our PSA doesn't give us useful reports" usually means nobody built the reports.

The distinction matters because it changes the solution. If the platform truly can't do something, you need a different platform or a workaround. If the platform can do it but isn't configured to, you need configuration work — which is faster, cheaper, and less disruptive than a migration.

How configurations go wrong

Nobody deliberately misconfigures their PSA. It happens gradually, through a predictable set of patterns.

The rushed implementation. The PSA was set up quickly to get the business operational. The defaults were accepted. The advanced features were deferred. "Phase two" was planned but never executed. What was supposed to be a temporary starting configuration became permanent.

Staff turnover. The person who configured the PSA left. Nobody who remained understood why things were set up the way they were. Changes were made tentatively, with a "don't touch what you don't understand" approach that prevented both improvement and maintenance.

Organic growth. The business evolved — new services, new client tiers, new team members, new tools — but the PSA configuration didn't evolve with it. The configuration that worked for a 5-person shop serving 50 endpoints is still running unchanged at a 15-person shop serving 300 endpoints.

Workaround accumulation. Someone couldn't figure out how to make the PSA do something, so they built a workaround. Over time, workarounds accumulated and became entrenched. The PSA's native capabilities went unused because the workarounds were "how we do things."

Fear of breaking things. The PSA is a production system. Making changes to a production system is risky. So people avoid making changes, even beneficial ones, because "what if something breaks." The configuration calcifies.

The symptoms that look like platform problems but aren't

"Reporting is useless." The built-in reports don't show what you need. But have you built custom reports? Both ConnectWise and HaloPSA support custom report creation. BrightGauge, Power BI, and NHServer Reporting connect to PSA data and can produce virtually any analysis you need. The data is there. The reports just haven't been built.

"Billing is always wrong." Invoices have errors every month. But the errors are almost always in the agreement configuration — wrong quantities in additions, missing exclusion rules, stale rates — not in the platform's billing engine. Fix the inputs and the outputs fix themselves.

"Techs hate using it." The interface has too many clicks, too many fields, too many options. But most of that friction comes from custom fields nobody uses, statuses that don't match the workflow, and boards that should have been consolidated years ago. Clean up the configuration and the interface simplifies.

"We can't automate anything." Everything is manual. But the automation engine — workflow rules in ConnectWise, automations in HaloPSA — is sitting right there, unconfigured. The automation capability exists. It just hasn't been built.

"Integrations don't work." Data doesn't flow between systems. But the integration settings haven't been reviewed since initial setup, there are errors in the sync queue that nobody's addressed, and two of the three API connections are using credentials for an employee who left six months ago.

The cost of misdiagnosis

When you blame the platform for a configuration problem, you pursue the wrong solution. You evaluate new PSAs. You sit through demos. You spend weeks comparing feature matrices. You commit to a migration that takes months and costs tens of thousands of dollars.

Then you set up the new platform with the same rushed implementation, the same lack of documentation, the same deferred "phase two" — and within two years you're having the same frustrations with a different logo in the corner.

I've seen this cycle play out multiple times. MSP migrates from ConnectWise to HaloPSA because "ConnectWise doesn't work for us." HaloPSA gets set up quickly. Advanced configuration gets deferred. Two years later: "HaloPSA doesn't work for us." The platform changed. The pattern didn't.

The pattern is the problem. Not the platform.

How to tell if you actually need a new platform

There are legitimate reasons to switch PSAs. Here's how to distinguish a real platform limitation from a configuration problem:

It's a platform problem if: The feature genuinely doesn't exist on the platform, and no amount of configuration, customization, or API integration can create it. Example: if you need native support for a billing model the platform doesn't support and can't be approximated through existing features.

It's a configuration problem if: The feature exists but isn't turned on, isn't configured correctly, or isn't configured for your specific use case. Example: "auto-routing doesn't work" when workflow rules haven't been created.

It's a platform problem if: The vendor's pricing, contract terms, or business direction is fundamentally misaligned with your business. No amount of configuration fixes a 40% price increase or a mandatory 3-year contract.

It's a configuration problem if: You're frustrated with daily operational friction — slow workflows, inaccurate billing, poor reporting — that traces back to how the system is set up rather than what the system can do.

Before committing to a migration, invest in an honest assessment of your current configuration. Have someone who knows the platform well — not the vendor's sales team, not a generalist IT consultant — audit your setup and tell you what's fixable and what isn't.

You might save yourself a year of disruption and a pile of money. Or you might confirm that migration is the right move, but now you'll enter the new platform with the knowledge to configure it properly from day one.

---

Not sure if you have a platform problem or a configuration problem? Book a discovery call and I'll give you a straight answer.