Migrating from VSA 9 to VSA 10

In order to initiate the migration from VSA 9 to VSA 10, follow the below steps.

1. To kick off the migration process, reach out to your Kaseya account manager, or submit the Migration Form. Once the migration has been requested, a tracking ticket will be provided to you, and all communication on the migration process will be through this ticket.
2. After the ticket has been created, the VSA team will analyze your VSA 9 usage and telemetry. Once reviewed, your VSA 10 instance will be provisioned with the same number of licenses that you had in VSA 9, and this information will be conveyed to you via the tracking ticket provided in step 1.

   NOTE  If you need to modify the number of licenses in your VSA 10 instance, reach out to your Kaseya account manager.

3. You will be assigned a dedicated migration specialist and be asked to schedule two sessions with them: 
   • Session 1: The specialist will walk you through running the VSA 9 to VSA 10 migration wizard.
   • Session 2: The specialist will help you complete your setup and review with you and your team how to use the VSA 10 interface.

During the upgrade process, the following items will be migrated from VSA 9 to VSA 10: 

• Organizations and Machine Groups
• Devices (via the deployment of the VSA 10 Agent on those devices)
• Custom Fields
• Users
• Monitor Sets (converted into Monitoring Profiles in VSA 10)
• Agent Procedures (converted into Workflows in VSA 10) 

For more details on what is migrated, refer to Migrating from VSA 9 to VSA 10

NOTE  Certain items may not be able to be migrated to VSA 10. Our enhanced audit logging will show you what items migrated, and which didn't, along with the reason why they didn't migrate. This gives you a list of items you can reference when recreating items omitted during the migration.

Before starting the upgrade process, ensure you have completed the necessary preparations. As follows are a few key steps:

• Review the release notes. Take the time to carefully read the current and previous release notes for VSA 10. Release notes will provide you with important information about new features, known issues, and any specific requirements for the upgrade process. Refer to VSA 10 release notes.
• Check system requirements (on-premises only). Ensure your current system meets the minimum requirements for VSA 10. These include hardware, software, and operating system specifications. If necessary, plan to upgrade any components that fall short of the requirements.
  For on-premises installation instructions, refer to VSA 10 On-Premises Guide.

NOTE  Kaseya executes provisioning for SaaS/cloud-based customers.

• Prepare your team. Inform all VSA users of the upcoming upgrade. We recommend they review the fundamentals course available in Kaseya University as part of your subscription. You can provide access to the course via the admin console in KaseyaOne. Refer to Assign courses to a user in the KaseyaOne Online Help.

Log in via the link in your email inbox

An activation email from the VSA 10 team will contain a link that allows you to log in to your VSA 10 tenant. Once your account is initially created, you will be presented with the VSA 9 Upgrade Wizard.

Run the VSA 9 Upgrade Wizard

Watch a demo of the VSA 9 Upgrade Wizard.

NOTE  Certain configurations, including Software Management, Monitoring, Policies, Info Center, and Discovery, will currently require recreation in VSA 10 using our provided sample configuration.

What is brought over when upgrading from VSA 9 to VSA 10? 

• Organizations and Machine Groups
  • VSA 9 organizations will become organizations in VSA 10.
  • VSA 9 sub-organizations will become sites in VSA 10.

    NOTE  If no sub-organization exists in VSA 9, then the upgrade wizard will create a default site for the migrated organization in VSA 10.

  • VSA 9 machine groups will become agent groups in VSA 10.
• Machines
  • For Windows agents, existing VSA 9 agents will automatically deploy the VSA 10 agent.
  • For macOS and Linux agents, existing VSA 9 Agents will automatically prepare each device with specific information about the upgrade. Next, the VSA 10 agent will need to be installed manually. When the agent is deployed, based on the local system information from the VSA 9 Agent, the VSA 10 agent will register itself with the proper VSA 10 agent record
• Users
  • User passwords will not be upgraded. Instead, a secure invite will be sent to the email address found in VSA 9 for each user account.
  • If there is no email address for a given user account, you must provide one during the upgrade process for the user to be upgraded.
  • When migrating users, you must select a Team for each user.

  NOTE  While users will migrate, security levels will not. Security levels will need to be recreated as closely as possible in VSA 10 as Teams before running the upgrade wizard so they can be selected during the upgrade process. By default, there is an Administrators team in VSA 10. For more information on configuring teams in VSA 10, refer to User functions and permissions.

• Custom Fields

  • VSA 9 Managed Variables will upgrade to Custom Fields in VSA 10, and aligned with the relevant Organization, Site, or Group.

• Agent Notes
• Network records and discovered devices.
• Monitor Sets
  • Monitor Sets from VSA 9 will be brought in as Monitoring Profiles in VSA 10.
• Agent Procedures
  • Agent Procedure Steps and Conditions will automatically get translated to their Workflow counterparts.
  • Any Agent Procedure not executed withing 30 days will by default be excluded. This option can be changed.
  • All Workflows translated will be set to Inactive, giving you the opportunity to activate and schedule.
  • All Agent Procedures can be selected during the upgrade, but any step or condition not yet supported will be displayed in red once created. A 0-100% score will indicate the compatibility during the Upgrade Wizard process.
  • Workflows with any not yet supported actions or conditions can not be activated until manually edited.
  • Agent Procedures already translated into Workflows will not be included when re-visiting the Upgrade Wizard.

  NOTE  Agent Procedure imports are “as is” and are not guaranteed to work for all agent procedures being imported (for example: agent procedures with managed variables or managed files will need to be edited after importing to work). We will not modify or edit procedures after importing.

  NOTE  Cooper Copilot can be utilized to assist you in recreating any workflows that could not be brought over during the migration process. Refer to Create Workflows with Cooper Copilot.

What impact is there to end users? 

This is a side-by-side upgrade, meaning the VSA 10 agent will be installed alongside the VSA 9 agent. End users should not experience any disruption due to the migration.

Congratulations on successfully upgrading to VSA 10! As follows are a few additional considerations to keep in mind:

• Configure reporting, monitoring and patch management: These areas of VSA 10 will have to be manually configured after the migration. Review what you have in VSA 9 and configure the reports, monitoring policies, and patch management policies that you will need. This is a great time to evaluate your environment to eliminate redundant or defunct configurations. Refer to Reporting, Policies overview, andCreating/editing Patch Management policies.
• Set up your integrations: Make sure that any integrations you had in VSA 9 are also configured in VSA 10. Refer to Kaseya Integrations.
• Review your workflows: It's important to make sure that your migrated workflows are working as intended. Review and test your critical workflows, and make sure that they are working properly. Refer to Workflows.
• Let us know the migration was successful: Ensure that the migration team knows your migration was successful by reaching out on the migration ticket that was configured in Phase 1: Preparing for the migration.
• Set a date to decommission VSA 9: Once you have completed the initial Upgrade Wizard process and have taken a few weeks to get VSA 10 ready for production, please notify our team of a date to decommission your VSA 9 instance.
• Uninstall the VSA 9 Agent: We recommend you perform this step in VSA 9, but the uninstallation functionality is also available in VSA 10.
• Review the Migration History: On the VSA 10 Upgrade Wizard page, after the migration has completed, you can review the migration logs by clicking the Migration History button at the bottom of the page. This will display detailed process tracking of the migration, including any errors, in a human-readable format.

Below are answers to some frequently asked questions about the migration process.

VSA 10 On-Premises technical FAQ

Can I use the same DNS address for VSA 10 that I'm currently using for VSA 9?

No, you cannot use the same DNS as currently used by VSA 9. VSA 10 is not an in-place upgrade, it is a move to a new server with a new DNS address.

Can I change the DNS address of VSA 10 after installation?

No, once VSA 10 is installed, you cannot change the DNS address as all agents register against this DNS. The DNS address is locked in during the initial setup. The DNS is also registered against our license server which provides software updates and licensing to your VSA 10 instance.

Can I install VSA 10 on my current VSA 9 server?

No, you cannot install VSA 10 on the current VSA 9 server. VSA 10 requires a separate, new server installation.

What if changing DNS addresses would be difficult for my client networks?

Because the migration process requires the use of a separate, new server installation, you may need to look at options for your customers/users to allow access to a new DNS address. This is a limitation of the migration process that requires network policy updates on client endpoints.

Can I use a temporary DNS for VSA 10 and then change it to my original DNS after migration?

No, changing the DNS address of VSA 10 when already deployed is not supported. The DNS must remain the same throughout the lifecycle of the VSA 10 installation.

Do I need an existing VSA 9 subscription to get VSA 10 On-Premises?

Yes, you need to have an existing VSA 9 subscription and account relationship with Kaseya to be eligible for VSA 10 On-Premises migration.

Is VSA 10 like VSA 9 in terms of being able to split out more roles across more servers?

Yes, VSA 10 is like VSA 9 in terms of having separate servers for different roles.

For example, VSA 9 can have a separate application server and SQL server (two tiers). VSA 10 supports a three-tiered on-premises environment: application server (standalone), SQL Server (separate), and advanced reporting server (optional). The total architecture supports up to 3 servers.

NOTE  The Advanced Reporting server is optional and uses Wyn Enterprise (business intelligence engine) with its own database - no additional SQL Server license required.

How many agents can a single VSA10 application server manage?

VSA 10 can handle single instances running 25,000+ agents.

NOTE  Recommended architecture is separate application server and SQL Server for more than 5000 agents.

Is there any capability to have multiple app servers or front ends for load balancing?

VSA 10 does not allow two application servers to access the same database simultaneously. We do recommend leveraging VMWare/Hyper-V with High Availability (HA) capabilities which work well with VSA10 for failing over to other hypervisors.

What are the hardware requirements and performance capabilities?

Hardware requirements for VSA 10 versus VSA 9 are basically much less for SQL Server and a bit more for the application server. VSA 10 uses .NET cache on the application server which significantly reduces SQL Server database hardware requirements compared to VSA 9.

To put this into perspective, Kaseya’s own US Cloud supports 600,000 agents on a single SQL Server instance with 16 cores and 128GB RAM. VSA 10 is more efficient than VSA 9 due to this architecture and is less expensive per agent since SQL Server resources have been reduced by more than 50%.

How does the caching architecture work differently than VSA 9?

VSA 9 doesn’t have memory caching like VSA 10. VSA 10 caches real-time data in .NET cache on the application server. This cache holds short-term live data which doesn’t need to be persisted in the database. This significantly reduces the chatter between the application server and database. It also reduces page response times since most queries are direct from the application server’s RAM. Data that needs to be persisted is flushed to the database as specific data is updated.

NOTE  Advanced reporting connects via a JSON API to the application server rather than direct database connection since real-time data resides in app server cache.

What URLs and ports need to be allowed for VSA 10?

All agent and UI access is via port 443 with a valid SSL certificate. VSA 10 does need outbound access to our license, remote control relays, integration and dispatcher servers. These URLs should be allowlisted and details of these URLs can be found in our VSA 10 On-Premises Guide.

What are the requirements for air-gapped environments?

VSA 10 does support a locked down environment where inbound connections from agents can be controlled via a proxy server. Access to the UI is only via port 443 and there is an ability to lock down which IPs are allowed to access the UI from the outside. Additionally, VSA 10 only requires access to the license, remote relays and dispatcher servers for minimum functionality such as server/agent automatic updates, migrations from VSA9, Cooper AI and integrations.

VSA 10 licensing & pricing FAQ

How does perpetual licensing transition to subscription work financially?

When moving to VSA 10, customers forfeit perpetual licenses and move to subscription-based model, but pricing remains the same as current costs.

VSA 10 migration & upgrade path FAQ

How has the migration wizard been revamped and what's the process?

The VSA 9 to VSA 10 migration wizard now supports:

• Custom transfer (recommended) vs automated transfer
• Phased migration by organization (org-by-org approach)
• Dual agent implementation with grace period for parallel running
• Custom fields migration (machine-level only, not org-level)
• Agent procedure conversion to workflows with compatibility assessment
• User migration with team assignment
• Monitor sets migration
• Automated VSA 10 agent deployment via VSA 9

NOTE  The migration wizard can be run multiple times for different organizations, but each organization can only be migrated once. Batch agent procedures in smaller groups due to timeout issues with large quantities.

What happens to agent procedures that aren't 100% compatible?

Agent procedures become workflows in VSA 10. The migration wizard shows compatibility percentage and unsupported statements in real time. Procedures with less than 100% compatibility can be migrated but will require manual fixes in workflow editor. Cooper Copilot can help rebuild workflows from natural language descriptions using best practices.

NOTE  Some functions removed for security reasons (for example, SQL read/write capabilities). Complex procedures will require manual configuration.