What to Consider When Migrating RMMs

Over the last few quarters, we have seen a lot of MSP partners switching their RMM tools. This is not a decision to be made lightly, there are a lot of factors involved in a making a switch. To try and simplify this a bit, we’ve generated a list of items that should be considered when switching RMMs. ProVal believes there are a few core pillars of an RMM and what it is supposed to do. These items are: (in no particular order) Patching, Reporting/Auditing, Monitoring, Automation, and Remote Access.

Patching

Patching, specifically Windows/Microsoft patching, is a core element to most RMM software. Most systems have things broken into two parts. One is the schedule of when patches are installed and how reboots occur. The second system is which patches are approved for installation.

• Ensure the same functionality exists between both systems
  • Patch install policies (Timing of when patches are installed)
  • Reboot policies (Timing of how reboots occur on endpoints)
• Review current patch install and reboot policies, by client, for configuration in the new system
  • Note: This is a good time to work on overall patching strategy and get schedules standardized if possible.
• Review and ensure machine exceptions are maintained
• Review patch approval and denial status between the two systems and ensure they match
• Verify Windows 10 build upgrades are managed in the new system
• Verify Third Party Patching configuration if present in the current RMM and migrate to the new RMM where possible

Reporting/Auditing

Most, if not all, RMMs have some core functionality around gathering data from machines automatically and displaying that information for all to see. The MSP will need to review what is gathered in the current tool versus data in the new tool to ensure there is no loss of data or loss of visibility to the data required for the team.

• Review current scheduled reports
  • Review the content of these reports and ensure the new system has something similar
  • Match the schedules for the reports so there is minimal interruption in reporting for partners. Notify partners of the change so they are not surprised when a different report arrives.
•  Auditing
  • Work with the team to understand what tools they are using to audit various thing in environments. (Software lists, hardware lists, patching metrics, etc.)

Monitoring

There are certain critical functions of all RMMs that will carry over, things like Offline Server notifications. There are some that are very specific to the MSP or to their end clients that may need to be migrated to the new system. It’s important to find these items and setup a plan to verify similar monitoring happens between the old and new RMM.

• Review how the RMMs monitor scenarios and create parity between the two systems
• Develop methods to bridge gaps between the two systems. An example of this is some RMMs use Event Logs for most alerting, and some use information in the database.

Automation

Most RMM systems have Automation as a core function. Automation can mean many things. It can be an automated audit gathering data from endpoint. It may be a monitor that looks for an issue on a machine and remediates that issue. It could be a script performing a disk cleanup and ticketing based on the results from the cleanup.

• Audit the current system for scripting and ensure those items make it into the new system.
• Review the new system to bridge gaps that were present in the old system.
• Review machine groups / other machine organizational methods in the RMMs and understand their function.
  • Migrate the “automation” provided by these groups to the new RMM where necessary/possible.
• Overall System configuration
  • Branding
  •  Templates/Policies/Onboarding/Offboarding
  • Automatic application of monitoring, alerting, scripting, etc by configuring the new environment to do this for you

Remote Access

Another pillar of RMMs are their remote access functions. When automation does not suffice, a human will need to get involved. It should be easy and secure to connect to endpoints using the RMM. Many RMMs have their own proprietary tools, and some do not.

• Review current remote access configuration and considerations depending on what the tool can do
  • Deploying the remote access software (where applicable)
  • Configuring the centralized portal (where applicable)
  • Audit and review exceptions for sensitive machines. Ensure these configurations are still required or make it into the new RMM/Remote Access tool.
  • End user remote access to machines
    • If the current system allows for users to connect to their own devices remotely, it will be important to ensure that after the migration those functions are still available
  • Security Policies
    • Connection timeouts
    • Endpoint screen lockouts on disconnect or timeouts
    • Securing administrative consoles

Other Considerations

There is obviously a lot more to consider when transitioning RMMs beyond these functions. Above are just some of the core pillars of what an RMM does. Below we’ll outline some of the other items to keep in mind during the transition.

• Agent Migration

  • How to migrate the agents so they end up in a similarly structured way in the new system (Client/Location vs Machine groups vs sites, etc.)
  • How, technically, to do the deployment.
    • In many cases, using the current RMM to install the new RMM’s agents.

• User Permissions

  • All RMMs are going to have a unique approach to permissions in the environment. It is paramount to understand the differences between the two systems and ensure that the Principal of Least Privilege is followed in the new RMM.
  • Restricting access to certain information or machines and how to do that. Reviewing the current settings to ensure those are mapped to the new system. Especially in regulated industries like finance or healthcare.

• Integrations

  • Verify or assess what currently plugs into the RMM and if the new RMM has the same functionality
    • If an integration doesn’t exist in the new system, how does this item need to be handled moving forward?
  • PSA Sync
    • Does the RMM sync up with your PSA to sync tickets, configurations/assets, contacts, etc?

• Training

  • The MSP staff will require training on the new product. Who will train the staff and what content will they learn? (Likely a training program will need to be generated for each product switch.)

• Maintenance

  • Many RMMs require some form of maintenance each month. Ensuring someone (or the vendor) is responsible for maintenance is important.

• Other MSP Considerations

  • Are there any specific processes that are central to the current RMM that needs to be transitioned to the new RMM?
  • Does the current RMM provide value to other teams like sales/finance/marketing that will impact their work?
  • Security
    • Does the RMM meet or exceed the MSP’s security policy?
  • Insurance
    • Insurance firms / underwriters have been more cautious with RMMs since the Kaseya breach. It’s likely worth confirming with the insurance provider that premiums will not increase.

If you’re looking to make a change on your RMM, or have recently made a change, we hope the list will help you through the process.