Leaving Kaseya VSA: a migration plan that works around a multi-year contract

The date that governs a Kaseya VSA migration is not the day you choose a new platform. It is the last day you can serve notice without auto-renewing. Plan a Kaseya VSA migration backwards from that date: confirm the notice window, start a parallel deployment roughly four to six months before term end, rebuild agent procedures and policies in the new tool, then cut over agents client by client so VSA is empty well before the contract expires. Here is the timeline, clause by clause and month by month.

Read the contract before you read any comparison page

Many MSPs start with the fun part, trialling alternatives, and only open the agreement when they are ready to leave. That ordering is backwards, because the paperwork, not the tooling, decides your real deadline.

This is not legal advice. Agreements vary by year signed, reseller, bundle and any amendments, so check your own agreement and, if the sums matter, have a solicitor read it. What follows is a list of what to look for, not what it will say.

• Term and start date. Find the exact commencement date and the term length. Bundled agreements sometimes carry different start dates for different products, so note each one. Skip this and you may be counting from the wrong anniversary.
• Auto-renewal language. Look for whether the agreement renews automatically, and for how long. A renewal for a full new term is a very different risk from a monthly roll-on.
• Notice period and method. Note how many days before term end notice must arrive, and how it must be delivered: email, a portal, a named address, written letter. Notice sent the wrong way can be treated as no notice at all.
• Minimum commitments. Check whether you committed to a minimum endpoint count or spend. If you did, reducing agents early saves you nothing on the invoice, which changes how fast you need to migrate.
• Data and termination assistance. See what the agreement says about exporting your data and how long access continues after termination. Assume it ends on the day the term ends unless the text says otherwise.

If VSA sits inside a wider Kaseya bundle with Datto products, the same logic applies to each line item. We covered the bundle side in getting out of a multi-year Kaseya contract.

Serving notice: early, in writing, and confirmed

There is a common instinct to serve notice late, so the vendor has less time to complicate things. We think that instinct is wrong. A notice served comfortably early costs you nothing if the window allows it, and a notice served one day late can cost you another term.

Serve it by the method the contract specifies, keep a copy, and ask for written acknowledgement. If none arrives within a reasonable time, chase it. Silence is not confirmation.

Expect a retention conversation. Listen to it, because a better offer is information, but do not let it pause the technical work. A migration paused for a negotiation tends to stay paused.

When to start the parallel deployment

Running two RMMs at once feels wasteful. It is the cheapest insurance you will ever buy. Because you are paying for VSA until term end regardless, the overlap does not cost you extra on that side; it only costs the new platform's subscription for a few months.

For a small to mid-sized estate, four to six months before term end is a sensible start. That leaves time for a trial, a pilot client, a rebuild of your automation and a staged rollout, with slack for the client whose firewall blocks everything. Larger or messier estates should start earlier. The general method is in how to switch RMM platforms without dropping a single endpoint; the VSA-specific parts follow.

Moving agent procedures without moving the mess

VSA agent procedures accumulate the way lofts accumulate boxes: some are essential, some were written for a client you lost years ago, and nobody remembers which. A migration is the one moment you are forced to open every box.

1. Export and inventory. Export your agent procedures and list each one with its schedule, target machines and last run. Anything that has not run in months is a candidate for retirement.
2. Classify by what each procedure actually does. Most fall into a few buckets: software deployment, maintenance and cleanup, configuration enforcement, and information gathering. Each bucket maps differently in a new tool.
3. Rewrite as PowerShell, not as translations. VSA procedures often wrap script steps in proprietary logic such as file transfers, conditional steps and variables. Do not try to mimic that structure line for line. Rewrite the intent as a self-contained PowerShell script that returns a clear exit code. Skip this and you inherit VSA's quirks in a platform that does not have them.
4. Replace procedures the new platform makes redundant. Patching, third-party updates and software deployment are often native features elsewhere, so a procedure that installed and updated an application can simply disappear. Our guide to third-party patch management covers what to expect natively.
5. Test on a pilot group. Run every rewritten script against your own machines first, then a pilot client, before it touches anyone else.

Policies: rebuild the intent, not the tree

Policies in VSA are usually layered by organisation and machine group, with years of overrides. Exporting the tree and recreating it faithfully reproduces every exception, including the ones nobody can justify.

Instead, write down what each policy is meant to achieve: patch windows and approval rules, monitoring thresholds and alert routing, antivirus and security baselines, and maintenance schedules. Then build a clean baseline in the new platform and add client exceptions only where someone can say why they exist.

The why test: if no technician can explain an override in one sentence, it does not migrate.

A dated timeline that ends on the contract end date

Replace T with your contract end date. The notice step sits wherever your agreement puts it; the example below assumes a 60-day window, so adjust it to yours.

Failure modes: how VSA migrations go wrong

• The late notice. Technically complete, contractually stuck for another term. The most expensive mistake on this list.
• The big-bang cutover. Every agent swapped in a week, alerts misconfigured, and a quiet gap in patching nobody spots for a month.
• The faithful translation. Every old procedure rebuilt, including the dead ones, so the new platform starts life as cluttered as the old one.
• The orphaned agent. VSA uninstalled from the console view but still present on machines that were offline, still checking in to nothing.

Where this fits with Helios

Most of this plan is discipline, not tooling: reading the contract, serving notice properly and retiring procedures nobody needs are jobs no platform can do for you. Where Helios helps is the parallel run and the rebuild. Its agent installs alongside VSA, Helio, the AI agent, can help rewrite old procedures as PowerShell and build them into a playbook library, and patching, Microsoft 365 management, remote access, ticketing and billing all sit in one product, so many procedures simply stop being necessary. Plans are flat and published on the pricing page, billed monthly with no annual lock-in, which means you never have to build a timeline like this one again.

Helios: AI-native RMM and PSA for MSPs and internal IT teams. 14-day trial and no feature gating. Start free.

Researched and written with Helio SEO, our AI writer for business blogs.