Replacing endpoint security across a small-business fleet is safest when it is treated as a controlled migration, not a simple uninstall-and-install task. This runbook explains how to inventory devices, prepare licensing and policies, pilot the new product, manage overlap and reboots, handle remote endpoints, verify protection, and retire the old console without creating blind spots.
Overview
An antivirus migration can affect more than malware scanning. Endpoint agents may provide web protection, firewall controls, exploit prevention, ransomware safeguards, device isolation, alerting, and centralized policy enforcement. Removing one product before its replacement is ready can leave a computer exposed; installing two products with overlapping real-time controls can create conflicts, performance issues, or confusing alerts.
The safest sequence is usually:
- Document the current environment and define the target state.
- Confirm licensing, operating-system support, and deployment methods.
- Prepare policies, exclusions, administrator access, and rollback files.
- Test the new protection with a small pilot group.
- Deploy in controlled waves while monitoring coverage and failures.
- Verify protection and reporting before retiring the old platform.
Keep the migration plan separate from incident response. If a device is showing signs of compromise, isolate and investigate it rather than using it as an ordinary deployment target. The Windows malware removal checklist provides a useful starting point for that situation.
Checklist by scenario
Before replacing protection across the fleet
- Build an inventory. Record device names, users, operating systems, ownership, location, last check-in time, current agent version, encryption status where relevant, and whether each device is online or remote.
- Separate special systems. Identify servers, shared computers, point-of-sale systems, development machines, virtual machines, and devices running line-of-business software. Do not assume a workstation policy is suitable for a server. Review the Windows Server antivirus guide before including servers in the project.
- Confirm the target design. Decide whether the replacement is traditional antivirus, an endpoint protection platform, or EDR for small business. Define which components will be enabled, who receives alerts, and how incidents will be escalated.
- Check licensing and identity. Confirm the number and type of seats, tenant or console ownership, administrator accounts, enrollment requirements, and any restrictions on operating systems or server use.
- Export what can be reused. Save current policies, exclusions, schedules, alert contacts, device groups, tamper-protection settings, and reports. Treat exclusions as review items, not as settings to copy automatically.
- Prepare recovery access. Keep local administrator or approved recovery credentials available, along with the vendor's supported removal utility and documentation. Store installers and recovery instructions somewhere accessible if the old console becomes unavailable.
For a pilot group
- Choose representative devices: at least one standard office computer, one remote device, one device with important business applications, and any higher-risk or technically unusual endpoint that can be tested safely.
- Schedule the pilot during a period when someone can respond to failed installations, required reboots, application conflicts, or unexpected alerts.
- Test normal work: sign-in, email, web access, file sharing, printing, VPN, line-of-business applications, and software updates.
- Confirm that the device appears in the new console, reports a recent check-in, receives policy changes, and shows the expected protection modules as active.
- Use a safe test method to validate alerting rather than real malware. The EICAR and alerting checklist explains how to test detection without using a live threat.
For staged production deployment
- Deploy in waves based on risk, location, or device group rather than attempting an uncontrolled fleet-wide push.
- Keep the existing protection active until the replacement is ready to take over, unless the vendors' supported migration process specifies another order.
- Allow for reboots when the new agent or removal utility requires them. Record devices that are offline, powered down, or waiting for user approval.
- Monitor installation success, last check-in time, protection status, policy assignment, alert delivery, CPU or memory concerns, and user-reported application problems.
- Pause the next wave if a repeatable failure appears. Investigate before increasing deployment scope.
What to double-check
Overlap and removal order: Many security products do not support two full real-time protection agents operating together. Follow the target vendor's migration instructions and use its supported removal or cleanup tool when required. Do not rely on a standard operating-system uninstall if the product leaves services, drivers, or tamper controls behind.
Policies and exclusions: Translate settings instead of copying them blindly. Product names, detection categories, path handling, and policy defaults can differ. Every exclusion should have an owner, a reason, and a review date. Broad exclusions can weaken ransomware protection and should receive particular scrutiny.
Remote devices: A remote laptop may not be connected to the corporate network or VPN when the change is launched. Use a deployment method that can reach it, define what happens if the device goes offline, and provide a support path that does not depend on the old agent remaining healthy. Avoid starting a removal step without a realistic way to deliver the replacement.
Identity and administration: Verify that administrators can sign in to the new console, that alert recipients are correct, and that least-privilege roles are assigned. For Microsoft 365 environments, review the relevant Defender for Business deployment guidance if that is the target platform.
Coverage evidence: A successful installer message is not proof of protection. Require a recent console check-in, active protection status, current policy assignment, and a test alert or other approved validation. Compare the completed device list with the original inventory, not just with the number of purchased licenses.
Rollback: Define in advance when to stop, how to restore the former product if supported, and how to protect devices that failed midway. Preserve the old installer, access details, and configuration exports until the new platform has completed its acceptance period.
Common mistakes
- Removing the old product first: This creates an avoidable protection gap, especially for devices that are offline or slow to receive the new deployment.
- Ignoring unsupported systems: Older operating systems, servers, virtual machines, and specialized appliances may need a different product, policy, or migration window.
- Copying every exclusion: Old exclusions may no longer be necessary or may be unsafe in the new product. Review them individually.
- Deploying to every device at once: A broad push makes it harder to distinguish a vendor issue from a local application conflict and increases support pressure.
- Counting licenses instead of devices: Purchased capacity does not prove that every endpoint is enrolled, checking in, and protected.
- Forgetting the old console: Leaving stale agents, duplicate devices, administrator accounts, or unused integrations can obscure coverage and create unnecessary access risk.
- Testing only installation: Verify prevention, alerting, policy delivery, and reporting. A quiet console may indicate success, but it may also indicate that devices are not communicating.
For broader planning, compare the capabilities and operational workload of antivirus and EDR in the antivirus versus EDR guide. Document the final standard in an endpoint policy, using the small-business antivirus policy template as a reference.
When to revisit
Review this migration checklist before each major renewal, vendor change, operating-system transition, merger, or fleet refresh. Revisit it before seasonal planning cycles and whenever the deployment tool, endpoint agent, console workflow, licensing model, or supported operating systems change.
After the migration, schedule a short post-change review. Compare the original inventory with the new console, investigate devices that have not checked in, remove stale records from the old platform, and confirm that alert routing still reaches the right people. Repeat the coverage check after staff changes, remote-work changes, and significant network or identity-management changes.
Practical next step: Create a migration worksheet with columns for device name, user, location, operating system, current agent, target policy, deployment wave, reboot required, new-console check-in, validation result, and rollback status. Do not close the project until every device is accounted for or has an owner and a documented follow-up date.
