Our small IT team has relied heavily on Kaseya VSA9 for several years. I manage most of our configuration, including Microsoft and third-party patching, policies, procedures, and custom automation. VSA9 can be awkward, but with enough testing and troubleshooting we have usually been able to make it do what we need.
With VSA9 approaching end of life, management is considering moving to VSA10. We briefly evaluated NinjaOne, but the current plan may be to stay with Kaseya and migrate to the newer platform. I have not seen VSA10 since an older demonstration, so I would like candid feedback from people who have actually moved from VSA9 to VSA10.
How difficult was the migration? Which features changed, disappeared, or improved? Are there specific limitations or questions I should raise during the sales demo?
5 Answers
Several people I know moved away from VSA because of both product limitations and frustration with the vendor. Datto RMM, NinjaOne, and other platforms are worth comparing, but switching tools means checking scripting, patch management, monitoring, reporting, integrations, and API coverage—not just the dashboard. A migration can be manageable, but rebuilding years of custom automation is where the real effort tends to appear.
Do not let the demo focus only on the features that look better in VSA10. Ask them to reproduce your hardest VSA9 workflows live: patch approval, third-party updates, registry changes, user-context actions, custom scripts, alerts, reporting, and recovery from failed jobs. Also ask what happens to historical data, existing agents, procedures, and integrations during the migration.
We started moving toward VSA10 but stopped and chose Datto instead. The main concern was that the newer product felt like a substantial rewrite rather than a straightforward upgrade, so many of the mature VSA9 options were missing or worked differently. If you are considering staying with the same vendor, compare the actual features you use today instead of relying on a general product demo.
Our migration was relatively painless from a process standpoint, but the feature loss was significant. The biggest problem for us was losing agent procedures entirely, since they were central to many of our automations. I would build a detailed inventory of every VSA9 procedure, policy, script, and patching workflow before agreeing to anything, then have the vendor demonstrate the replacement for each one.
If your environment already uses Microsoft 365, evaluate Intune seriously before committing to another RMM. It handles Windows management, configuration policies, and Autopilot well when it is set up properly. Application deployment can be quirky, though, so you may still need another tool for software distribution, monitoring, or advanced automation.
Our product contact told us they are continuing to invest in VSA10 and are working on restoring some missing capabilities, so the roadmap may matter. I would still insist on written commitments and a hands-on proof of concept before migrating.