Why are our machines so slow after switching to N-Able?

Start by identifying which processes are using CPU, memory and disk on an affected machine, especially while it is slow. Compare that with the MSP's schedule for monitoring, patching and other jobs. A bunch of tasks running at once could explain the timing without the monitoring agent itself being the whole problem.

Ask the MSP to review the results and adjust the schedule or test changes on a small number of machines. That should give you something more concrete than guessing from the switch alone.

Check what else came with the new setup. N-Able deployments can include more than monitoring, such as web protection, endpoint security, backups and patch management. The MSP should be able to give you a list of what's installed and enabled.

Web protection is one possible source of high CPU use, but look at the actual process usage before singling it out. Also check whether the old MSP's tools are still present and whether any security services overlap.

Since this is N-Central, contact the MSP and N-Able support promptly about the N-Central security update and ask whether your deployment is affected. Have your security team review for signs of compromise as appropriate. The slowdown alone doesn't establish that the system was exploited, though, so keep investigating the performance issue separately.

If the slowdown started right after the change, ask the MSP to compare an affected machine with one that hasn't had the new deployment yet, if you have one. Record which components and jobs differ. A controlled test can help narrow down whether a particular service is responsible before you consider rolling the whole setup back.