NinjaOne Backup — Parallel Run: Monitoring Both Platforms During Transition
Audience: T2 Use when: A site has NinjaOne Backup deployed but MSP360 has not yet been decommissioned — both platforms are running simultaneously.
Running both platforms is a deliberate transitional state, not a failure condition. This page covers how to manage and monitor both during the overlap.
When Parallel Running Is Appropriate
DTC runs both platforms simultaneously at a site when:
- NinjaOne has been deployed and the first backup has completed
- The migration verification checklist isn't fully signed off yet
- There's uncertainty about whether NinjaOne cloud sync is fully working
- The client site has a near-term schedule for MSP360 data review before expiring old backups
Parallel running adds cost (two backup agents, two cloud destinations) and risk (VSS provider conflicts). Keep it short — target no more than 2 weeks before decommissioning MSP360.
Monitoring During Parallel Run
Daily check — both platforms:
| Platform | What to Check | Acceptable State |
|---|---|---|
| NinjaOne | Last backup result per device | Success, local + cloud both completing |
| MSP360 | Job status in portal | Success or disabled (not failing) |
If MSP360 jobs are still running alongside NinjaOne: watch for VSS conflicts. Two backup agents both requesting VSS snapshots at the same time on the same machine will cause one or both to fail.
Preventing VSS Conflicts During Parallel Run
Stagger backup windows:
- MSP360: change schedule to 11:00 PM
- NinjaOne: keep at midnight (12:00 AM)
- This gives MSP360 time to complete its snapshot before NinjaOne starts
# After both jobs run, check VSS writer state next morning
vssadmin list writers
# All writers should show [1] Stable — if any are [6] Failed, there was a conflict
Alternatively — disable MSP360 jobs but leave agent installed: If you want MSP360 data preserved but don't want it running, disable the MSP360 backup plans without uninstalling the agent. This eliminates VSS conflict risk while preserving the ability to access old MSP360 data.
Monitoring NinjaOne Progress Toward Full Coverage
Track which devices have completed their first successful cloud backup:
- NinjaOne → org → Backup → Overview
- Look for devices still showing "In Progress" or no cloud revisions — these are still on their initial upload
- Devices with successful cloud revisions are ready for MSP360 decommission
# Cross-reference from the NAS — which device folders exist (at least one NinjaOne backup):
Get-ChildItem "\\NAS-HOSTNAME\backups\ninjaone" | Select Name, LastWriteTime | Sort-Object LastWriteTime -Descending
Common Issues During Parallel Run
| Issue | Cause | Fix |
|---|---|---|
| NinjaOne VSS errors after MSP360 ran first | MSP360 left VSS in a bad state | Stagger schedules; reboot to clear VSS |
| MSP360 jobs failing since NinjaOne was installed | NinjaOne VSS provider conflict | Same fix — stagger; or disable MSP360 jobs |
| Device shows two backup agents in Services | Both agents installed | Expected during parallel run — confirm Lockhart is running |
| NinjaOne cloud upload speed is slower than expected | Both platforms competing for bandwidth | Throttle MSP360 upload bandwidth in the portal settings |
Decision: When to Pull the Trigger on Decommission
Decommission MSP360 at a device when all of the following are true:
- At least 2 consecutive successful NinjaOne backups confirmed (local + cloud)
- Test restore from NinjaOne verified
- No VSS conflicts in the last 48 hours
- Old MSP360 cloud data retention has been decided (keep/expire)
When all devices at a site meet these criteria: execute the decommission procedure.