How to calculate the true cost of IoT platform migration
Next Mile originally produced this as customer-facing content to guide and estimate a full-scale enterprise IoT platform and fleet migration.?Find our original blog post here.
For the OEM creating and selling a connected product, “connectivity” costs a ton, and that cost makes itself felt disproportionately at the program P&L, especially over time. Connectivity costs themselves tend to be weirdly opaque and/or nebulous. Time to fix that, starting with the IoT software platform.
Most IoT platform cost savings discourse revolves around one central metric: operational cost per connected device, calculated thusly:
$ total platform cost + $ fleet operation cost / # devices = $ cost/connected device
Many platforms sell strictly on this number (“only $1 per device per month!”), and their stated numerator is platform- and communication-focused so you can make an apples-to-apples comparison against your current platform and your cost as determined by your finance team.?
Apples-to-apples is the trap. It’s the switching costs that kill you.
In this article, we'll help you factor everything into your numerator: all the switching gotchas, by-the-ways, and batteries-not-includeds. This will get messy.
So why would I transition?
You might not have a choice. Businesses voluntarily transition IoT platforms only occasionally, mostly after feeling the strain of unsustainable cost growth, but sometimes because of performance problems, frequent outages, unaligned roadmaps, and service issues. Unfortunately for many, several recent transitions are involuntary due to a precariously-solvent platform provider threatening to go under.?
Most leaders react by switching to big iron (AWS, Azure) because those providers’ likely solvency and commodity pricing theoretically solve both the cost and continuity problems front-and-center today (never mind Google dropping IoT Core). This approach is never the worst plan, and since it’s the most typical, that’s what we’ll focus on here. There’s a long road ahead, and many of the costs your former provider bore will now be yours.?
You may feel railroaded into a transition, but before authorizing an enormous effort, ask your VPs to complete this exercise.
Break it down
Most product and business leaders understand their connected product's architecture clearly at a very high utilitarian level:
Device ? Platform ? Interface
With ?’s representing both the physical connection (say, cellular) and transport protocol (like MQTT). Let’s begin by unpacking “platform.” Using a representative real-world example, “platform" actually means:
Consequently, step one in a platform transition is to break down what your platform actually does. We begin with the following questions:
From there, we add questions depending on specific context.
Platform piece plans
Step two: you'll need a plan for each piece of your architecture. For each platform function, identify the following tasks and estimate their associated costs:
There’s more. Our system change has systemic implications:
System changes will affect the user experience. For our hypothetical device, interfaces now have a new auth API (BTW, users have to reauthenticate) which devices might depend on as well. You did create a proxy for your current endpoints previously, right? Hopefully?
User accounts and authentication migration
To continue our example, let's say you're going to have Okta take over user authentication and account creation from your old platform. Your business's e-commerce system will also use the same Okta instance so users only have to remember a single brand account. For just this piece, you have to perform the following tasks:
Now, we unpack the remaining components!
Protocol change: HTTPS→MQTT
Protocol changes often aren’t required. For platform customers, API calls are the most expensive part of their bill, so minimizing their frequency is a well-known, low-hanging-fruit best practice. Still, not sending HTTPS headers with every transmission can reduce costs as well, especially for cellular devices.
Protocol change task checklist:
Over-the-air firmware update system migration
On the platform side, this one varies greatly by the alternative you’ve chosen. On the device side, there’s usually a substantial firmware change required. Your typical tasks include:
Platform data migration
Now we port relevant data from the old platform to the new one. The more types of data you store, the more complex this task becomes. Rollout methodology and timing will play a crucial role—a single bit can represent whether or not a garage door is up or down, so rolling out today based on last night’s data may create an unpleasant surprise for thousands of fleet users.
Platform data migration tasks:
Device provisioning system migration
Depending on your current approach, upending device provisioning could be the most painful high-level task on this list. Altering manufacturing provisioning in particular can disrupt factory floor tooling and process needs, making provisioning the controlling factor in overall project timing.?
Key provisioning migration tasks:
Fleet administration tooling migration
Few IoT platforms of any type provide worthwhile fleet administration tooling. If your fleet’s larger than 500,000 devices, chances are you’ve already built some custom interface to view, analyze, segment, and find devices and/or trigger scripts or updates by group. If your operations became dependent on the previous platform’s dashboards or other built-in tooling, you’ll either have to replicate them or live without them.?
Although your circumstances dictate, this task list is commonly short:
It may also be possible to pipe your new system’s data into your old platform’s dashboards/admin tools.?
External integration changes
Always the wildcard, “integrations” means anything that your platform:
While external integrations are easy to know about, the non-obvious are the external services your previous platform depended on that appeared as standard platform services to you, such as password reset, activation emails, notifications, sign-up/registration, voice control, and similar. Your tasks:
A note on MDF (market development funds)
Technology platform providers like Microsoft and Amazon frequently dish out MDF to their channel partners should those channel partners win a professional services deal to onboard a new device fleet. Your implementation partner would apply some or all of the MDF to cover the professional services cost.?
While MDF can take the edge off your capital expense, it usually comes with strings attached that will depend on your specific partner and circumstances. Pay close attention to the fine print!
Calculation worksheet
Step three: add it all up and chart out the timeline. I've put together a worksheet below you can use to tally up every cost. We've also shared a Google Sheet you can copy to start with.
Recurring costs
User accounts and authentication
New service licensing: $_____,_____.__
Legacy service continuation: $_____,_____.__
Protocol change: HTTPS→MQTT
New service licensing: $_____,_____.__
Legacy service continuation: $_____,_____.__
DevOps support: $_____,_____.__
OTA migration
New service licensing: $_____,_____.__
Legacy service continuation: $_____,_____.__
DevOps support: $_____,_____.__
Platform data migration
New service licensing: $_____,_____.__
Legacy service continuation: $_____,_____.__
DevOps support: $_____,_____.__
Device provisioning migration
New service licensing: $_____,_____.__
Legacy service continuation: $_____,_____.__
DevOps support: $_____,_____.__
领英推荐
Fleet administration tooling migration
Any additional licensing: $_____,_____.__
Legacy service continuation: $_____,_____.__
Possible DevOps support: $_____,_____.__
Integration migration
Any additional licensing: $_____,_____.__
Legacy service continuation: $_____,_____.__
TOTAL RECURRING: $_____,_____.__
Non-recurring costs
User accounts and authentication
Okta implementation: $_____,_____.__ / ?? weeks/months
App modification and testing: $_____,_____.__ / ?? weeks/months
E-commerce modification and testing: $_____,_____.__ / ?? weeks/months
End-to-end verification with fleet users: $_____,_____.__ / ?? weeks/months
Rollout management: $_____,_____.__ / ?? weeks/months
Decommission legacy account service: $_____,_____.__ / ?? weeks/months
Protocol change: HTTPS→MQTT
MQTT (or other) implementation: $_____,_____.__ / ?? weeks/months
Device firmware modification and testing: $_____,_____.__ / ?? weeks/months
(multiply this by the number of firmware builds if needed)
Proxy/routing/legacy: $_____,_____.__ / ?? weeks/months
End-to-end testing: $_____,_____.__ / ?? weeks/months
Rollout management: $_____,_____.__ / ?? weeks/months
Decommission legacy communication: $_____,_____.__ / ?? weeks/months
OTA migration
Platform OTA setup and implementation: $_____,_____.__ / ?? weeks/months
Device firmware modification and testing: $_____,_____.__ / ?? weeks/months
(multiply this by the number of firmware builds)
Proxy/routing/legacy support changes: $_____,_____.__ / ?? weeks/months
End-to-end testing: $_____,_____.__ / ?? weeks/months
Rollout management: $_____,_____.__ / ?? weeks/months
Decommission legacy OTA system: $_____,_____.__ / ?? weeks/months
Platform data migration
Schema rearchitecture: $_____,_____.__ / ?? weeks/months
Database(s) implementation: $_____,_____.__ / ?? weeks/months
Data migration and testing: $_____,_____.__ / ?? weeks/months
Device firmware modification and testing: $_____,_____.__ / ?? weeks/months
(multiply this by the number of firmware builds)
End-to-end testing: $_____,_____.__ / ?? weeks/months
Rollout management: $_____,_____.__ / ?? weeks/months
Legacy routing/maintenance: $_____,_____.__ / ?? weeks/months
Decommissioning: $_____,_____.__ / ?? weeks/months
Device provisioning migration
Redefine provisioning methodology: $_____,_____.__ / ?? weeks/months
Build manufacturing provisioning toolkit: $_____,_____.__ / ?? weeks/months
Device firmware modification and testing: $_____,_____.__ / ?? weeks/months
(multiply this by the number of firmware builds)
End-to-end testing: $_____,_____.__ / ?? weeks/months
Rollout management: $_____,_____.__ / ?? weeks/months
Legacy routing/maintenance: $_____,_____.__ / ?? weeks/months
Decommissioning: $_____,_____.__ / ?? weeks/months
Fleet administration tooling migration
Fleet administration strategy: $_____,_____.__ / ?? weeks/months
Pre-built tool selection and implementation: $_____,_____.__ / ?? weeks/months
Design/build or modify current fleet administration application built upon new controls and databases: $_____,_____.__ / ?? weeks/months
End-to-end testing: $_____,_____.__ / ?? weeks/months
Rollout management: $_____,_____.__ / ?? weeks/months
Decommissioning: $_____,_____.__ / ?? weeks/months
Integration migration
Redefine services architecture: $_____,_____.__ / ?? weeks/months
Implement missing services: $_____,_____.__ / ?? weeks/months
Service quality/availability/performance testing: $_____,_____.__ / ?? weeks/months
End-to-end testing: $_____,_____.__ / ?? weeks/months
Decommission legacy services: $_____,_____.__ / ?? weeks/months
General allowances
Incident management/customer service: $_____,_____.__ / ?? weeks/months
Possible new feature development: $_____,_____.__ / ?? weeks/months
Anything else?: $_____,_____.__ / ?? weeks/months
TOTAL NON-RECURRING: $_____,_____.__ / ?? weeks/months
Final total
Recurring costs: $_____,_____.__ * lifespan (years)
Lifespan total: $_____,_____.__
+
Non-recurring costs: $_____,_____.__
-MDF: -$_____,_____.__
=
TOTAL IOT PLATFORM MIGRATION COST
$__,______,_______.__
IoT platform migrations, like any technology transition, take experience and detailed planning to get right.
This is a prototypical example—yours will be different. Next Mile has helped clients through tricky transitions large and small, saving millions along the way. If you’re facing a potential IoT platform switchover, reach out, and we’ll help guide you in softly.
CEO & Founder at SumatoSoft
1 年Calculating the true cost of IoT platform migration is a critical exercise that demands careful consideration of numerous factors.
Connected Products Pioneer and Technology Evangelist
1 年I'd recommend your next follow-up being a part 2. The decision-making flowchart of whether to dump the platform you have. This reminds me of the book my wife recommends to her therapy clients seeking couples therapy, "Too good to leave, to bad to stay". A series of diagnostic questions that take some of the emotions out of the difficult decision. Sometimes leaving the platform company you're with is totally justified and no amount of sunk cost should be reason to stay. 1. Did your current platform experience a major security breach, impacting your device fleet and your end customers. 2. Is your current platform stealing your data and selling it on the Dark Web? (not only do you have to migrate, you have a lawsuit you should be filing if the company isn't based out of some sketchy place. 3. Does your platform lie about outages and performance issues? Are they gaslighting you and covering up mistakes and platform shortfalls? Ooh, this is fun. Who else can add to this list?
Connected Products Pioneer and Technology Evangelist
1 年Woof. Being in a situation where you have to switch platforms is a beast, especially if your vendor is doing an end-of-life (cough Google Cloud cough). I've had a number of clients impacted by the GCP end-of-life announcement. If you're lucky enough, there are some enterprising companies that I've read about such as ClearBlade that are a direct 1:1 replacement for GCP, emulating the pubsub, APIs, device management registry, and so on. But as you've pointed out, there are still going to be OTA updates, changes to endpoints at the device level (maybe?) and lots of testing to make sure the transition is smooth. But I don't think you're writing this document to help the people impacted by GCP, it's the ba-jillion other squirrely IoT platforms that were chasing their tails trying to grab up their slice of the IoT land grab to make the mad IoT bucks. And like the old gold rush frontier towns, full of ghosts. These platforms throw around terms like, pivot, productization, and (drumroll) acquisition by their largest clients that can't afford to migrate away, so they go all-in, buy up the IP, get key developers on contract, and shed the other customers as part of a strategic realignment. 3 words... Sunk. Cost. Fallcy.