Next Mile originally produced this as customer-facing content to guide and estimate a full-scale enterprise IoT platform and fleet migration.

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:

• User authentication
• Account creation
• Device control functions
• Over the air updates
• Data store
• Data processing
• Device provisioning
• Fleet administration
• External integrations
• Platform DevOps

Consequently, step one in a platform transition is to break down what your platform actually does. We begin with the following questions:

• How do you authenticate users?
• How do you authenticate devices?
• Where and how do you store data from devices?
• How do you provision devices?
• How do you handle device and interface analytics?
• How do you build and deploy your fleet(s)'s firmware?
• How do you build, deploy, and administer your interface software?
• How do you view and manage fleet health?
• What external integrations contribute data to your ecosystem?
• Who does all of the above?
• How do other departments (customer service for example) interface with customer devices and admin tools?
• What outside systems depend on data or services from this ecosystem?

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:

• The replacement system
• New system licensing costs
• Implementation engineering
• Migration work
• Testing effort
• Rollout effort
• Ancillary operating expenses

There’s more. Our system change has systemic implications:

• Interface application changes
• Device firmware changes
• Dependent system change
• Incident plan: increased call volume, inevitable bricks, # of unconnected devices now on shelves that can't be updated (you may have to leave that legacy infrastructure active far longer than you thought)
• DevOps support effort: these new services are now either decentralized and externalized or partially owned by you. Bake these recurring expenses (and headcount) into each component you intend to build and maintain.

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:

1. Okta implementation:
   1. Stand up
   2. Migrate user data
   3. Test
   4. Verify
2. Modify interface app to use new authentication, then test it
3. Modify e-commerce site and test it, should work in dev/staging
4. End-to-end test with fleet users
5. Rollout phases
   1. Leverage proxy to current user management. If not already implemented:
      1. Create proxy
      2. Roll out endpoint changes to interface app(s)
      3. Roll out endpoint changes to devices, preferably by SKU or other cohort
   2. Set primary user services to Okta, failover to old
   3. Move to standalone Okta once you’re certain
6. Decommission previous account service

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:

1. Stand up MQTT on AWS/Azure, map functions and/or rewrite commands
2. Test control functions and data payloads with MQTT
3. Rewrite affected device firmware for MQTT by SKU/build
4. End-to-end test with affected fleet SKUs
5. Rollout
   1. Comm proxy
   2. Routing: MQTT to AWS/Azure, HTTPS to legacy
6. Legacy HTTPS communication
   1. Stand up and maintain proxy for legacy HTTPS
   2. Redirect or reformat communication
7. Firmware rollout by line/cohort/SKU
8. Decommission HTTPS once you’re sure

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:

1. Configure your replacement platform’s OTA system
2. Modify or recreate firmware to conform with new standards and/or implement agent multiplied by the number of distinct firmware builds your fleet contains
3. End-to-end test the rebuilt firmware with affected devices
4. OTA testing by SKU, connection type, and other parameters
5. Firmware rollout by line/cohort/SKU
6. Decommission legacy OTA structure once you’re really really sure

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:

1. Rearchitect schema(s), define requirements and functions (controls, history, user data)
2. Stand up database types per needs. Test database performance, availability, and scaling.
3. Migrate user data into new schema(s) and test
4. Modify firmware for new data routing if needed
5. End-to-end of test rebuilt firmware with affected devices
6. Firmware rollout by line/cohort/SKU
7. Maintain and archive legacy database
8. Decommission legacy data service when plausible

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:

1. Redefine manufacturing/provisioning plan. Many non-boutique platforms lack obvious manufacturing provisioning support, but nodes/devices can be created via API, requiring a customized interface (and not necessarily just a user interface).
2. Create and test manufacturing/provisioning application and/or modify existing to support
3. Modify firmware for new provisioning method as needed
4. End-to-end test rebuilt firmware with affected devices
5. Firmware rollout by line/cohort/SKU
6. Maintain legacy activation database
7. Decommission previous provisioning system

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:

1. Define fleet admin needs and compare to prebuilt dashboard capabilities
2. Decide which tools to implement
3. If available, design/build or modify your fleet admin service web application to interface with your new system
4. Decommission legacy administrative tools

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:

• Consumes from third parties
• Is dependent on
• Is depended on

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:

1. Map your services architecture
2. Identify external depended-ons/dependents
3. List and account for all platform functions, noting those that your new platform doesn’t have an obvious solution for
4. Recreate or reimplement any remaining necessary services
5. Quality, availability, performance testing of integrations as triggered from device, platform, and interface applications
6. Decommission any remaining external services used by your old platform

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. Based on the above example, here’s a general worksheet you can use to tally up your migration’s total real cost and timeframe:

Recurring costs

Non-recurring costs

Final total

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.