Number (DiD) Lifecyle and Porting Process

Contents

1. Before you start
2. The life of a number
3. Before you port: the inventory
4. The port
5. After go-live
6. Where to go next

1. Before you start

Who this is for

• Audience — voice administrators.
  • Anyone who will hold the number inventory, submit a port, or answer a question about a DID after go-live.
• When to use it — before number work begins.
  • The inventory is the first thing to start and the last thing anyone regrets starting early.
• What it covers — the whole life of a number.
  • From the outgoing carrier, through the port, into service, and on to routine change once you are live.

What this covers

• The five states — where a number can be, what it costs, and who can move it.
• Reserved numbers — why a parked number needs two steps before anyone uses it.
• The inventory — what the file looks like, and the rows that matter most.
• What not to port — elevators, blue lights, alarms and fax lines.
• Phases and the gate — porting runs in phases; Spectrotel verifies every order before submission.
• The paperwork — what Spectrotel needs before anything is submitted.
• The port itself — who does what, in what order, over the whole run.
• Routine change — what a valid change request contains after go-live.

2. The life of a number

A number is always in one of five states. Knowing which one answers most questions before they are asked.

• Reserved can return to active by a change request to Spectrotel. Retired cannot.
• A campus can only affect two of the states directly.
  • Assigning a number in Teams and unassigning it are campus actions. Everything that changes the number’s state with the carrier is a request.
• Active numbers buy capacity in tens. Each bundle covers up to ten active numbers. Activating one number can buy a whole bundle. Parked numbers use none.
   

Reserved numbers: two requests and an approval before a parked number goes live

A parked number is cheap because it carries no calling and no emergency service. Getting it into service takes two vendor requests and a SUNY approval, started through your voice administrator.

The right way — two requests and an approval:

1. Ask the program. Send the request to your voice administrator.
2. SUNY approves. Change Release Authorization, approved by John Green or Kevin Stillman.
3. Spectrotel. Moves the number to in-service and sets the 911 record.
4. AudioCodes. SUNY User List Template: number, display name, UPN, any policy notes.
5. You assign it in Teams, to the user or resource account.

Activation is a billing change, which is why it goes through the program rather than direct to the carrier. The carrier record and the Teams-side configuration are separate systems — doing one does not do the other.

How the money actually works

• Capacity comes in tens.
  • One call path bundle covers up to ten active numbers and includes unlimited local and long distance calling and emergency service for them.
• Activation is a step, not a smooth per-number cost.
  • At forty active numbers you are using exactly four bundles; the forty-first buys a fifth. Know where your next step is.
• Parked is genuinely cheap
  • ​​​​​​​ A few cents a month, no bundle consumed, and it cannot make or receive calls until activated.
• Your rates are on your PIA.
  • Bundle and per-number rates sit on your Participation Agreement. Ask the program before you model a change — the step matters more than the unit price.
  • Parking numbers for a known future need is usually cheaper than retiring and re-acquiring them.
  • Retired numbers cannot be recovered.

3. Before you port: the inventory

The SUNY Port and Order Template is the program form Spectrotel works from. Build your inventory in it, not in a file of your own.

A real extract, shortened. The template also carries the losing carrier account name, PIN, authorized name, billing address, CSR flag, and the service address split across five separate columns. Every row that reads like the last one is a question to answer before you submit anything.

• Caller ID name is 15 characters, including spaces. The cell rejects anything longer, and it is the field campuses spend the most time redoing.
• Dynamic and Static behave differently. For Dynamic, the address is for taxation and Teams supplies the location. For Static, the address on this form is the location.
• Split the address across the columns. Street, suite or floor, city, state and zip each have their own cell. Combining them corrupts the batch update.

What you will find — every number is one of these, and they do not all move the same way

• User lines — the bulk of the estate. These port and become Teams numbers.
• Main published numbers — switchboards and departmental numbers. Higher cutover risk; plan them first.
• Queues and attendants — need a resource account with its own license on the Teams side.
• Common area phones — lobbies, corridors, workshops. Their own account and their own license.
• Analog and elevator lines — stay on analog behind a MediaPack or on a legacy line. Not Teams numbers.
• Blue lights and alarms — life-safety paths. Agree their treatment with facilities before anything moves.
• Fax and modems — usually retired or kept on a POTS line. Confirm who still relies on them.
• Unidentified — the most important category. Every one is a decision waiting to be made.

Some numbers should not move to Teams

• Life safety — blue lights and alarms. Emergency posts, fire and alarm panels. Their path is agreed with facilities and is usually analog behind a MediaPack.
• Lifts and elevators. Regulated and separate; elevator phones stay on a dedicated path. Confirm with your lift maintainer before anything on that line changes.
• Fax and modems. Rarely worth moving. Most can be retired; the rest stay on a POTS line or move to a fax service.
• Door access and gates. Easy to miss — often a forgotten analog line with nobody named against it. Find them during the inventory.

Decide the path for each of these during the inventory, while there is time to plan it properly.
 

Porting runs in phases, not as one event

A typical campus runs five to twelve port orders over six months to a year — one losing carrier per order, building by building or department by department.

Typical span: month 1 to month 12.

• One carrier per order. A campus with ranges on two carriers runs two orders, with different requirements and potentially different dates. Group the plan by carrier first.
• Every phase runs the same loop: scope, packet, gate, submit, cut over, hypercare, accept — on the Port Orders tab of the readiness tracker, one row per order.
• The inventory goes stale between phases. Reconcile each phase against current records before its order, not against the inventory from readiness.
   

4. The port

What goes into a submission

Gathered once, submitted through the program. A submission missing any of these waits until it is complete.

• SUNY Port and Order Template — numbers, campus, port date, carrier account, caller ID and E911, all in one form.
• Customer Service Record (CSR) — from the losing carrier. Lists every number they hold, usually with the BTN.
• Recent invoice — no older than 31 days at every submission, for every carrier.
• Port authorization PIN — where the losing carrier requires one. Ask them.
• Change Release Authorization — the SUNY form, approved by John Green or Kevin Stillman.

One submission goes through the program to Spectrotel quotes, quoting your Spectrotel sub-account number. Spectrotel validates (any queries come back to you and are quick to resolve), then the order is submitted to the carrier, who accepts or returns it.

No Letter of Authorization is required. Spectrotel verifies and owns the pre-port gate — nothing is submitted, and no port date requested, until the packet passes. A Customer Service Record is the single thing most likely to make the port succeed first time — ask your carrier for it early.
 

The pre-port gate — verified by Spectrotel

• Who owns it. The Spectrotel port desk checks the packet before anything is submitted; the program assists your campus through it. No port date is requested until the gate passes.
• Per order, not per campus. A fresh CSR and an invoice no older than 31 days for every order — five to twelve times over the migration, not once at the start.
• Carrier-specific checks: the Carrier Register. Losing carriers differ; Frontier requires an IP Justification form with the order. The register on the tracker holds what the program has learned per carrier — check it before every order.
• Why it exists. A rejection costs a month: the list freezes at submission and a rejected port restarts the thirty-day clock. Every rejection cause is checkable before submission — so it is checked, every time.

The gate lives on the Port Orders tab of the readiness tracker. It reads READY TO SUBMIT only when the packet is evidenced.
 

Who does what, in order

Eight steps. The SUNY approval at step two and the testing at step eight are the ones most often left out.

AudioCodes configure in parallel with the carrier build, from the SUNY User List Template — number, display name, user principal name, policy notes.

Why a port comes back, and what to change

Almost every return is one of five things, and all five are fixable before you submit.

1. The account details do not match. Name, address or PIN. Take them from the losing carrier’s own record, not the campus directory. A CSR settles all three.
2. A number on the list is not active. Carriers reject inactive numbers. Campuses point unused numbers at a shared voicemail to keep them live until the port completes.
3. An order is already open on the account. Any move, feature change or disconnect will hold it. Freeze changes on that account once you decide to port.
4. The account is not in good standing. An unpaid balance or disputed invoice will stop a port. Check with finance before submitting.
5. The numbers are not on that account. Group your list by billing number; numbers cannot be ported across accounts in one request.

A rejected port restarts the thirty-day clock. Every one of these is checkable before you submit.

Cut-over day, and the dates around it

• Book it 30 to 45 days out. Ports run 9am to 3pm, weekdays. That lead time is required, not advisory. Once submitted, numbers cannot be added or removed without canceling and restarting the whole thirty-day cycle.
• Moving the date is expensive. A change 24 to 48 hours out carries a per-number fee; a change on the day carries a much larger one. Across several hundred numbers that becomes a serious figure. Confirm current rates with the program.
• It happens in two stages. The numbers port, then the emergency records load — possibly hours later on a large batch. For static numbers, wait for the E911 load before running 933.
• Allow a settling period of two weeks. Porting issues can surface a few days later, often as a single inbound path. Hold the project open until it is stable.

Active numbers port first; parked numbers follow in a separate step. Confirm the outgoing carrier has stopped billing, and give that check a date and an owner in campus finance.

Caller ID reputation — register before you cut over

• The problem. After a port, legitimate campus numbers can display as “spam” or “scam likely” on recipients’ phones — at campus scale, hundreds of numbers at once.
• Why it matters. Admissions, advancement and clinic calls that display as spam go unanswered, and the damage to confidence in the new platform takes far longer to repair than the port itself.
• The fix: one registration, three carriers, before cutover. Register the ranges at freecallerregistry.com as a pre-cutover check on every port order — one free submission reaches Verizon/TNS, T-Mobile/First Orion and AT&T/Hiya. The number owner registers; allow up to thirty days.
• If it happens anyway, tell the program. Give removal up to thirty days. Numbers still labeled after that are pursued by the affected recipients with their own carrier; the program escalates dated call examples through Spectrotel.

This is a pre-cutover step on every port order, not a one-time task — it is on the readiness tracker. For numbers already labeled, go direct: voicespamfeedback.com · portal.firstorion.com · hiyahelp.zendesk.com. Step by step: pack document 15.
 

5. After go-live

What a change request looks like

Anything that changes what SUNY is billed goes through the program. You start it; the program places the order.

To:      [your voice administrator]
Subject: Service change request — [Campus] — Spectrotel customer ID [number]

Please move 518 629 7840 from Parked_Reserved to In-service.

Service address: 80 Vandenburgh Ave, Troy NY 12180.
E911 setting: Dynamic. Outbound caller ID: HudsonValley CC.
Needed by: [date]. Reason: [new starter in the Registrar's office].

Requested by [name], [title], [phone], [email].
Listed on the campus authorized contact list.

• Start with the program, not direct with the carrier. Activation changes billing, so it needs a SUNY approval before it can be ordered.
• Your Spectrotel customer ID in the subject line, every time.
• The number and the target state — In-service or Parked_Reserved, in the template’s own words.
• Address, E911 setting and caller ID — these go on the Port and Order Template. Give them once and the form can be completed for you.
• The user, if there is one — display name and user principal name go to AudioCodes on the User List Template.

The program prepares the SUNY Change Release Authorization, obtains approval, and places the order with Spectrotel quotes. AudioCodes receive the SUNY User List Template — number, display name, user principal name and any policy notes — so they can configure it on the platform.

The NIC portal — what it is for

Spectrotel’s customer portal is an orders and inventory tool. Useful, within a clear boundary.

Ask AudioCodes for the Spectrotel case number when they hand a ticket over — then you can follow it here without opening a second case.

Eight things worth planning for

All of them are easier before the port than after it.

1. Get the CSR early — it settles account name, address and numbers in one document.
2. Thirty to forty-five days — the lead time is required. Work backwards from the date you need.
3. Freeze the outgoing account — any open order will hold the port. Tell whoever manages that account.
4. Caller ID name — fifteen characters including spaces. Agree it with the department early.
5. Dynamic or static per number — it decides whether the form address is a location or a tax address.
6. Active first, parked second — two separate port steps. Plan the sequence, not just the date.
7. Double billing — set a date to check the next invoice, and give it an owner.
8. Life after go-live — number data drifts. Name an owner and a review cycle for the inventory.
    

Keeping the inventory worth having

• One owner, named, not assumed. A person, not a team mailbox. The inventory is the first thing asked for by the next project and the hardest to rebuild.
• A review cycle — quarterly is enough. Reconcile assigned numbers in Teams against the carrier inventory. Differences are usually leavers.
• Release what you do not need, or park it. A DID on a departed account stays billable and cannot be reissued until it is released. Parking is cheaper than holding it active.
• Record decisions, not just data. Note why a number was kept on analog or left with the outgoing carrier. In two years nobody will remember.

The program can help you reconcile the first time. Ask through your voice administrator.
 

6. Where to go next — who to contact

How to Get Support is the authoritative contact source — this section is a convenience copy. Architecture reflects the current production environment; SUNY is evaluating future cloud-hosted options.