Kaseya Community

Looking to move from an On Prem to Hosted Kaseya server

This question is not answered

We have been running Kaseya for the past 7 years on the same hardware.  The database and the VSA are on the same server.  It has some time to look at either replacing the hardware or moving to a hosted version of Kaseya.  We have about 1700 endpoints and we integrate with our On Prem ConnectWise server by a nightly sync between the two to automatically update configurations in ConnectWise.  Alerting is done via email connectors that Kaseya sends alerts to ConnectWise that workflow rules then process and those that require after hours alerting are routed properly.

I am trying to put together a list of pros and cons for going hosted and was hoping to get some advice from those here already using the hosted version of Kaseya.  How has this impacted servicing your clients?  How has upgrade been handled and how long have then taken?  From an uptime viewpoint how reliable has the hosted platform been?  If you have gone from an on prem to hosted have you seen more efficiency and more time available to handle other issues rather than researching, testing and then deploying updates to your Kaseya server?

Thank you in advance for your help!

Sal DiPietro

All Replies
  • Stay away from the Cloud hosted solution.. You will be sorry.. You will lose some functionality and control over your VSA platform. We moved away from cloud to on prem because there are things you can't do in cloud vs being on prem.. Also, you have no control over software updates. When they update, they proceed and you have not control over that.. For us, we wanted to control when we apply updates to the VSA because there are times whereby updates went out and stuff broke.. Also we wanted access to the backend database for reporting reasons and you will lose that access when you use their cloud setup. Plus for us, their cloud setup performed horribly and thus decided to put our setup into Azure. Best decision we made.

  • Thank you.  So are you running Kaseya on a physical server, or is it running as a VM in an Azure cloud?  

  • I second everything Buster just said.  You don't  want to lose that control.  Especially over updates.  We run Kaseya front end and backend servers as VM's (on seperate hosts) in a datacenter.

    We moved off hosted after the 1st year and have been on prem ever since.  

  • We have a application server and DB server setup in Azure

    Running on Premium Subscription

  • Salvatore:

    Keep in mind that hosted solutions are "shared" solutions, and depending on where you are, you may have to "travel" to a hosted data center quite far away. One of our MSP clients in AU was hosted in North America and performance was pretty slow after they scaled beyond 1000 endpoints. They are on-prem virtualized and have great performance now.

    We use the Tenancy module in-house and support some smaller MSPs that are getting started with VSA, and we have a pretty slick way to ultimately move them to their own (or hosted) VSA. At 1700 endpoints, you're already too big for a hosted solution, in my opinion as well of others that have migrated to on-prem.

    We have some Tech Brief documents on our website that deal specifically with setting up the VSA and SQL servers to enhance performance, and its a process we follow for every VSA we build for our customers regardless of where the servers are virtualized.

    If you add our RMM Suite to your VSA solution, it automates most of the administration tasks (other than VSA updates, which haven't been an issue for us), performs alert filtering to reduce noise into your PSA. I spend less than 15 minutes a week on VSA and agent administration, and about 30 minutes a month on patch administration with 3200+ endpoints.

    Glenn

  • So it seems, and please correct me if I am wrong, that the problem isn't so much Kaseya running as a VM in the cloud but with the Hosted version offered by Kaseya?  I ask only because when I think On Prem I think of a physical server sitting in a rack in our office, not a VM running in an Azure Cloud environment.

  • I would say that Buster's system would still be considered an "on prem" solution of the two options because it doesn't utilize Kaseya's hosted servers, but in this case, his physical servers reside as part of the Microsoft Azure cloud.  The way I like to think of it is that "the cloud is just someone else's computer."  In this case, his "premises" just happens to be an Azure data center instead of his server room.  Considering Kaseya is a web based application, that's certainly a viable option.  



    corrected extra carriage return that didn't need to be there
    [edited by: JordanD at 11:27 AM (GMT -7) on Sep 10, 2018]
  • "On-Prem" = you manage the server - it can be physical, virtual, or hosted in a cloud service. Key advantage is that you have 100% of the available resources of that server at your service, plus access to SQL queries for reporting and changes*. Disadvantage is that you have to maintain the O/S, VSA, and SQL - patches, updates, etc. Probably less of an issue than you might imagine. Our VSA usually completes patch updates in under half an hour, and agents update following that within 4 hours.

    "SAAS" = Kaseya manages the server - you don't know (or much care) where it exists. Advantage is that Kaseya keeps the platform and related applications up to date. Disadvantages - you don't control the outage window (might not always be convenient to you); The VSA is shared by several MSPs, which could impact performance if one has a sudden influx of agents; and there are limitations to what you can do - mostly related to SQL reporting (or updating) and ease of file management.

    At this time, every one of our MSP customers has an on-prem solution, but not one has a "physical" server that runs their VSA. Some have in-house VMware or Hyper-V platforms, and others run in AWS or Azure. As long as the infrastructure that hosts the VSA is properly designed, a virtual platform works very well. SAAS is ideal for the small MSP - it lets them get started with managed services and VSA without the worry of managing the infrastructure. There's a lot to learn, and this certainly lets them focus on customers and developing solutions first, but (again, in my opinion and experience with other MSPs) there's a limit to how far a shared platform will scale. You will need to discuss this with your CSR and the appropriate SAAS team to see how many resources will be available to a platform with that many agents.

    We use a 3-node 36-core / 432G RAM Hyper-V cluster in-house and both VSA and the SQL server are hosted there. I suppose that the only thing that might give me pause when building this in a hosted/cloud platform is that we deploy a VSA configuration with distributed disk to improve the I/O load performance. This might be just a bit more challenging (or costly) to implement in certain cloud environments. (FYI - we also have a VSA SAAS platform for code validation and testing.)

    Glenn

  • Thank you for the clarification!  I think I have enough information to go to my supervisor and discuss our options.  Either way, I think we need to move off of the hardware we are on.  The last time I did the upgrade it took a couple of hours and then another 4-5 to get all of our agents upgraded.

  • Be sure to check out the Tech Briefs on our web site for optimizing the disk layout!

    (requires a login).

    Glenn

  • With Azure, think of it like your virtual co-location except you don't have to worry about supporting hardware.. We have a couple of Azure Architects that oversee our Azure instance. I gave them the specs for the two servers and they got them configured.. I worked with Kaseya to get the the application loaded up, then we migrated information away from kaseya's cloud over to my azure servers. We have COMPLETE CONTROL over our own servers. That's the most important part about the setup. Azure's job is to make sure the underlying infrastructure is running correctly. My upgrades take lest than 30 minutes to complete and that's because I take my time with that process.