ConnectWise Automate → Breeze

ConnectWise Automate (formerly LabTech) is the most expensive migration in this section, and it is worth being honest about why: its scripts, internal monitors, and remote monitors are all proprietary step-based objects with no export path into anything else. None of them port. Everything else — the client tree, the computer list, the EDFs — moves fine.

Plan for re-authoring, not converting. In exchange, most MSPs find that a decade of accumulated Automate scripting compresses into a fraction of its original size.

Read Migrating to Breeze first.

---

Hierarchy Mapping

Automate	Breeze	Notes
Automate instance	Partner
Client	Organization	Direct match.
Location	Site	Direct match. Automate always creates a default location per client.
Computer group (static/auto-join)	Device Group	Auto-join groups map to Breeze dynamic device groups.
Computer	Device
Contact	Contact	First-class records, organization-level or pinned to a site. Bulk-load with Recipe 1c — matched on externalId so re-imports are idempotent, with fuzzy email/name matches held back for an explicit acknowledgement.

---

Phase 0 — Export from Automate

You have two routes. The REST API is the supported one; direct SQL against the labtech MySQL database is faster and far more complete, and is what most migration projects actually use for a bulk export. Use SQL for the export, and the API for anything you need to write back.

Option A — Direct SQL (recommended for export)

-- Client → Location tree, ready for Recipe 1
SELECT c.Name AS organization, l.Name AS site
FROM clients c
JOIN locations l ON l.ClientID = c.ClientID
WHERE c.Name NOT IN ('Deleted Clients')
ORDER BY c.Name, l.Name;

-- Device inventory + last-contact, for reconciliation and licence cleanup
SELECT c.Name AS client, l.Name AS location, comp.Name AS hostname,
       comp.OS, comp.LastContact,
       DATEDIFF(NOW(), comp.LastContact) AS days_stale
FROM computers comp
JOIN clients   c ON c.ClientID   = comp.ClientID
JOIN locations l ON l.LocationID = comp.LocationID
ORDER BY days_stale DESC;

-- EDFs (Extra Data Fields) at computer scope
SELECT comp.ComputerID, comp.Name AS hostname, ef.Name AS field, ed.Value
FROM extradatavalues ed
JOIN extrafield ef ON ef.ID = ed.ExtraFieldID
JOIN computers comp ON comp.ComputerID = ed.ExtraDataID
WHERE ed.EDFType = 2 AND ed.Value <> '';

ComputerID is the durable identifier the wizard uses below to make a second import exact — keep it in the export.

Export to CSV, reshape to organization,site, and feed Recipe 1.

Option B — REST API

Automate’s REST API lives at https://<your-automate>/cwa/api/v1, authenticated by POST /apitoken with an Automate username and password (and a two-factor code where enforced).

TOKEN=$(curl -sf -X POST "https://$AUTOMATE/cwa/api/v1/apitoken" \
  -H 'Content-Type: application/json' \
  -d "{\"UserName\":\"$USER\",\"Password\":\"$PASS\"}" | jq -r .AccessToken)

curl -sf -H "Authorization: Bearer $TOKEN" \
  "https://$AUTOMATE/cwa/api/v1/Clients?pageSize=1000" | jq -r '.[] | [.Id,.Name] | @tsv'
curl -sf -H "Authorization: Bearer $TOKEN" \
  "https://$AUTOMATE/cwa/api/v1/Computers?pageSize=1000" \
  | jq -r '.[] | [.Client.Name, .Location.Name, .ComputerName, .OperatingSystemName, .LastContact] | @tsv'

This is your best licence audit in years

Automate estates accumulate stale computer records more than any other RMM — agents on decommissioned hardware, duplicates from re-imaged machines, and Deleted Clients leftovers. Sort by days_stale and expect 10–20% of the list to be fictional. None of it should migrate.

---

Phase 3 — Deploy the Breeze Agent with an Automate Script

1. Create a script. In the Automate Control Center: Automation → Scripts → New Script, script type Computer Script. You need exactly one function — a Script Execute / Shell step that runs PowerShell as SYSTEM (LTService already runs as SYSTEM, so no elevation is needed).

2. Use a script parameter for the key. Define a @breezekey@ script parameter and pass the per-location enrollment key from Recipe 2 when scheduling. Alternatively store the key in a location-level EDF and read it with @edf(...)@ so one script serves every client.

3. Body: the Windows PowerShell payload from Recipe 3. Keep the agent.yaml existence check — it is what makes the scheduled re-runs safe.

   Caution

   Write the payload to a .ps1 file and invoke it, rather than pasting a long inline one-liner. Automate’s script-step escaping mangles quoting in long inline PowerShell, and the failure mode is a silent no-op that looks like a successful run.

4. Add AV/EDR exclusions in both directions before the push — see Antivirus Exceptions.

5. Schedule against a group, daily. Create an auto-join group for the target client and schedule the script daily for the length of your rollout window. This picks up machines that were offline, and — importantly for Automate estates — retries against machines where LTService is wedged and recovers on its next check-in.

---

Scripts: Plan to Re-author

Automate scripts are step lists stored in the database and exported as proprietary XML. There is no converter, and building one is not a good use of the migration budget.

The practical approach:

1. Rank by actual use. Query what has actually run:

   SELECT s.ScriptName, COUNT(*) AS runs, MAX(sl.DateRan) AS last_run
   FROM scriptlogs sl JOIN scripts s ON s.ScriptId = sl.ScriptId
   WHERE sl.DateRan > DATE_SUB(NOW(), INTERVAL 12 MONTH)
   GROUP BY s.ScriptName ORDER BY runs DESC;

2. Delete the tail. Anything with zero runs in 12 months does not migrate. On a typical Automate estate this removes 70–85% of the library.

3. Check the Breeze system library (GET /scripts/system-library) before re-authoring anything. Disk cleanup, service restart, printer spooler, profile cleanup, reboot-required checks — the standard Automate toolkit is largely already there.

4. Re-author what remains as plain PowerShell or bash. Scripts whose steps were Shell, Execute Script, or File Download translate almost mechanically; scripts built from If/Then step logic against Automate’s own database do not translate at all and should be reconsidered rather than reproduced.

5. Bulk-load with Recipe 6, availability: "partner".

---

Monitors

Automate has two kinds and neither ports:

• Internal monitors are SQL queries against the Automate database. They have no meaning outside Automate. Re-express the intent as Breeze monitors and alert rules.
• Remote monitors are agent-side checks (service state, performance counter, event log, drive space). These map well onto Breeze’s equivalents — service monitoring, event log forwarding, and disk thresholds.

Rank by alert volume over the last 90 days and rebuild the top of the list partner-wide. Automate estates typically carry hundreds of monitors of which a dozen generate every ticket that mattered.

---

EDFs → Custom Fields

Automate EDFs (Extra Data Fields) exist at computer, location, and client scope. Only computer-scope EDFs (EDFType = 2 in the query above) map onto Breeze custom fields — they become partner-wide field definitions, since Automate has no per-organization computer scope narrower than the whole install.

Location- and client-scope EDFs are out of scope for the importer. There is no Breeze custom-field owner that maps to “one location” or “one client” more precisely than an organization, and guessing wrong here means re-typing every value later. Re-home that data as organization-level fields by hand, or leave it in your PSA if it is already tracked there — do not force it through the bulk importer.

Use the Import from another RMM wizard (Settings → Custom Fields, or the Devices page) for the computer-scope fields:

1. Export computer-scope EDFs with the SQL query above (or the REST equivalent) and confirm which ExtraFieldIDs are actually populated.
2. Open the wizard, choose ConnectWise Automate, and import the definitions with owner All organizations.
3. On the values step, map ComputerID to Source device ID (and hostname as a fallback identifier) and each EDF column to the matching custom field.
4. ComputerID is the durable identifier Custom Fields records on this first run — map it even when hostname alone would resolve most rows, so a later re-import after more devices enroll resolves exactly rather than by hostname guess.

A row the wizard can’t resolve to exactly one device is reported, never guessed at. Re-run after each enrollment wave; an already-applied value is left alone by default.

---

Phase 6 — Decommission LTService

Only after Recipe 4 is clean for that client.

1. Disable alerting — remove the client’s computers from monitor targets. Leave the agent installed.

2. Wait one full patch cycle.

3. Uninstall via Automate. Use the built-in Agent Uninstall script, or run ConnectWise’s Agent_Uninstall.exe from the LTSVC directory:

   $u = "$env:windir\LTSvc\Agent_Uninstall.exe"
   if (Test-Path $u) { Start-Process $u -Wait }

   Automate agents are notoriously persistent. If the standard uninstaller leaves remnants, ConnectWise’s own LabTechUninstaller/Agent_Uninstall cleanup routine removes the LTService and LTSvcMon services, %windir%\LTSvc, and the HKLM\SOFTWARE\LabTech keys.

4. Verify from Breeze. Recipe 5 — Breeze Management Posture fingerprints both ConnectWise Automate and ScreenConnect independently, so it will tell you if the remote-access component survived the RMM uninstall. That distinction matters: leftover ScreenConnect is an unmanaged remote-access path into your customers’ networks.

5. Delete the client in Automate and reduce your agent count.

Caution

Automate and ScreenConnect (ConnectWise Control) are separately installed. Uninstalling the Automate agent does not remove ScreenConnect. Check Management Posture for both and remove them deliberately — an orphaned ScreenConnect instance you no longer monitor is a standing security exposure.