Leaving N-central: migrating devices, Automation Manager policies and service templates without losing an endpoint

An N-central migration off the platform takes roughly four weeks for a typical small MSP estate: one week to inventory and export, two weeks of overlapping agents, and a final week to remove N-central and confirm nothing was dropped. The data that matters, device lists, customer and site structure, Automation Manager policies, scripts and custom properties, can all be exported. What cannot be exported is the behaviour baked into service templates, and that is where endpoints quietly go unmonitored.

This guide covers leaving N-able entirely. Here is the plan, object by object.

This is not the same as moving N-central to Azure or hosted

Search for N-central migration and most results are N-able's own documentation about moving an on-premises N-central server to Azure, to N-able's hosted service, or about switching antivirus to AV Defender. Those are migrations within N-able: the agents stay, the templates stay, the licence stays, and only the server underneath changes.

Leaving N-central is a different job. Every agent comes off, every policy is rebuilt somewhere else, and the contract has to end on a date you control. If you are moving your server, follow N-able's guidance. If you are moving your business, read on.

What you can export from N-central

N-central is generous with exports if you know where to look. Take everything before you touch a single agent, because once the licence ends so does your access.

• Device lists. Export from the All Devices view to CSV with customer, site, device class, OS, last check-in and agent version columns. Skip this and you have no baseline to reconcile against at the end.
• Customer and site hierarchy. N-central nests service organisation, customer and site. Export the customer list and record the site under each, because most target platforms flatten this into client and location, and you need to decide the mapping before devices arrive.
• Automation Manager policies. Each policy exports as an .amp file. Keep them, but treat them as a specification rather than something you will import: .amp is N-able's own format and other platforms will not run it. Open each one and write down what it actually does.
• Scripts. Download PowerShell, batch and VBScript items from the script repository. These are the most portable thing you own. For the general approach, our guide to exporting RMM scripts before you cancel applies here too.
• Service templates. Screenshot or document every template: which services it applies, thresholds, scan intervals and which device classes it targets. There is no clean export of their logic.
• Rules and filters. Rules decide which devices get which templates and policies, driven by filters. Document every filter's criteria, because that targeting logic is the real shape of your monitoring.
• Custom properties. Export customer and device custom properties. They often hold contract tiers, backup flags or warranty dates that nobody remembers storing there.

What does not transfer cleanly

Monitoring thresholds tied to service templates

N-central monitoring lives in service templates applied through rules, so thresholds are rarely set on a device directly. Exporting the device list tells you nothing about what was being watched. Rebuild thresholds as policies on the new platform, then compare alert behaviour during the overlap.

Take Control and EDR or AV Defender dependencies

Take Control remote access, N-able's EDR and AV Defender are tied to the N-central agent and licence. Remove the agent and they go with it, sometimes leaving a machine with no antivirus at all. Plan replacement security first, deploy it, confirm it is reporting, and only then uninstall the N-able components. Remote access is the same: your technicians need a working alternative before Take Control disappears.

Windows probe roles

Probes handle network discovery, agentless SNMP monitoring, WMI checks and pushing agents to new machines. Printers, switches and firewalls monitored only through a probe have no agent to replace. List every probe, what it discovers and what it monitors, and make sure the target platform has an equivalent network discovery method before the probe is removed.

The checklist: N-central object, export method, target equivalent

Removing the N-central agent and deploying the new one

The cleanest route uses N-central itself to do the work. Push the new platform's installer as an N-central script or Automation Manager policy to each customer's devices, so every machine that N-central can reach gets the new agent without a site visit. Then run both agents together while you check the new one is reporting correctly. Our piece on running two RMM agents at once covers how to keep the overlap safe.

Once the new agent is confirmed, use another N-central script to uninstall the Windows agent, Take Control and any N-able security components, in that order of dependency. Uninstall the agent last on any machine where it is the only thing running the script. Devices that were offline throughout need chasing manually, which is why the reconciliation step exists.

Contract and term timing

N-central is commonly sold on annual or multi-year terms with minimum device commitments, so the technical plan has to fit the contract, not the other way round. Find your renewal date and notice period before you start. Begin the migration early enough that the overlap finishes before renewal, but not so early that you pay for both platforms for months. Our guide to N-able pricing and minimums explains what typically sits inside those terms.

A migration finished a week after auto-renewal is a migration that costs another year.

A week 0 to week 4 timeline

1. Week 0: inventory and decisions. Confirm contract notice dates, export everything above, map customers to clients and choose replacement security and remote access.
2. Week 1: build. Recreate monitoring policies from service template notes, import scripts, rebuild automations from .amp descriptions and set up network discovery for probe-only devices.
3. Week 2: deploy and overlap. Push the new agent through N-central, starting with your internal machines and one friendly customer, then the rest. Deploy replacement security.
4. Week 3: compare. Check alert parity between platforms, reconcile device counts per customer against the week 0 export and chase missing machines.
5. Week 4: remove. Uninstall N-able components by script, decommission probes, give final notice and keep the exports archived.

Common failure points

• Offline laptops. Machines that never check in during the overlap keep the old agent and miss the new one. Reconcile by name, not by count.
• Security gaps. Removing AV Defender before the replacement reports leaves endpoints unprotected, often without anyone noticing.
• Forgotten probe devices. Switches and printers disappear from monitoring silently because nothing was ever installed on them.
• Templates rebuilt from memory. Thresholds drift, alerts change and the first sign is a client noticing an outage before you do.
• Late notice. The contract renews while the overlap is still running.

Where this fits with Helios

Helios is one possible target: an RMM and PSA in one product, with monitoring, patching, Microsoft 365 and Defender monitoring, backup monitoring, remote access and a helpdesk together, which reduces the number of pieces to replace when Take Control and the N-central agent come off. It is priced by fleet size rather than per technician, with every feature on every plan, and the published pricing lets you check costs before you give notice. Most of this plan is discipline rather than tooling, though: the exports, the documentation and the reconciliation are yours to do whichever platform you choose.

Common questions about N-central migration

Can I import N-central .amp files into another RMM?

No mainstream RMM outside N-able runs Automation Manager .amp files directly, because the format is specific to N-able's tooling. Treat each .amp file as documentation: open it, record what it checks and changes, and rebuild that logic as PowerShell or as the target platform's automation. Any embedded scripts can usually be extracted and reused.

How long should both agents run during an N-central exit?

Running the N-central agent and the new agent together for about two weeks gives enough time to catch devices that only come online occasionally and to compare alerts between platforms. A shorter overlap risks missing laptops, while a much longer one mostly adds cost and the confusion of duplicate alerts.

Does leaving N-central remove AV Defender automatically?

Uninstalling the N-central agent does not reliably remove every N-able security component, and removing them without a replacement leaves machines unprotected. Deploy and verify replacement antivirus or EDR first, then uninstall AV Defender or N-able EDR deliberately by script, and confirm each device reports healthy protection afterwards.

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