RMM and documentation platform migration
This project is for your own business, not a client’s. We move your RMM, your documentation platform or both to a new platform, such as between IT Glue and Hudu.
You can’t stop using these tools while they change. Your team still has to patch, answer alerts and find a client’s firewall password the whole way through.
Every job has one owner at every point
A platform change isn’t one weekend cut-over. Each job hands over on its own schedule, and the overlaps are planned so nothing runs twice and nothing goes unwatched.
-
Agents on devices
The new agent goes on beside the old one. The old one comes off a device only after the new one has reported in from it.
-
Monitoring and alerting
Rebuilt monitors run next to the old ones for a while, so you can see what each would raise before the old alerts are switched off.
-
Scripts and automation
Rebuilt scripts are proven on a few test devices before they’re attached to policies for every client.
-
Patching
Never both. Patching moves in one step for each client, because two patch engines on one device means duplicate installs and reboots nobody scheduled.
-
Documentation
Your team stops writing to the old platform before the final import, so nobody saves a new password into the system being emptied. It stays readable until it’s retired.
- Old platform
- Both platforms in place
- New platform
- Old platform read-only
- Hard switch
An RMM holds years of decisions
By the time you change platforms, your RMM holds scripts written by people who have since left, monitors tuned for one noisy server, patch exceptions for a client’s line-of-business app, and policies overridden at client level until nobody is sure which setting wins.
Copying all of it across moves the mess. Rebuilding none of it throws away what your team learned the hard way. So the first job is working out what’s there and what’s in use, and agreeing with you what gets rebuilt, what gets tidied on the way and what stays behind. Then it’s rebuilt the way the new platform expects to work, not as a copy of the old one.
- Policy inheritancePlatforms resolve overlapping policies differently. A setting that won at client level on the old platform can lose to a global one on the new.
- Alert thresholdsA threshold copied number for number can still behave differently if the platforms sample or average differently. Each rebuilt alert is triggered on purpose to prove it fires.
- Patch approvals and rebootsApproval rules, deferrals and reboot windows are the part clients notice. They’re rebuilt client by client and checked before the first patch cycle on the new platform.
Getting the new agent onto every device
The cleanest route is often the old RMM itself: it’s already on every managed device, so it can install its replacement. Devices it can’t reach are covered through the deployment method you have, such as Intune or group policy. Laptops that stay off for weeks are the long tail. They’re tracked by name for each client until they check in, rather than left as a count that doesn’t quite match.
- Inputs
- The threshold comes from the policy.Each RMM passes values into a script its own way, so every input is reconnected by hand.
- Runs as
- SYSTEM or the signed-in user.Anything that touches a user’s profile, mapped drives or printers depends on getting this right.
- Success means
- An exit code, or the words it prints.Platforms read results differently. A script that reports success when it shouldn’t is worse than one that fails loudly.
- Writes back to
- A device field other things read.Policies, reports and other scripts rely on it, so the field has to exist on the new platform before the script can fill it.
- Runs when
- On a schedule, on an alert or at agent install.Triggers don’t map one to one between platforms.
The links between records matter as much as the records
A firewall record matters because it links to the admin login, the internet service it sits on, the site it lives at and the runbook that explains it. Move the records without those links and your team has every fact and no quick way to find it during an outage.
So organisations, assets, passwords and documents move together with their relationships, and the structure is rebuilt on the new platform before any data lands in it.
Organisations that don’t match by name
The same client is “Smith & Co” in your PSA, “Smith and Co Pty Ltd” in your documentation and something else again in the RMM. Names are matched before anything is imported, because an integration switched on with unmatched names creates duplicate organisations that quickly fill up with records.
Structured asset types
Custom record types, such as IT Glue’s flexible assets or Hudu’s asset layouts, need their layout built on the new side first, with each field mapped to its new home. Fields with no equivalent are raised with you rather than dropped.
Links inside documents
Documents link to other records using the old platform’s addresses, and carry inline images and attachments. Those are carried across and pointed at the new records. Otherwise they break, and it gets noticed the first time someone clicks one in a hurry.
Passwords and who can see them
Each password moves with the record it unlocks. Restricted folders and access rules are rebuilt and checked. Anything that can’t move the same way, such as one-time password seeds an export doesn’t include, is flagged for you to deal with rather than dropped.
The export is the most sensitive file in the project
A documentation export can hold every client’s passwords in one place. It’s kept out of email and shared drives, and deleted once the import has been checked.
Checked against the old platform
“It looks about right” isn’t a check. Every part of the move is compared with what the old platform held, so gaps are named rather than discovered by a technician months later.
RMM
- Device counts for each client on both platforms, with every missing device listed by name.
- A test alert raised for each monitoring policy and followed to where it should land.
- Patch policy and reboot window confirmed for each client before the first cycle.
- Rebuilt scripts run on test devices, with results compared against the old platform.
Documentation
- Record counts for each organisation and record type, old against new.
- Relationships and links inside documents opened and followed for a sample of records in each organisation.
- Password access tested from a technician’s account, not just an administrator’s.
- Attachments and inline images opened, not just counted.
It all goes into a migration report: what moved, what was deliberately left behind and why, any devices or records that need a decision from you, and how the new platform has been set up.
Then the old platform goes
Old agents come off each device once it’s confirmed on the new platform, along with the remote access and other components installed with them. Uninstall protection on the old agent is dealt with along the way, and devices that come back online late are caught when they do.
The old platform is retired last, after you’ve kept any exports you want for your own records. You’re left with one RMM and one documentation platform, and any device the old agent couldn’t yet be removed from is listed by name rather than left running.
Tell us what you’re moving between
Which platforms, roughly how many clients and devices, and whether documentation is moving as well as the RMM. We’ll quote a fixed price for the agreed scope, and the work is delivered remotely.
You end up with agents, policies and records on the new platform, the old one retired, and a migration report.