How to Migrate from Datto to Aerie OS: Complete Migration Guide

Why Migrate from Datto to Aerie OS?

Datto RMM is a reliable monitoring and remote support platform. It's fast, stable, and widely used across the MSP community. But Datto is just the monitoring piece. Most Datto users also manage:

• PSA (billing, tickets, contracts): Typically ConnectWise, Syncro, or a similar platform
• CRM (sales pipeline, client communications): Often Salesforce or a basic spreadsheet
• Documentation: Separate platform like Hudu or SharePoint
• Backup and disaster recovery: Often another vendor entirely
• Password management: Yet another tool

This fragmentation creates problems:

• Tool fatigue: You're managing 4–6 separate platforms, each with logins, interfaces, and integrations.
• Data silos: Your monitoring data doesn't talk to your billing system. Your RMM alerts don't create tickets automatically without complex integrations.
• Cost accumulation: Datto (per device) + PSA (per technician) + CRM (per user) + Backup (per GB) adds up quickly.
• Integration complexity: Zapier rules, webhooks, and custom scripts cobbled together to make tools communicate.
• Steep learning curve: Each new team member must learn 4–6 interfaces. Onboarding takes weeks.

Aerie OS consolidates all of this. One platform. One interface. One cost structure. Unified data. This guide walks you through migrating from Datto to Aerie — honestly and practically.

---

Pre-Migration: What You Need to Know

1. What Datto Data Migrates and What Doesn't

Migrates to Aerie RMM (automated):

• Device inventory and asset registry
• Monitoring and alert configurations
• Custom fields on devices
• RMM agent logs and deployment history
• Remote support and ticket links (from Datto's ticketing)
• Patch management settings and deployment schedules

Requires manual setup:

• Custom monitoring scripts (need to be revalidated in Aerie)
• Alert routing rules and escalation policies (recreate in Aerie's alert rules)
• API integrations (Datto API rules must be migrated to Aerie API or webhooks)
• Custom reports (rebuild in Aerie's reporting interface)
• Third-party integrations (Zapier, webhooks, API calls — reconfigure for Aerie)

Does not migrate (plan separately):

• PSA/billing data (if you use ConnectWise, Syncro, or similar PSA platforms, migrate separately to Aerie PSA)
• CRM data (if you use Salesforce, migrate manually or use a third-party sync tool)
• Backup and disaster recovery data (keep your backup platform; Aerie doesn't replace backup — it integrates with it)
• Documentation (if you use Hudu, migrate to Aerie Wiki or keep Hudu and integrate)

2. Understanding Datto vs. Aerie RMM Differences

Datto RMM is purpose-built for monitoring and remote support. It's excellent at what it does: agent deployment, system monitoring, patch management, remote sessions.

Aerie RMM does all of that, but as part of a broader platform. Key differences:

Feature	Datto RMM	Aerie RMM
Monitoring & Alerts	Fast, lightweight, highly configurable	Full-featured, integrated with PSA/CRM
Remote Support	Excellent; dedicated tool	Built in; works with Aerie ticketing
Patch Management	Granular, scheduled, tested	Built in; coordinated with service windows
Custom Scripts	PowerShell, VBScript, Bash	Python, PowerShell, Bash, custom workflows
Integrations	API-first; hundreds of webhooks	API-first; native Slack/Teams/Zapier
Dashboards	RMM-focused monitoring views	Unified business dashboard (RMM + PSA + CRM)
Compliance	Monitoring and alerting	Integrated compliance, evidence, audit trails

Bottom line: You'll gain PSA/CRM integration and unified dashboards. You may notice some feature gaps in very specialised monitoring areas — but Aerie's RMM is solid and getting better.

3. Licence and Subscription Considerations

Current Datto cost (example, small MSP with ~100 devices, 5 techs):

• Datto RMM: £200–400 per month (platform + per-device fees)
• Separate PSA: £100–150 per technician per month (£500–750/month)
• Separate CRM: £20–50 per user per month
• Backup platform: varies significantly by data volume and vendor
• Integrations (Zapier, custom API): £100+ per month
• Total: £1,000–1,500+ per month for a small MSP

Aerie OS cost (example):

• All-in-one: £150–200 per technician per month (includes RMM for all your devices, PSA, CRM, compliance, documentation)
• Total: £300–400 per month for the same small MSP

During migration:

• You'll run Datto and Aerie agents simultaneously for 1–2 weeks. This means paying for both.
• Budget for 2–3 weeks of dual agent costs. Then decommission Datto.

After cutover:

• Cancel Datto (check your contract for cancellation terms — some have 30-day notice requirements)
• Cancel or keep separate CRM/backup/documentation if you prefer (Aerie integrates with them, so you don't have to migrate everything)

---

Migration Timeline: What to Expect

Realistic timelines depend on your MSP size and infrastructure complexity:

For a small MSP (1–5 techs, 50–150 monitored devices):

• Planning and Aerie setup: 3–5 days (admin configuration, alert rules, custom fields)
• Agent deployment (phased): 1–2 weeks (small groups of clients first, validate monitoring, then full rollout)
• Parallel running: 1 week (both agents monitoring, validate data completeness)
• Cutover and decommission: 1 day (disable Datto agents, final validation, confirm Aerie coverage)
• Post-migration tuning: 1–2 weeks (alert threshold adjustments, script validation, team retraining)
• Total: 3–5 weeks

For a mid-market MSP (10–30 techs, 500–1,500 devices):

• Planning and Aerie setup: 1–2 weeks (admin setup, alert configuration, script audit)
• Agent deployment (phased): 3–4 weeks (deploy to critical clients first, then roll out by geography or business unit)
• Parallel running: 2–3 weeks (validation, performance tuning, team feedback)
• Cutover and decommission: 2–3 days (staged cutover by group, final validation)
• Post-migration tuning: 3–4 weeks (performance optimisation, custom script refinement, integration validation)
• Total: 8–13 weeks

For a large MSP (50+ techs, 3,000+ devices):

• Planning and Aerie setup: 3–4 weeks (full audit, detailed configuration plan, stakeholder alignment)
• Agent deployment (phased): 6–8 weeks (deploy by department, geography, or customer tier)
• Parallel running: 3–4 weeks (extensive validation, staged cutover by region)
• Cutover and decommission: 3–5 days (multi-region rollout, centralised monitoring throughout)
• Post-migration tuning: 6–8 weeks (performance optimisation, integration refinement, advanced feature adoption)
• Total: 18–28 weeks

Key assumptions:

• Your Datto devices are in good shape (no orphaned agents, clean inventory).
• You have one person (or team) dedicated to migration.
• Your team is willing to adopt new workflows (Aerie is different from Datto — in good ways, but different).

If your Datto inventory is messy or you're understaffed, add 25–50% to these estimates.

---

Step-by-Step Migration Process

Phase 1: Planning and Aerie Setup (Weeks 1–2)

1.1 Audit Your Datto Infrastructure

Before deploying any Aerie agents, understand what you're monitoring:

Run these checks in Datto:

• How many devices are actively monitored? (Include servers, workstations, network devices)
• How many devices are archived or inactive? (Decide whether to migrate these)
• How many custom alert rules do you use? (List them — you'll recreate these in Aerie)
• How many custom monitoring scripts are deployed? (Document their purpose)
• How many device groups or client hierarchies exist? (You'll mirror this in Aerie)
• How many integrations send data to/from Datto? (Zapier, webhooks, API calls, etc.)

Output: Create a spreadsheet:

Item	Count	Notes
Active monitored devices
Archived devices
Custom alert rules
Custom monitoring scripts
Device groups
Third-party integrations
Critical monitoring dependencies

1.2 Plan Your Aerie RMM Configuration

Aerie's structure differs from Datto. Plan your configuration:

• Devices: Datto uses flat or hierarchical device lists. Aerie uses hierarchical client/site/device structure. Plan your Aerie device hierarchy to match your business.
• Alert rules: Datto alert rules are device-centric. Aerie allows client-level, site-level, and device-level rules. Decide which level of granularity you need.
• Custom fields: List your custom device fields in Datto. Recreate only the ones you actually use in Aerie (don't migrate legacy fields).
• User roles and permissions: Plan who needs access to what in Aerie. Granular permissions differ from Datto's simpler model.

1.3 Document Your Custom Monitoring Scripts and Integrations

For each custom script or integration:

Custom scripts:

• What does it monitor?
• How frequently does it run?
• What language (PowerShell, VBScript, Bash)?
• Does it do anything besides monitoring (e.g., automatically remediate issues)?

Integrations:

• What system does it connect to? (Slack, email, ticketing, etc.)
• What triggers the integration? (Alert fired, SLA breached, etc.)
• What action does it take? (Send notification, create ticket, etc.)

Example:

• Script: Custom CPU temperature monitor for server rooms (PowerShell, runs every 15 min)
• Integration: Critical alert → Slack #soc channel + create ConnectWise ticket

You'll rebuild these in Aerie.

1.4 Get Aerie Configured and Ready

Work with Aerie Support to set up your tenant:

• Create your client structure (companies, sites, device groups)
• Set up alert rules (start with critical ones; you can add more later)
• Configure integrations (Slack, email, ticketing if applicable)
• Test the setup with a small pilot group

---

Phase 2: Phased Agent Deployment (Weeks 3–6)

2.1 Select a Pilot Group

Choose 1–2 small clients (20–50 devices) to deploy Aerie agents first:

• Ideally a cooperative client who won't panic if something goes slightly wrong
• Mix of server and workstation devices
• Must have good network connectivity (no wonky firewall rules)

2.2 Deploy Aerie Agents to Pilot Group

For Windows devices:

• Download Aerie agent installer
• Deploy via Group Policy, Intune, or manual installation on each machine
• Agents should check in and appear in Aerie within 5–10 minutes
• Verify monitoring data is flowing

For macOS/Linux:

• Deploy Aerie agent via package managers or manual install
• Same check-in and verification process

Typical results: Most agent deployments succeed on first attempt. Failures are usually due to:

• Firewall blocking outbound connections (fix: whitelist Aerie IP ranges)
• Incorrect client credentials (re-run installer with correct tenant ID)
• Agent doesn't have permission to install (needs admin/root)

2.3 Validate Monitoring in Aerie

Once agents check in:

• ✅ Device appears in Aerie inventory
• ✅ Hardware data is populated (CPU, RAM, storage, etc.)
• ✅ Network data is visible (IP address, gateway, DNS)
• ✅ Performance metrics are flowing (CPU, memory, disk, network)
• ✅ Security baseline is captured (OS version, security software, patches)

If anything is missing, check Aerie documentation or contact support. Most issues resolve in under 24 hours.

2.4 Migrate Custom Monitoring Scripts and Alert Rules to Pilot

For your pilot group:

• Recreate critical alert rules in Aerie (if any devices from the pilot had custom rules in Datto)
• Deploy any critical custom monitoring scripts to the pilot devices
• Test that alerts fire correctly

2.5 Run Pilot in Parallel (1 Week)

Keep Datto agents running on the pilot group for 1 week. This gives you:

• A week to validate Aerie monitoring is accurate and reliable
• Time for your team to get comfortable with Aerie's interface
• Confidence that nothing is being missed

Run these checks daily:

• Are all pilot devices reporting in Aerie?
• Are alerts firing correctly?
• Is the data quality matching Datto's data?
• Any performance issues (high CPU, memory leaks)?

If there are issues, pause the rollout and fix them.

2.6 Full Rollout (Phased by Client or Geography)

Once the pilot is stable, deploy to the rest of your clients in waves:

• Wave 2: Next 100–200 devices (1–2 weeks)
• Wave 3: Next 300–500 devices (1–2 weeks)
• Wave 4: Remaining devices (1–2 weeks)

Space out waves so you can support issues without being overwhelmed. Each wave follows the same pattern:

1. Deploy agents
2. Validate check-in and data flow
3. Migrate custom scripts and alert rules for that wave
4. Run parallel monitoring for 3–5 days
5. Confirm everything is stable, then move to next wave

---

Phase 3: Parallel Running (Weeks 6–8)

3.1 Run Both Datto and Aerie Simultaneously

During parallel running (typically 1–2 weeks):

• Datto agents continue to monitor and send alerts
• Aerie agents also monitor and send alerts
• Your team uses Aerie for all new incident response
• Any critical issues still get escalated via Datto (as backup)

What you're validating:

• Aerie is catching all critical issues that Datto would catch
• Alert routing and escalation work correctly
• Custom scripts and integrations are firing as expected
• Team is comfortable troubleshooting from Aerie

3.2 Data Completeness Check

Weekly, compare Datto and Aerie:

• Device count: Same number of devices in both systems?
• Alert frequency: Similar number of critical alerts in both systems?
• Performance data: CPU, memory, disk metrics match between systems?
• Agent health: Any devices that have gone dark in either system?

Run these checks manually or via reports. Fix any discrepancies.

3.3 Gather Team Feedback

Your team will surface issues:

• "The alert rule threshold is too low; I'm drowning in alerts." → Tune thresholds
• "How do I do remote support in Aerie?" → Documentation or training gap
• "This Datto script doesn't work in Aerie." → Rewrite or find alternative

Document everything. Address critical issues before cutover.

---

Phase 4: Cutover and Datto Decommission (Week 9)

4.1 Plan Your Cutover Day

Choose a quiet day (Tuesday–Thursday, avoid month-end). Cutover day is straightforward because you've been running in parallel:

Time	Task	Owner
9:00am	Announce cutover to team	Manager
9:15am	Final validation (all devices reporting in Aerie)	Tech Lead
9:30am	Disable Datto agent auto-deployment (block agent updates)	Tech Lead
10:00am	Stop all Datto agents (via group policy or manual command)	Tech Team
10:30am	Verify no stray Datto alerts coming in	Tech Lead
11:00am	Go live: Aerie is now your primary monitoring system	All
3:00pm	Final validation (all alerts, reports, workflows functional)	Manager
5:00pm	Confirm Datto can be decommissioned (no dependencies remain)	Tech Lead

4.2 Final Validation Checklist

Before declaring cutover complete:

• ✅ All monitored devices are reporting in Aerie
• ✅ All critical alert rules are active and firing
• ✅ Remote support functionality works
• ✅ Custom monitoring scripts are running
• ✅ Integrations (Slack, ticketing, etc.) are functional
• ✅ Dashboards and reports are accessible
• ✅ Team can access their assigned devices/groups
• ✅ No critical bugs or access issues

If any item fails, extend parallel running and investigate.

4.3 Datto Decommission Plan

Once cutover is complete and you're confident Aerie is stable (typically 3–7 days post-cutover):

1. Uninstall Datto agents from all devices (can be done remotely via Aerie or group policy)
2. Cancel Datto RMM subscription (check your contract for notice period)
3. Export Datto historical data as backup (optional but recommended)
4. Update internal documentation to reference Aerie (runbooks, knowledge base, etc.)
5. Archive or remove Datto from your team's bookmarks (avoid confusion)

---

Phase 5: Post-Cutover Stabilisation (Weeks 10–12)

5.1 Monitor Closely for the First Week

In the first 7 days post-cutover, expect edge cases:

• Devices that went offline during cutover and haven't re-connected yet
• Custom scripts that have subtle issues (often dependent on Datto API)
• Team members asking "how do I do X in Aerie?"

Establish a daily standup:

• 15-minute call each morning
• Discuss blockers, questions, bugs
• Escalate to Aerie Support if needed

5.2 Tune and Optimise

After the first week:

• Review alert thresholds: Are you getting too many false positives?
• Check custom scripts: Are all critical scripts running? Do any need adjustment?
• Audit dashboards: Does your main dashboard show what you care about?
• Review permissions: Are team members seeing what they should (and nothing they shouldn't)?

Make small tweaks. Document everything.

5.3 Adopt Aerie's Advanced Features

Now that core monitoring is stable, explore what Aerie adds:

• Integrated ticketing: Aerie alerts can auto-create tickets in your PSA
• Client portal: Clients can see their device status (optional)
• Compliance modules: Run automated compliance checks (CIS, HIPAA, SOC 2 baselines)
• Advanced reporting: Combine RMM data with PSA/CRM data for business insights

---

Common Gotchas and How to Avoid Them

1. Agent Deployment Fails on a Subset of Devices

What happens: Most agents deploy fine, but a handful of devices won't install Aerie agent. You're scratching your head.

Prevention:

• Test agent deployment in your own lab first.
• Check firewall rules; Aerie needs outbound HTTPS access to Aerie servers.
• Deploy to a test group of 5–10 devices before rolling out to all clients.
• Common failure reasons: corporate proxy, firewall blocking, missing admin rights.

2. Alert Rule Threshold Mismatch

What happens: You migrate alert rules from Datto, but Aerie's threshold logic is different. Suddenly you're drowning in false-positive alerts (or missing real issues).

Prevention:

• Don't just copy thresholds; understand them.
• Set conservative thresholds initially (fewer alerts, but catch real issues).
• Monitor alert volume for 3–5 days and tune based on what you see.
• Use Aerie's alert tuning tools to automatically suggest optimal thresholds.

3. Custom Script Incompatibility

What happens: You had a PowerShell script in Datto that monitors something specific. You move it to Aerie, but it breaks because it depended on Datto's API or file paths.

Prevention:

• Audit all custom scripts before migration.
• Test each script in Aerie's environment (not just copy-paste).
• Document what each script does and why. Remove obsolete scripts.
• Aerie's custom script interface is similar to Datto's, but not identical.

4. Device Visibility and Permissions Issues

What happens: After cutover, a technician says "I can't see my client's devices." Turns out you didn't set up permissions correctly in Aerie.

Prevention:

• Plan your permission model before cutover.
• Aerie uses role-based access control (RBAC). Map Datto permissions to Aerie roles.
• Test permissions with a test user before cutover.
• Document the permission model for future hires.

5. Parallel Running Confusion

What happens: Your team gets confused about which system is "live." They fix something in Datto but forget to fix it in Aerie. Data inconsistency nightmare.

Prevention:

• Communicate clearly: "During parallel running, Aerie is the source of truth. Use Aerie for incident response. Datto is backup only."
• Use Aerie exclusively for new work. Don't create tickets in both systems.
• Limit parallel running to 1–2 weeks. The longer you run dual systems, the more confusion.

6. Forgetting Integration Reconfiguration

What happens: You had a Zapier rule that sent Datto alerts to Slack. You forget to update it for Aerie. Suddenly your team stops getting alerts.

Prevention:

• Create a checklist of all integrations (Slack, email, ticketing, etc.).
• For each integration, test it in Aerie before cutover.
• Have someone responsible for each integration (DRI).
• Do a dry run of a critical alert flow 1 day before cutover.

---

Post-Migration Checklist

Week 1 Post-Cutover

• ✅ All devices reporting in Aerie
• ✅ Alert rules active and firing
• ✅ Team is comfortable with Aerie's interface
• ✅ Datto agents are stopping/uninstalling cleanly
• ✅ No critical issues or access blockers

Week 2–3 Post-Cutover

• ✅ All custom monitoring scripts validated
• ✅ Integrations (Slack, ticketing, etc.) confirmed working
• ✅ Alert thresholds tuned based on real-world data
• ✅ Reports and dashboards validated
• ✅ Team is using Aerie for all incident response

Week 4+ Post-Cutover

• ✅ Datto agents fully uninstalled from all devices
• ✅ Datto RMM subscription cancelled
• ✅ Team is proficient with Aerie (minimal questions)
• ✅ Advanced features explored (integrated ticketing, compliance, reporting)
• ✅ Monitoring is stable; false-positive rate acceptable
• ✅ Historical Datto data archived and backed up

---

Additional Considerations: PSA and CRM Migration

If you're using a separate PSA (ConnectWise, Syncro, etc.) or CRM (Salesforce), you now have options:

Option 1: Migrate to Aerie PSA/CRM

• Aerie includes PSA and CRM in its platform.
• Integrate with your Aerie RMM for unified monitoring + billing + CRM.
• Reduces tool fragmentation. But requires separate migration effort.

Option 2: Keep Your Existing PSA/CRM

• Aerie RMM integrates with ConnectWise, Syncro, Salesforce, etc.
• Aerie alerts automatically create tickets in your PSA (native integration).
• Keep what works; just replace the RMM piece.

Option 3: Hybrid Approach

• Migrate RMM to Aerie (what you're doing now).
• Migrate PSA to Aerie (benefit from unified platform).
• Keep CRM separate if you have a Salesforce-based workflow (Aerie integrates with Salesforce).

---

Questions? Support Resources

Aerie Migration Support:

• Schedule a migration consultation: hello@aerie-tech.co.uk
• Create a support ticket from your Aerie dashboard once you're onboarded

Your team:

• Designate one "Aerie champion" to be the expert.
• Have them attend Aerie training first, then train others.
• Create an internal Aerie troubleshooting channel (Slack/Teams).

---

Final Thoughts

Migrating from Datto to Aerie is a significant operational shift, but it's a strategic investment. You're not just replacing an RMM — you're unifying your entire MSP platform.

The timelines and gotchas in this guide are based on real MSP experiences. Your timeline may vary based on:

• Number of devices and clients
• Complexity of custom scripts and integrations
• Your team's capacity and willingness to change
• Data quality and infrastructure readiness

But now you have a roadmap. Follow it, anticipate the gotchas, and you'll transition smoothly.

Ready to make the move? Reach out to Aerie Support to start your Datto migration conversation.