Migrating from ScreenConnect: the step-by-step guide

Migrating a remote access tool feels risky when hundreds of machines depend on it. The method is simple though: inventory, parallel deployment, cutover, removal. Here is the path, step by step.

Why plan the migration now

In September 2026, CISA added a critical ScreenConnect flaw to its Known Exploited Vulnerabilities catalog after seeing active exploitation, an advisory covered by BleepingComputer. The episode makes one thing plain: a remote access tool must be patched and watched constantly. If you are weighing your options, compare methodically, then migrate cleanly. A well-run migration is also a chance to clean the fleet: dormant accounts, obsolete agents, access that no longer has a reason to exist.

Step 1. Inventory before touching anything

Before the first install, draw the map.

• How many machines you manage, with operating system and role for each.
• The split between attended sessions and unattended access.
• The list of technicians and their rights.
• The custom properties and scripts you will need to recreate.

The inventory is your gauge. It measures progress and catches machines that get left behind. It stays your dashboard until the final uninstall.

Step 2. Map your use cases

Each use case has a home in Ubidesk. Attended sessions map to remote support, machines you maintain map to unattended access. Note the extras too: Wake-on-LAN, rebooting into Safe Mode, mobile access. A missed use case resurfaces later as a missed machine.

Step 3. Deploy in parallel

The two tools coexist without conflict. Start with a pilot group: a few machines, a few technicians.

• Deploy the agent through your usual method, GPO, Intune or Jamf.
• Check firewall traversal: Ubidesk uses port 443 only.
• Test automatic reconnection after a reboot, including in Safe Mode.
• Validate Wake-on-LAN on a powered-off machine.

Every failed test gets fixed without pressure: that is the point of the pilot group. Once all four pass, the cutover is a formality.

Step 4. Switch attended sessions

For clients, the change is one new entry point. Sessions start with a 6-digit code, no installation and no administrator rights, through a temporary client that leaves nothing behind. Your clients have nothing new to learn. Your technicians’ habits carry over: invitation, session, close.

Step 5. Migrate unattended agents

Push the agent to the whole fleet, then confirm in the console that every machine reports in. Once coverage is complete, uninstall the old agent. The Ubidesk Pro plan, at 24 euros per technician per month billed annually, sets no limit on unattended devices. You do not have to choose between machines to migrate and machines to leave behind.

Step 6. Retire the old tool

Keep the old solution read-only while you close out the stragglers, then cut it. Archive access logs before deleting the account, as a legal precaution.

The mistakes that sink a migration

• Migrating without an inventory: machines end up with no agent and no access.
• Cutting the old tool too early: keep it read-only until the last case closes.
• Forgetting the edge cases: off-domain devices, personal machines, urgent replacements.
• Not telling clients: an unexplained new entry point generates pointless calls.

Cutover checklist

• Inventory of machines and technicians complete.
• Pilot group validated: connection, reboot, Wake-on-LAN, port 443.
• Agents deployed fleet-wide and confirmed in the console.
• Clients informed of the new entry point.
• Old agent uninstalled, licences revoked, logs archived.

The same method serves MSPs and internal teams alike. The rule that matters: never cut the old access until the new one has proved itself. Keep the checklist close: it is the only document you need on cutover day.