The Short Version: Router vs. Platform
If you're standing in a server room holding a brand-new Sierra Wireless Airlink MP70, you've got a choice. You can crack open the manual, configure it locally via the web interface, and get it online — or you can register it with Sierra Wireless ALMS (AirLink Management Service) and manage it from the cloud.
I've been in that exact spot more times than I can count. In my role coordinating field deployments for a critical infrastructure company, I've handled 150+ router activations across the last four years. And honestly? The decision between a local config and ALMS isn't as straightforward as the marketing makes it seem.
Here's the framework I use to decide, broken down by the dimensions that actually matter when the pressure's on.
Dimension 1: Setup Speed — The 30-Minute Rule vs. The 15-Minute Sprint
The local approach: Unbox the MP70, plug it in, hit the IP default (192.168.13.31), log in, and start configuring. For a basic setup (cellular APN, IP passthrough, a couple of firewall rules), I'm looking at about 20-30 minutes. That's assuming you know the APN settings off the top of your head and don't need to call the carrier.
The ALMS approach: Register the device on the ALMS portal, create a configuration template, push it to the device. If the template is already built (which it should be, for repeat deployments), the device auto-configures in about 10-15 minutes after first power-on. The catch? You need ALMS access set up beforehand, and the device needs to ping the ALMS server — which means it needs basic connectivity first.
In March 2024, I had 36 hours to get 12 MP70s deployed across three remote sites. With pre-built ALMS templates, I configured all 12 in about 4 hours total — including travel time between sites. Local config on each one would have taken me closer to 8-10 hours. No contest for bulk deployments.
Verdict: ALMS wins for speed in repeatable, multi-device deployments. But for a single, quick-and-dirty install, local config is faster if you know what you're doing.
Dimension 2: Security & Remote Management — The 'Set It and Forget It' Trap
Here's where it gets interesting. The local config gives you full control. You're setting every rule, every port, every VPN tunnel by hand. That's powerful — but it's also a liability. Once you walk away from that router, how do you update it when a new vulnerability drops?
Last quarter alone, we pushed three firmware updates to our ALMS-managed fleet. Each update took about 15 minutes of my time: review the changelog, schedule the update window, and monitor the rollout. No truck rolls. No site visits. For our local-only devices (which are a legacy handful), each update requires a technician physically on-site. At $150 per truck roll, that's real money.
To be fair, ALMS has its own risks. If the ALMS platform goes down (which happened for about 2 hours in November 2024), you lose visibility. Your routers still run — they don't stop routing — but you can't push changes or see status until the platform comes back. For mission-critical networks, that's a consideration.
Verdict: For security and lifecycle management, ALMS is the safer bet — as of January 2025, at least. The convenience of remote firmware updates outweighs the 99.9% uptime trade-off.
Dimension 3: Troubleshooting Under Pressure — The 'Why Is This Not Working?' Scenario
This is the dimension that surprised me. I initially thought local config would always win for troubleshooting because you're right there, looking at the device. But I've changed my mind after a few specific incidents.
In June 2024, a client called at 4 PM needing an MP70 configured for a demo the next morning. Normal setup would take 30 minutes, but I was 45 minutes from the device. With ALMS, I logged into the portal, located the device, adjusted the IP passthrough configuration, rebooted it remotely, and had it working within 10 minutes. I didn't even have to leave my desk.
That said (and I stress this), if the device is in an area with spotty cellular connectivity, ALMS is useless. The device needs to be online to be managed. In one instance in early 2023, a router in a basement parking garage had marginal signal. Local troubleshooting via the console port was the only option.
Verdict: ALMS wins for remote troubleshooting (assuming connectivity). Local wins for hard-to-reach or low-connectivity sites. I keep a USB-to-serial adapter in my bag for exactly this reason.
So Which One Should You Use?
I can't give you a blanket answer — and anyone who does is oversimplifying. But here's the decision tree I use:
- Choose LOCAL if: You're deploying 1-5 devices, you have on-site access, and you want maximum control without an ongoing subscription. This is fine for temporary setups or low-availability requirements.
- Choose ALMS if: You're deploying 5+ devices, you need remote management, or you want automated firmware updates. The time saved in config and troubleshooting pays for the subscription (which, as of Q3 2024 pricing, runs roughly $15-25 per device per year depending on volume).
- Use BOTH if: You can. Configure locally for the initial setup, then register with ALMS for ongoing management. That's what we do for all new deployments now. Best of both worlds.
One last thing: whatever you choose, have a plan for the scenario where it fails. ALMS is down? Know the local IP and default credentials. Local config is failing? Have a backup router ready. In 2022, we lost a $12,000 contract because we tried to save $200 on a spare router for a critical demo. That $200 decision cost us the client.
At the end of the day, the tool matters less than the process. Pick one, learn it well, and have a fallback. That's the real secret to IoT fleet management.