For a typical MSP, the RMM platform is the nerve center of the business. While you can run a managed services practice without it, the RMM is critical to maintaining a link with the customer for real-time monitoring and alerts, troubleshooting, and routine updates.
So, it would be safe to assume that MSPs go to great pains to avoid switching RMM platforms. But migrations are common, and they happen for various reasons.
Reasons To Change Your RMM
“Deciding to switch often stems from the need for better scalability, cost management, or specific features that align more closely with evolving business objectives,” says Adam Bielanski, CEO of MSP+OS, an IT consultancy and coaching company. “It’s not just about what’s lacking in the current system, but also about what potential gains a new RMM could bring in terms of efficiency, client satisfaction, and long-term growth.”
Often, security is a primary motivator for switching. Followed by functionality and ease of use, it tops the list for Mike Bloomfield, president of Tekie Geek, an MSP in Staten Island, New York, and an ASCII Group member. He warns against switching for the wrong reason, however: “A key consideration should not be that your RMM provider was purchased by another company who you may or may not like.”
Josh Kotler cautions against switching solely based on price. “When my peers talk to me about cheaper tools, if I had hair, I’d pull it out,” says the former MSP who is now a partner in two private equity firms, one of which, Sansom Street Capital, is investing in MSPs. “The price we pay for our RMM tool just is nothing compared to the labor that goes into transitioning from one to another.”
Switch RMMs With Eyes Wide Open
Be sure to clearly define the reasons for switching, experts advise, before you proceed. Take all relevant technical and integration factors into consideration. And don’t forget the human factor: Switching RMMs has a profound impact on the business and, as such, it requires explanation and training for the staff.
MSPs who have done it one or more times advise peers to be very deliberate with their decision:
- Set a realistic timeline.
- Weigh the investment against expected ROI.
- Factor in all potential costs, including those involving new licenses, potential downtime, and staff training.
“Plan, plan, and plan again,” says Bloomfield. “Everything will need to be moved and every RMM company will make it seem like it will be easy. Here is the truth: It will not be easy, and it will take weeks to months to move everything over. Think of all your monitors, scripts, update rules—everything!”
Migration Motivators: The Why Behind Switching RMMs
DataCorps Technology Solutions, an MSP in Brandon, Florida, and also an ASCII Group member, has switched RMMs four times, “each driven by distinct needs and growth phases,” says CEO and President Angel R. Rojas.
The first time DataCorps switched was due to lack of support from the platform vendor, he says. “The next RMM promised NOC services and automation, but we faced challenges in managing alerts and experienced communication issues. Our third RMM offered flexibility but suffered from a lack of investment and growing technical debt.”
At last, he says, DataCorps has settled on a platform with a modern interface from a vendor that is innovative, receptive to customer feedback, and proactive with feature development. “An RMM vendor that isn’t evolving to meet the latest technological challenges or isn’t listening to its client base can hinder an MSP’s growth and service quality,” Rojas says.
Mike Giovaninni, CEO of NetWerks Strategic Services, an MSP based in Agawam, Massachusetts, reviewed several competing platforms before switching. “We found that between a dated user interface and a number of features that never really worked effectively, it was time for a change.”
Some of the features, such as the platform’s Mac agent, were so cumbersome that NetWerks techs never used them. On top of that, agents would fail to update, or disconnect completely, and the syncing between the RMM and PSA, which were from the same vendor, was problematic, Giovaninni says.
The Critical Steps To A Successful Migration
RMM migrations, say MSPs, take a few weeks to several months. How long it takes depends on business and staff readiness, complexities of the existing platform, and the scope of the new system.
Giovaninni, who has changed platforms twice, recommends planning out the migration at least six to nine months in advance. “Then, at least three months out, start your onboarding process. It will result in having to pay for both platforms for a time, so budget for that added overhead as well as any onboarding charges.”
To start, conduct a comprehensive audit and risk assessment, says Bielanski. “Plan meticulously, ensuring data integrity during transfer and system compatibility. Phase the migration to minimize disruption and focus on training and support to get everyone on board.”
To avoid missteps, says Giovaninni, follow the 7 P’s:
Proper prior planning prevents pitifully poor performance.
“Map out all major configuration points of the new platform first,” says Giovaninni. “Educate your team on how they work and how they differ. Map out all your integrations. If your new RMM does not support some integration you’ve become accustomed to, can you find a way to work around it?”
When it’s time to migrate clients, he says, do it gradually. “Make sure that you triple-check before pulling out the old agents.”
A staggered deployment strategy, beginning with the less critical systems, helps identify issues before a full rollout, says Rojas. Maintain communication with the new RMM vendor throughout the process to quickly address any issues that arise, he adds.
RMM Migration Lessons Learned
Asked about lessons learned from their RMM migrations, MSPs advise thoroughly reviewing the new RMM’s features and training materials, testing out new settings and policies, doing the migration of workstations and servers separately, and keeping the staff properly informed about the process.
If nothing else, say MSPs, don’t rush the process. And remember, there’s no such thing as overplanning.
