Migrating from Pod 11 to Pod 17/19: What IoT Team need to Watch Out For

Many enterprise clients who manage IoT lines through AT&T, T-Mobile, or other mobility providers have historically operated on Pod 11 within Cisco Jasper (Control Center). Over the last year, however, carriers have been transitioning customers to Pod 17 or Pod 19, as the legacy pod approaches deprecation.

The newer pods promise better API performance, updated security and identify management, more reliable lifecycle automation, and overall improved system stability. Ideally, these upgrades will also improve the accuracy of device data and syncing with billing systems, an area where clients have experienced real consequences. In one case, dashboard usage data in Pod 11 did not match the actual AT&T billing, resulting in massive overage charges that required a dispute. Without close monitoring, issues like this could easily go unnoticed.

But while the new pods are an improvement, the migration process is rarely seamless. There are several operational risks that IoT and TEM tams need to understand.

New Pod = New Account Number (and Nobody Tells You)

One of the biggest surprises during migration is that the carrier may create an entirely new IoT account number in Pod 17/19 rather than merging it with the legacy account.

If nobody flags this:

• the new account quietly bills for months

• TEM teams don't optimize it

• usage/overages accumulate

• the vendor may not notify the client

• and charges may go unnoticed until the invoice totals jump

This has happened in real migrations, six months of charges with zero visibility.

SIMs Must Be Properly Decommissioned (or You Keep Paying)

When AT&T and T-Mobile migrate accounts to new pods, the SIMs do not automatically disappear from Pod 11.

If they remain active in the old pod:

• they keep billing monthly recurring charges

• even if they show no usage

• because MRC charges do not depend on traffic

• and nothing alerts you unless you manually check

Clients often assume "we're on the new pod now, so the old one doesn't matter", but that is not true. You must:

• deactivate SIMs in Pod 11

• confirm they were migrated successfully

• verify no active subscriptions remain

Otherwise, you literally pay twice for the same line.

Plan Misalignment After Migration

Even when SIMs appear correctly populated in the new pod, the rate plans may not map cleanly.

We've seen cases where:

• the same plan name is assigned

• but the MRC is significantly higher on Pod 17/19

• and nobody realizes until after invoicing

This is especially common when carriers rename or reorganize IoT plans during the migration.

You must verify:

• plan codes

• plan pricing

• promotional vs. standard MRC

• matching SOC codes

• alignment across billing + inventory + pod data

Billing Cycles and Usage Cycles Are Different

A common point of confusion:

• Pod 17/19 has its own usage cycle end dates

• The billing invoice may show different billing period dates

Example:

• Pod usage cycle ends on the 18th

• AT&T invoice shows the billing cycle running 21st-20th

But overage prevention must be done based on the usage cycle inside the pod, not the billing cycle printed on the invoice.

If you optimize based on the invoice dates, you will miss usage spikes and trigger avoidable overages.

Clean Up the Legacy Pod (Don't Manage Two Worlds)

Once migration is complete, the goal is to:

• close out Pod 11

• deactivate all remaining SIMs

• ensure no shadow accounts remain open

• consolidate into a single pod and a single billing account

If you don't clean up the legacy pod, you end up managing:

• two inventories

• two sets of lifecycle statuses

• two sets of charges

• and double the work

The Upside: Pod 17/19 Really Is Better

Despite the friction, the new pods bring meaningful improvements:

• faster APIs (especially for large SIM pools: 50K+)

• more reliable usage pulls

• better filtering and search

• cleaner event and lifecycle handling

• stronger authentication

• improved alignment with modern carrier systems

Over time, these improvements should reduce operational issues and simplify IoT management.

Final Thoughts

Migrating from Pod 11 to Pod 17/19 is absolutely the right move, but only if it's done carefully. If the process is rushed, clients risk:

• paying higher MRC for the same plan

• paying MRC on legacy pod lines

• missing new accounts created during migration

• bad usage/billing sync

• and a messy double-pod environment

With proper auditing, clear communication with carriers, and close monitoring of the first few months of billing, the migration can be smooth and the benefits of the newer pods make it worth the effort.