Teams Phone Migration: Moving From a PBX to Cloud Calling Without Surprises

M365 FM - Teams Phone Migration - Moving From a PBX to Cloud Calling Without Surprises 00:00:00 Speaker: A team's phone. Migration isn't a phone project. It's a routing project, an identity project, and an emergency safety project that happens to carry voice. Most plans don't look like that. They cover licenses, they cover handsets. Then they miss the number ports, the emergency addresses, and the contact center. That's where it breaks. The surprises don't come from Microsoft. They come from assumptions your PBX hid for fifteen years. If you're planning this move, subscribe to the M365 FM podcast now before your cut over weekend, not after, but before we design anything. We need to see what the old model actually did. Sponsorship segment educational placement. A quick word from this episode's sponsor. I'll keep it useful. The sponsor builds migration tooling for Microsoft three hundred sixty five mailboxes, files, teams, data. The reason I'm mentioning them here is the rule behind every good migration tool. Same rule applies to phone numbers. Inventory. First, you can't move what you haven't counted a mailbox. Migration fails when nobody knew about the shared mailbox. With forty delegates, a number. Migration fails when nobody knew about the line that runs the alarm panel. Same failure, different workload. So if you're evaluating any migration tool or partner, Ask a few plain questions before you sign. How do they discover what exists? Do they trust your list, or do they check it against real usage data? What happens to the things they can't move? Every project has them. A good partner tells you early. A weak one tells you at cutover who owns the rollback, not the idea of a rollback. The actual steps, the named person, the time limit and what do they hand you when they leave? A tool is only useful for a project, a register of what you moved and why is useful for years. Those questions apply to data. They apply to numbers too. Now back to the core problem. And that starts with the PBX itself for the old model. What a PBX really does. Your PBX wasn't just a phone system, it was a closed system lines, extensions, trunks, a dial plan, all of it sat in one box, in one room, and in the head of one team, sometimes in the head of one person. That's what I call the model. The assumption that telephony is a fixed asset, something you own, something that sits on premises and stays where you put it. For decades, that assumption held a phone was a physical thing, wired to a physical port, tied to a physical desk, move the person, move the cable, add a user. Add a line card. The whole design assumed location was fixed. Teams phone doesn't work that way. In teams. Telephony stops being an asset. It becomes a workload and that workload is tied to three things identity, policy and network. Identity decides who the user is and which number belongs to them. Policy decides what that user can do and where their calls can go, and the network decides whether any of it sounds like a human voice. So the question changes. It's no longer, where is the phone plugged in? It's who is this person? What are they allowed to do? And what path is their audio taking right now? That's a different model. And here's the problem. Your PBX did a lot of work you never wrote down. Think about hunt groups somebody configured one years ago so that when sales gets a call, five phones ring in a set order. Nobody remembers why that order, but the business depends on it. Think about night modes. At six p m, the switchboard flips calls, go to a recorded message, or to a mobile or to a security desk. Somebody set that up. Maybe a facilities manager who left in twenty sixteen. Think about class of service. The PBX decided who could dial international, who could dial premium numbers, who could only call internal extensions. That was a rule. It lived in a config file and it enforced policy without anyone calling it policy. Then there's call recording. Some lines were recorded because a regulator said so. Nobody put that on the project plan. It just happened quietly in the background for years. And paging overhead announcements in a warehouse. A bell in the loading bay, a buzzer at the front desk, all triggered by the phone system and all invisible until the day they stop. That's the real problem. The PBX didn't just carry calls, it carried behavior and behavior doesn't show up on a license list. So here's how I'd frame this migration. You're not moving features. You're translating behaviors. A feature is a line item hunt group voicemail call forwarding. You can match those against a team's feature list in an afternoon. A behavior is what the business actually relies on. When the front desk is busy, the call rolls to the back office after four rings, and if nobody answers, it goes to a mobile. That's not a feature. That's a habit the organization built around a machine. Teams can usually reproduce the habit, but only if someone has described it first. That's the shift in the old model. The system held the knowledge. In the new model, you have to hold it. You have to write it down, assign it an owner and decide how it gets rebuilt. Because teams will do exactly what you configure and nothing you forgot, so you can't translate what you have encountered. Which means the first real step isn't design, it's discovery. Discovery. Inventorying the estate you don't know you have. Start by counting everything, not just the numbers. People know about everything. Dids extensions, analog lines, lift phones. Fax machines, alarm Dialers door entry panels, analog adapters. Hiding behind a cabinet in a stairwell. Each one is a dependency and each one will show up eventually. The only choice you get is whether it shows up in a spreadsheet or at seven a m on cutover Monday. So where do you get the list? Not from the PBX admin. Not only from them anyway. The admin knows what's configured. They don't always know what's still used. And those are two very different lists. That's why you pull call detail records ninety days at least. Every call in every call out, every internal hop. And then you compare what the system says exists against what people actually dial. You'll find extensions with zero calls, handsets nobody has touched since the team moved floors. But you'll also find the opposite, and that's the more useful finding a number that looks dead with one inbound call every month. And that one call is the supplier who triggers a payment run, or the regulator's line or the alarm company. Checking in ninety days catches. Most of this quarter end and year end behavior can hide outside the window. So ask the business what only happens once a year. Somebody always knows. Now you have a list of numbers. And here's the problem. A number on its own tells you nothing. Every number has a reason to exist, a person behind it or a process. And many have neither. They're orphans. Somebody set them up, left the company, and the line kept running because nobody dared turn it off. So you find owners for every number. Ask one question who is hurt? If this stops working, say the answer out loud. If it's a name, write the name down. If it's a department, find a person in it. If the answer is nobody, that's a decision too. But make it on purpose and get it signed off. This part is slow. It involves email chains and awkward meetings. It's also the cheapest work in the whole project. Every orphan you resolve now is one fewer surprise during the port. Next integrations. Because the PBX didn't sit alone, it talked to other systems, and those conversations were never documented as conversations. There were just things that worked. A CRM pops a customer record. When a call arrives. Somebody built that with a CTI link years ago. Voicemail lands in a mailbox as an audio file and the team depends on it. The warehouse paging system takes a trigger from the phone platform, a pharmacy, a clinic, a hotel, front desk, a security gate. Each one has a quiet connection back to the PBX. Ask three groups the people who run the applications, the people who run the facilities, and the people who answer the phones. They'll each name something the other two forgot and ask the vendor. Pull the integration list from the PBX contract. Look at licensed modules, add ons, and anything with an API key. If the license mentions it, something uses it. Now you're holding a lot of paper numbers, owners, usage figures, integrations, odd devices. If it stays scattered, it gets lost by week three. So build one artifact a number to purpose. Register one row per number or per range, and a short set of columns that never changes the number. The type, whether that's a user line, a shared line, a queue, an analog device, or something special, the owner, what it's used for, call volume from the records, any integration attached, and the target in teams, which stays blank for now. That last column matters because later every design decision lands in this register. Which model carries the number, which site it ports with, which wave it moves in, which test proves it works. This document survives the whole project. It feeds the porting request. It feeds the cutover plan. It feeds the decommissioned checklist at the end when you have to prove nothing. Still depends on the old box, so treat it as the source of truth, not a side note and a rule for it. If a number isn't in the register, it doesn't move. That sounds harsh, but it forces the question early while there's still time to answer it. With the estate counted, you know what you're connecting. Which leaves the first big design decision how teams reaches the public phone network at all the three connectivity models at a glance. Teams can't call a mobile phone on its own. It can call other teams users. That's it. To reach anyone on the public phone network, it needs a bridge. Microsoft gives you three ways to build one calling plans operator connect direct routing, three names, three product pages, three sets of marketing. Let's skip the product pages and look at the structure underneath. Each model answers the same four questions differently. Who owns the number? Who owns the trunk? Who owns the SBC and who picks up when you open a support ticket? Start with calling plans. Microsoft is the carrier. The numbers come from Microsoft. The trunk is Microsoft's. There's no SBC for you to run because the whole path sits inside their cloud. When something breaks, you open a ticket with one company. Now operator connect. A partner carrier is the carrier. That carrier has been certified by Microsoft and you switch them on inside teams. Admin numbers show up in your tenant assigned and managed from the same portal. The trunk belongs to the carrier the SBC belongs to, the carrier to, and they run it. You own the commercial relationship and the carrier owns the plumbing. Then direct routing. You bring the carrier any carrier you like, anywhere you like, and you bring the SBC, the session border controller, which is the device that sits between your carrier and Microsoft's SIP proxies. You own the routing logic. You own the certificates. When a call fails, you first have to work out which of four companies it's actually failing at. Now line those up with calling plans. You own almost nothing and depend on one vendor. With Operator Connect, you own the contract and the policy and the carrier owns the infrastructure. With direct routing, you own the design, the device, and the risk. That's the real shape of the choice. It isn't a feature comparison. Strip away the vendor language, and what's left is a trade between control and convenience. Every step toward more control gives you more things you can shape, and every one of those things is also something you now have to keep running. So here's the question to hold on to, not which model has the best features. That's the wrong frame. The better one is how much a voice do you want to be responsible for? Calling plans takes responsibility off your plate. Direct routing puts it on your plate on purpose. Operator connect sits in between handing off the heavy parts while you keep the commercial lever. One more point and it gets missed a lot. You don't have to pick just one. Many tenants run two or more at the same time. That's not a sign of a messy design. It's usually a sign of an honest one. Think about a company with a head office, a few branch sites and operations in six countries. Calling plans might cover a small office in a country where Microsoft sells numbers and where nobody needs anything unusual. Operator connect might cover the main regions where a carrier already holds the contract. Direct routing might cover the one site with legacy equipment or the country where no certified carrier exists. Each region gets the model that fits its constraints. Same tenant. Same users. Same teams. Client on the screen. The difference lives underneath in how the call leaves the building. That's fine. Teams roots by policy. A user in one country can use one model, and a user in another can use a different one with no visible change to either of them. But mixing has a cost, and it's worth naming up front. Every extra model adds another support path, another set of limits, another place to look when a call fails, mix because the facts demand it, not because each regional team wanted its own preference. That's the map. Three models. One question about ownership. Asked four ways the ability to combine them. As long as you can explain why. Now let's go through them one at a time. We start with the simplest because its limits tell you a lot about why the other two exist. Calling plans, simplicity and where it stops calling plans is the model with the shortest path. You buy a license. Microsoft gives the user a number and a bucket of minutes. That's the whole design. No SBC, no carrier contract, no certificates to renew. If a call fails, you open one ticket with one company and nobody can point at a different vendor. For a lot of sites, that's exactly what you want. But the real constraint isn't the product, it's the map. Microsoft sells calling plans in a limited set of countries. Inside each country. It sells a limited set of number types, local geographic numbers, maybe toll free in some places. Other types? Not at all. Before you design anything, you check two lists where Microsoft can supply numbers and which kinds. If your country or your number type isn't on the list, the conversation ends there. No amount of good planning fixes it. Then there are the minutes. Calling plans come with a domestic bucket and in some regions, an international one as well. Those buckets are pooled across the tenant and they're sized per license. A quiet office never touches the limit. A busy outbound team burns through it. You pull the usage from your call records, the ones you gathered in discovery, and compare them against what the licenses give you. If the numbers don't fit, you either buy more or you pick a different model. Now porting. You can bring existing numbers into calling plans, but Microsoft only accepts certain number types, and it rejects the rest. Plain geographic numbers on a clean account usually go through special ranges, unusual formats, and numbers sitting on a complicated carrier arrangement are where requests bounce. Check the register. Every number needs a type, and every type needs a yes or a no before you promise anyone a date. So where does this model fit? Small sites. A ten person branch office that just needs a number and a dial tone. Countries where you have a handful of users and no reason to sign a local carrier contract. Greenfield locations where there's no old PBX to coexist with pilots because you can have a user calling the outside world in an afternoon, which makes it a fast way to test the client, the network, and the user experience before you commit to anything bigger. That's also how you spot where it breaks. It breaks when legacy equipment has to stay connected. A calling plan's path has no place to plug in an analog gateway or a retained PBX. It breaks with special numbers, the short codes and service lines that only a carrier can provision. It breaks with odd call patterns, like a site that sends a burst of calls at the same minute every morning. It breaks with high volume outbound, where the minute bucket stops being a number on a page and starts being a bill. Notice what those have in common. Each one is a place where you need to shape the call path, and calling plans doesn't let you shape it. That's the price of the simplicity. You gave up control and you got one ticket in return. For many organizations, that's a fair trade. For others, it only works in some places. Which brings up the obvious next question if Microsoft isn't going to be your carrier, can somebody else be without you having to build the plumbing yourself? That's what Operator Connect is for. Operator connect carrier managed integration operator connect moves the plumbing to someone who already has it. Here's how it works. Microsoft certifies a carrier. That carrier appears in a list inside teams admin. You pick them, accept the terms, and the carrier does the rest on their side. Then numbers show up in your tenant. You assign them to users from the same portal you already use for everything else. No SIP trunk to configure, no certificates to chase from the admin seat. It feels like a feature you switched on. And behind that switch, the carrier owns a lot. They run the Sbcs. They build the trunks into Microsoft's cloud, and they decide how those trunks stay up. When a link fails, they manage the number lifecycle two ordering, porting, releasing, and moving numbers between sites. In many cases, they also handle the media paths, including bypass, so audio takes a shorter route than it would through a central hub. That's the handoff. You keep the policy and the users. The carrier keeps the infrastructure. Now the commercial angle because it's often what decides this. Most organizations already have a carrier, a contract, a rate card, a named account manager, and years of history on the invoices. Operator connect lets you keep that relationship if your carrier is certified. Same company, same commercial terms. New integration point. And if you operate in several countries, a carrier with local presence can often cover them under one agreement with local numbers and local support teams. That matters more than it sounds. A local carrier knows the local porting rules, they know which number ranges behave oddly and which regulator wants which form. You're paying for that knowledge as much as for the minutes. But there are limits and you inherit all of them. You get the carriers pace. If Microsoft ships a new calling capability, the carrier has to support it before you can use it. Some do that quickly, others take quarters. You get the carriers feature set. Not every certified carrier offers every capability, and the differences are rarely on the first page of the proposal. So ask directly which number types can you provision? Which emergency calling options do you support? How do you handle a failed trunk and you get the carriers country list certification is per carrier and coverage is per country. A provider may be strong in Europe and absent in Southeast Asia, so check the map against your register location by location before you build a plan around one name. There's also a quieter limit. Because the carrier runs the SBC, you can't shape the call path. Need to hang a legacy PBX off the same trunk? Need an unusual number format or a custom routing rule for one odd site. That's usually where Operator Connect runs out of road. You're working inside the carrier's design, and the carrier's design is built to suit most customers, not yours specifically. So when does it win? It wins when you have a multi country estate and you want carrier level support without staffing a SIP team, it wins. When you already trust a certified carrier and your needs are ordinary users cuz auto attendants and standard numbers. And it wins when the people who run voice day to day are Microsoft three hundred sixty five admins, not telecom engineers. That's a big group. A lot of organizations fit that description, but some don't. Some have a retained PBX that has to live alongside teams for two years. Some have a country with no certified carrier. Some have routing rules that no standard product will express. For those, handing off the plumbing isn't an option. You need to hold it yourself. And that's direct routing, direct routing control, and the price of control. Direct routing is the model where you own the path. Here's the definition. You have an SBC. You have one or more SIP trunks from a carrier you chose, and you have routing logic that decides where each call goes. Your SBC connects to Microsoft's SAP proxies and teams hands calls across that link. That's the whole design. Three pieces you control, joined by SIP. So what does that control buy you? First custom routing. You can send calls to different carriers by destination, by time of day or by cost. Second coexistence a retained PBX can connect to the SBC, which means teams and the old system can share numbers during a long migration. Third, unusual number formats, special service codes, and odd dial patterns that no standard product expects. And fourth, tight policy. You decide what crosses the border and what gets blocked there. Every one of those is a place where calling plans and operator Connect said no. Direct routing says yes if you can build it and that if is the price. 00:17:10 Speaker: Start with certificates. The SBC needs a public certificate from an approved authority matched to a name. Microsoft can verify it expires, somebody has to renew it. And if nobody does call, stop. Not slowly. At the moment of expiry, then the heartbeat. Microsoft's proxies send SIP options pings to your SBC and your SBC answers. If those pings fail, teams marks the route as down and calls go elsewhere or nowhere. So the firewall has to allow the right traffic from the right addresses in both directions. One wrong rule and the trunk looks dead while everything else looks fine. Then patching an SBC is a security border facing the public internet. It needs firmware updates and updates need a maintenance window and maintenance windows. Need someone who knows what a failed update looks like at two a m, and that points at the real cost. You need people who understand SIP not teams admins, not network generalists. People who can read a SIP, trace, spot a bad header, and explain to a carrier why their invite is being rejected. If you don't have them, you hire them or you rent them. Which brings up the choice. Nobody likes to make early hosted SBC or self-managed with a self-managed SBC. The box is yours, physical or virtual, in your data center or your cloud. You hold the configuration, the certificates, the patching, and the capacity planning. You get the most freedom and the most work. With a hosted SBC, a provider runs the device for you often in their cloud, often with a managed service wrapped around it. You still own the routing decisions and you still pick the carrier, but somebody else renews the certificate and applies the patch. Same direct routing, very different weekends. Now the trap, it's called shared responsibility and it catches teams who assume that Microsoft supports it means the whole path is covered. It doesn't. Microsoft supports teams. Microsoft supports its own SIP proxies. Microsoft does not support your SBC, and it does not support your carrier. So when a call fails, here's what actually happens. You open a ticket with Microsoft. They check their site and it's healthy. They tell you politely that the problem is elsewhere. You open a ticket with the SBC vendor. They ask for logs, the logs point at the carrier. The carrier says the call never reached them in the right format for parties, and each has a reasonable answer that ends with not us. Somebody has to own the whole path. A named team with access to every log and the standing to chase every vendor. If that person doesn't exist on day one, they get invented during the first major outage. That's the honest picture of direct routing. It's the most flexible model and the only one that fits every odd case. But flexibility isn't free. You pay for it in skills, in tooling and in accountability. So you have three models and three different answers to who carries the risk. The question now is how to choose between them without guessing. Choosing the model. A decision framework for questions. Decide this. Ask them in order. The order matters. Question one where are the users? Not where the head office is. Where the people sit country by country. Put your register next to the coverage lists. Can Microsoft supply numbers there? Does a certified carrier operate there? Some countries have both. Some have one and a few have neither. That single check removes options before you've debated anything. A country with no calling plans and no certified carrier is a direct routing country. The map makes the decision. Question two what are you replacing? Look at your discovery work. If the estate is users queues and standard numbers, you have flexibility. But if it includes analog gear, a retained PBX, odd number formats, or a contact center platform that needs a zip link. You've already narrowed the field. Those things need a place to plug in. Calling plans has no such place. Operator connect has one only if the carrier agrees to build it. Direct routing is where they connect without asking permission. Question three who runs voice day to day? Be honest here. Not who's supposed to. Who actually will at eight a m on a Tuesday when a trunk drops. If the answer is your Microsoft three hundred sixty five admins, they can run calling plans and operator connect. If the answer is a telecom team that reads SIP traces for fun, direct routing fits. And if the answer is we'll figure it out, then you've found a risk and no model solves it. Question four what must integrate recording platforms, CRM links, paging fraud controls. Each one is a requirement with an owner, and each narrows the options. Again, some work on every model. Some only work where you control the SBC. Now put the answers in sequence country first because it's a hard limit equipment. Second because it's a technical limit skills. Third, because it's a people limit risk. Last because it's what's left once the others have spoken. Notice what that sequence does. It stops the loudest opinion from winning. Nobody gets to say we should use direct routing because it's the most flexible before the map has been checked. Let's run a few patterns. A regulated business, say banking or healthcare recording is mandatory data location is audited. Call paths may need to stay inside certain borders. That pushes toward direct routing or toward a carrier under operator connect, who can prove the same controls in writing. Calling plans can work for the users who don't need recording, but rarely for all of them. A retail chain hundreds of small sites, each with an analog line for a card terminal or an alarm, plus a handful of corporate offices that are plain knowledge worker setups. Here, the split is natural operator connect or calling plans for the offices direct routing or gateway behind it. For the stores that carry the analog load, a global manufacturer plants in a dozen countries, each with its own carrier history, its own paging, its own lift phones. No single model covers all of it. Expect a mix with direct routing in the awkward plants and a certified carrier handling the regions where standard calling is enough. Now, the framing for the executive in the room you're not buying minutes. Minutes are a line on an invoice. What you're deciding is who carries the operational risk for voice under calling plans. Microsoft carries most of it, and you accept their limits. Under Operator Connect, the carrier carries the infrastructure and you accept theirs. Under direct routing. You carry it and you accept the cost of doing so. Put it to leadership in those terms, and the conversation changes from price to accountability. Last step right? The decision down, which model for which countries and why then, right. The exit path. If this choice stops working in three years, what does moving off it look like? Which numbers are portable? Which contracts have notice periods? Which parts are tied to one vendor? A decision with no exit path is a bet. A decision with one is a plan. And whichever model you land on, one thing is waiting for all of them. The number. It's the part users feel first and the part you control least. So next up is porting number porting. Why it's the critical path. Every project plan has a timeline. The port has its own. A number port is a regulatory process. It runs between carriers under rules set by national regulators, and your project manager has no say in the schedule. You can't escalate it, you can't add resources, you submit the request, and then you wait for two companies to agree that a number can change hands. That's the first thing to accept. Porting sits on the critical path, and it's the one task on that path you don't control. So how long does it take? It depends on the country, the carrier, and the number type. In some places, a clean request clears in days. In others it takes weeks. And for certain number types it can take longer. But the stated lead time is rarely the real one, because the stated time assumes a request that goes through the first time. Many don't request stretch for the same few reasons. The account data doesn't match what the losing carrier has on file. The letter of authorization gets rejected. A regional rule adds a step nobody mentioned each rejection restarts a clock and a two week port quietly becomes six. That's why you plan from the longest realistic lead time, not the shortest quoted one. Ask the carrier for their real numbers, not the brochure. Figure the one from last quarter's rejected requests. Now what does a request actually need for things? And all four have to be right. Account details, the account number, and any pin or reference on the current carrier's bill. The losing carrier checks these first, and a typo ends the conversation. An address match. The service address on the request has to match the address on the existing account. Not roughly exactly a suite number in one place and not the other is enough to bounce it. An authorized signer. Someone with the legal standing to approve the move. Who signs the letter of authorization. If the account was opened by a person who left in twenty fourteen, you now have to prove authority. Another way and a number list every number written out or expressed as a range tied to the right account. Notice where those four come from. Your register. If discovery found the owner, the account and the purpose for every line. This paperwork is an afternoon of copying. If it didn't, this is where you find out. Then there's the shape of the port itself. Three types matter. A full port moves every number on an account. Simple, because nothing stays behind. A partial port moves some numbers and leaves others on the old carrier. That's common during a wave migration, and it's where mistakes breed because someone has to track exactly which numbers went and which stayed and arranged. Port moves a block of consecutive numbers. The D I'd range your company has held for years. Ranges look tidy on paper. In practice they split. Say your range runs from one hundred to one nine nine nine and the first fifty belong to the office moving this month. The other fifty include the warehouse and the alarm line, and they're moving later. So you split the range and each fragment becomes its own request with its own date and its own risk of rejection. Every split is another thing to keep straight. Which fragment ports when? Which one carries which users, which one has a fallback. That's why the register matters so much. A range that look like one asset in the carriers records is really twelve different purposes in yours. So the process itself is clear. It's paperwork run by carriers on their clock with your data as the input. What isn't clear until you've lived it is how it fails, and it does fail in a handful of predictable ways. Porting failure modes and cutover windows most port rejections look boring. That's the problem. The most common one is a name or address mismatch. The request says contoso littered, and the carrier's record says Contoso Limited, or the address has a floor number in one system and not the other. Nobody argues about it. The request just comes back with a short reason code and the clock starts over. The second is numbers on the wrong account. Over the years, lines get added under whatever billing account was convenient. A branch office number sits under a contract. The finance team opened in twenty twelve. The request names the main account. The carrier can't find the number there and it bounces. The third is a pending order. If anyone has a change in flight on one of those numbers. A move a feature, add a cancellation. The port can't proceed until it clears and nobody remembers placing the order. Now the quieter failure, the forgotten line you port a d, I'd range and you list the numbers you know about. But the range included a few. You didn't. A fax line, a back door entry phone. Those numbers aren't in the request, so they stay behind on the old carrier. Then the old service ends and those lines go dead with it. A partial port that wasn't meant to be partial. That's why you reconcile the request against the register, line by line, before you submit, and then against the carrier's own records after. If the two lists disagree, you want to learn that now. Next, the date. Once the carrier confirms a port date, lock it. Everything else in the plan hangs from that date. Routing tested users briefed, floor walkers booked. Move it casually and you move all of those with it. If you're porting in waves, sequence them so no single date carries the whole estate. Put the simplest, lowest risk numbers first. Learn how that carrier behaves on port day. Then take the harder ones and for every wave, keep a rollback path. Know whether the numbers can be pointed back at the old carrier, how long that takes, and who has to ask now a question that catches teams off guard. What happens to an inbound call between the moment the port completes and the moment teams is ready to answer it? Here's what typically happens. The port lands. The number now belongs to the new carrier. But if routing isn't built and tested, a caller dials that number and gets silence or a fast busy, or a recording from the wrong system. Nothing is wrong with the port. It just finished before anything was there to receive it. So you don't treat port complete as the finish line. You treat it as the moment the load transfers. Before that date. User's voice routes, call queues and auto attendants have to be built and tested against the new numbers. Some carriers let you test with temporary numbers first. Use that if they do. The other half of the safety net is forwarding until the port lands. You can forward calls from the old PBX to the new teams numbers. A caller dials the old number. The PBX passes it along. Teams answers. Users can work in teams while the port is still pending and nobody outside notices. But forwarding has limits and you should name them early. Each forwarded call uses two channels on the old system, one in and one out, so a busy site can hit its trunk capacity sooner than expected. Caller ID can change on the way through depending on how the PBX presents it, and you've created a dependency on the old box that you now can't switch off. Forwarding is a bridge. It's not a destination. Treat it that way. Set an end date for the forward. Tie that date to the port and make someone responsible for removing it. A forwarding rule nobody owns has a way of living for years, so that's the shape of a port. Done. Carefully reconcile the list. Lock the date, build before the number moves forward until it lands. And with the numbers handled, there's the layer underneath that. Every single call depends on the network. Network readiness. The part everyone underestimates. Voice is a real time workload. Your network was built for something else. Email can arrive a second late. A file can pause and resume. A web page can stutter a. Nobody files a ticket, but a voice packet that arrives late is a voice packet that's gone and the caller hears a hole where a word used to be. That's the flaw in most readiness plans, they treat the network as a utility. It's there. It works. Tick the box. But the network was designed for best effort and voice needs something closer to a promise. So start with the floor bandwidth. A single team's call doesn't need much audio alone sits in the tens of kilobits per second, and you can look up the exact figures in Microsoft's planning guidance. That's why people wave this away. One call tiny number? No problem. But you're not planning for one call. You're planning for peak concurrency. How many people will be on a call at the same moment, at the busiest point of the busiest day? Take the number of calls, multiply it by the per call figure and add the video and screen sharing that now rides the same link. Then check it against what the site actually has, and you'll find that some sites are fine and some aren't. The ones that hurt first are rarely the head office. They are the small branches on a thin line shared between a card terminal, a backup job, and twenty people who've all just discovered video calls. Find those sites in the register and give them a name on the risk list. Now the part that breaks silently ports, addresses, and media paths. Teams need specific traffic to pass certain IP ranges, certain UDP and TCP ports in both directions. Microsoft publishes the list and it changes. And here's the problem with firewalls. They don't announce what they block. A call connects because signaling uses a port that's open. Then the audio, which uses a different port, gets dropped. The result is a call where one person hears nothing or a call that rings and never connects. Or one that works on Monday and not on Thursday. After a rule change, nobody connected to voice. Nobody's firewall team did anything wrong. They protected the network the way they were asked to, but nobody told them what a real time media path looks like. So a rule that made sense for web traffic quietly strangled the audio. So walk the media path on purpose from the user's device through the switch, the firewall, the proxy, if there is one out to Microsoft's edge at every hop, ask the same question does anything here treat this traffic differently from ordinary web traffic proxies and deep inspection devices are the usual culprits because they add delay, and delay is the one thing voice can't absorb and don't guess test. Microsoft provides a network assessment tool for exactly this. You run it from a machine on the side you're about to migrate. It simulates real call traffic measures, packet loss, jitter, and round trip time, and tells you whether the path meets the targets teams expects run it at different times of day. A network that passes at six a m can fail at ten. Once everyone's in, then go one step further before users ever touch a handset. Make test calls, real ones from the real sites over the real links to real mobile phones and landlines. Listen to them. A chart can say the numbers are fine and a human ear can still hear a problem the chart missed. Put that evidence in the plan for each site. Record the measured result and the date you took it. Because when someone says voice was bad after the migration, you want to be able to answer one question straight away. Was it bad before? That's what readiness means, not the network is probably fine. A measured result site by site with a clear list of the ones that need work. But passing a bandwidth test only tells you the road is wide enough. It doesn't tell you what happens when traffic gets heavy or who gets to go first. That's quality of service, and it's a discipline of its own. Call quality by design shows WiFi and VPN. Quality of service starts with a label. Every voice packet can carry a marking. It's called Dscp. A small value in the packet header that says treat me as real time teams lets you set those values by workload. Audio gets one marking video gets another. Screen sharing gets a third. The idea is simple when a link gets crowded, devices read the label and let voice go first. But a label only works if every device along the path respects it. That's the catch. You mark the traffic at the source through policy, then it crosses the access switch, the distribution layer, the core, the Wan edge, the firewall, and all it takes is one hop that resets the value to zero. A switch port with a default setting. A one circuit where the carrier doesn't honor your markings. At that point, the label is gone. Voice is competing with a backup job as if nobody ever asked for priority. So you trace it end to end. Capture a call at the desk. Check the marking. Capture it again at the edge. If the value changes between the two, you found the hop. It's usually one device, and it's usually one nobody had touched in years. One on this node. Here, markings only help on networks you control once traffic leaves for the internet, nobody has to respect them. That's why the part inside your walls matters so much. It's the only part where you have a say. Now Wi-Fi, because a large share of your calls will start on a radio, not a cable. And a radio behaves very differently. A laptop on a dock to desk with a wired connection gets a steady path. The same laptop on WiFi in a meeting room two floors down gets a shared one. Other devices on the same channel take turns. Walls add loss, and when someone walks from one room to another, the device has to drop one access point and join the next. That's roaming for a data session. It's invisible for a call. It can be a half second of nothing right in the middle of a sentence. That's why a call that sounds perfect at the desk can fall apart on the way to the lift. Nothing broke, the conditions changed and voice noticed. So designed for it. Check coverage where people actually walk, not just where they sit. Stairwells, corridors, loading areas. Keep channel widths sensible because wider channels sound faster on a spec sheet, but leave less room in a crowded building. Use the five gigahertz band and six gigahertz where you have it for voice set roaming thresholds, so devices hand off before the signal gets weak, not after mobile users make this harder. Someone on a phone walking between a hotel lobby and a taxi is crossing three kinds of network in ten minutes. You can't engineer that path. What you can do is set expectations and make sure the client handles a network switch gracefully, then VPN. This is where good designs go to die. 00:34:35 Speaker: Here's what typically happens. A remote user connects to the corporate VPN for everything, including teams. All traffic enters a tunnel, travels to a central gateway, gets inspected, then heads out to the internet. Audio that could have gone straight to Microsoft now takes a detour through a data center, possibly in another country, that adds latency. It adds a device that can drop packets, and it puts every call on a gateway that was sized for email. The fix is split tunneling teams media traffic skips the tunnel and goes directly to Microsoft over the user's own connection. Everything else stays protected inside. Microsoft publishes the specific address ranges for it, marked as the ones to send direct. You route those and leave the rest alone. Security teams sometimes resist this, and the concern is fair, so make the case with specifics. You're not opening the whole internet. You're sending one narrow, well defined set of addresses straight to a trusted provider for traffic that's already encrypted. One more thing worth knowing teams adapts. When the path degrades, the client lowers its bit rate, switches codecs, conceals small gaps in the audio. So many problems sound like a slightly robotic voice instead of a dropped call. That's useful. It's also why users often live with poor quality for weeks before anyone files a ticket. Which brings up the real problem. A design is just a hypothesis, it says calls should sound fine. Monitoring is how you find out whether they do monitoring and quality operations. Microsoft gives you two tools for this and they answer two different questions. Call analytics looks at one call. A user says, my call was bad at ten past two. You open that user, find that call, see what happened to it, which device, which network, which path, whether the audio degraded and where. Along the way, the call quality dashboard looks at everything. Thousands of calls grouped by building subnet, device type and time of day. It doesn't tell you what happened to Maria at ten past two. It tells you that every call from the third floor of the Leeds office sounds worse after lunch. So one is a microscope and the other is a map. You need both because a single complaint could be a fluke, and a pattern in the data could hide behind an average. That looks fine. Now, which numbers matter? Three of them do most of the work. Jitter packet loss round trip time jitter is how uneven the packet arrival is. packet losses. How many never arrive at all? Round trip time is how long a packet takes to go out and come back. Microsoft publishes target values for each and teams marks a call as poor when it crosses them. You don't need to memorize the thresholds. You need to look at where the poor calls cluster because that's the useful finding, not the tenant wide average, which smooths everything out. The building level pattern. One site where loss spikes at the same hour every day. Probably a backup job. One subnet with high jitter. Probably a bad switch port or a Wi-Fi zone. One group of users on a certain headset model with echo complaints. Each cluster points at a cause you can actually fix, but none of that means anything without a starting point. So set a baseline during the pilot. Before you migrate a site, record what quality looks like for the pilot users on that network. Then after cutover, compare. Without that, you'll get a sentence like voice feels worse and no way to prove it. Either way, with it, you'll know whether the numbers moved and by how much. Sometimes the answer is that quality is the same as before, and the complaint is really about a changed handset. That's worth knowing to then build the triage path before go live, not during the first outage. A bad call has five possible owners the network, the SBC, the carrier, the endpoint. The users own environment. Like a weak home connection, each one needs a name team, and each team needs to know the order of questions. Start with scope. Is it one user, one site, or everyone one user points at the endpoint or their connection? One side points at the local network. Everyone on one number range points at the carrier or the SBC. Everyone everywhere points at something central, then direction. Does the audio fail both ways or only one one way? Audio is almost always a firewall or a media path problem. Two way trouble with robotic sound is usually loss or jitter, then time constant or at certain hours constant means a configuration problem. Certain hours means load, right those three questions on one page and give the page to whoever answers the first ticket. A service desk that can sort calls into the right bucket in two minutes saves hours of everyone's time because the alternative is a ticket passed between four teams, each one saying not mine, and name one owner for the whole path. Someone who can open every dashboard and chase every vendor in a direct routing design that matters most. Because the next component, the one where a lot of those tickets end up belongs to you, the SBC. SBC design what the box is really for. People call it a box. It's closer to a border. A session border controller sits at the edge of your voice network between your carrier, your legacy systems, and Microsoft's Cloud. It does four jobs at once. First, signaling translation your carrier speaks, sip in one dialect team speaks it in another. Your old PBX speaks a third. The SBC sits in the middle and rewrites headers, number, formats, and codecs so each side hears what it expects. When people say a trunk just works, this is the work they're not seeing. Second media handling it anchors the audio. In some designs. It transcodes between codecs, which costs processing power. Third security. It hides your internal addressing, rejects malformed traffic, and blocks the scanning and toll fraud that hit any SIP service facing the public internet. Fourth interop with whatever you refuse to retire the analog gateway, the retained PBX, the recording platform. So when someone asks whether you need an SBC, the real question is how many of those jobs your design needs. Under direct routing, all four. Now, which box Microsoft certifies from a short list of vendors tied to specific models and software versions. That list matters more than it looks. A certified model on an unsupported firmware build is, for support purposes, an uncertified device. Microsoft won't troubleshoot it, and the vendor may not either. And firmware drifts. Someone applies an update for an unrelated bug. The version slips off the certified list and nobody notices until the first serious ticket. Then the answer is upgrade or downgrade and call us back. So write the certified version into your build documentation and check it again before every patch. Next, the part that stops more projects than anything else. Names and certificates. Your SBC needs a fully qualified domain name, and that name has to sit inside a domain you've verified in your Microsoft three hundred sixty five tenant. It also needs a public certificate issued by an authority Microsoft trusts covering that name. Self-Signed won't work. A private internal authority won't work either. Team's checks the certificate on every connection, and if it fails, the trunk stays down. Plan the naming early one name per SBC or a shared name with a wild card and decide which. Then put the expiry date in a shared calendar with two owners and a reminder well ahead of it. Most certificate outages aren't technical failures, they're calendar failures. Then the trunk itself. You configure the SBC to talk to Microsoft's CPU proxies. A small set of named endpoints in different regions team sends calls to your species name. Your SBC sends calls back to the proxies. Both sides run a heartbeat. The SIP options exchange we covered earlier and both sides need to see it succeed. In teams, you register the SBC, build voice routes and link them to policies through PSTN usages that chain SBC to route to usage, to policy to user is where a lot of it's configured, but nothing happens. Problems hide one missing link and the call has nowhere to go. Last media bypass and local media optimization both sound like free wins. Both can bite. Media bypass lets the audio skip Microsoft's media processors and flow straight between the client and your SBC, shortening the path that cuts latency and saves a hop. But it only works if the client can reach the SBC's media address directly. So firewall rules, certificates, and network location all have to agree. Get one wrong and calls fail in ways that look unrelated. Local media optimization goes further for sites where the SBC sits far from Microsoft's edge. It keeps audio inside a region when both ends are local and sends only signaling to the cloud. Useful for big multi-site designs, confusing for small ones. So the rule is simple turn these on when you can name the problem they solve, not because they're in the menu, and all of this assumes one SBC working perfectly. One SBC is one failure. Waiting for a date. SBC resilience and topology. So how many sbcs do you actually need? Start with the first decision where they sit. You have two patterns a pair at every site or a pair in a few regional hubs that serve many sites. A pair at every site keeps audio local. A branch calls out through the box in its own building, so the path is short and a one. Failure doesn't take down local calling, but now you own a lot of boxes. Everyone needs a certificate, a patch window, and someone who knows its quirks. Regional hubs flip that trade. Fewer devices. Fewer certificates. Less to patch. But calls from a small site now travel to the hub and back, and that adds latency for a hub a few hundred kilometers away, you'll barely notice. For a hub on another continent, your users will, and so will the people they call. So the question isn't which pattern is better? It's how far is too far for your sites and your measured round trip times from the network work will tell you. Now inside each pair, a second choice active, active or active standby. In active standby, one box carries the load while the other waits. Simple to reason about, but you've bought a device that does nothing until the worst day, and you only learn it works when you need it. Test it. Pull the plug on purpose in a maintenance window and watch what happens in active active. Both boxes carry calls at the same time. You use what you paid for and a failure costs you half your capacity instead of all your redundancy. But that only works if each box can carry the full peak alone. If it can't. You've built a pair that survives a failure on a quiet day and collapses on a busy one. And here's the part that surprises people. The SBC pair isn't the thing that decides where a call goes when one box dies. Teams does. You define voice routes and each route lists Sbcs in priority order. When a call needs to go out, teams tries the SBC in the list. If that one is down because the heartbeat failed or the SBC rejected the call, it tries the next. That's why the heartbeat matters so much. It's how teams know the box is gone. So your route design is your failover design. List the sbcs in the order you want and check that every route has a second option. One thing to know here. When teams moves to the SBC, an in-progress call on the failed box drops the caller Redials and the new call goes through the other box. Failover protects the next call, not the current one. Set that expectation with the people who run the phones next. The trunks behind the Sbcs multiple trunks are standard, but multiple trunks from the same carrier riding the same fiber into the same exchange are one trunk with extra paperwork. Real carrier diversity means a second carrier, or at least a different physical path and a different point of presence. So ask what carrier failure actually looks like. Usually it isn't a clean outage, it's partial. Some destinations fail while others work. Calls connect, then drop. After a minute, caller ID arrives garbled, a trunk group is up, but one number range returns errors. Your routing needs to handle that, which means rules based on failure codes, not just on whether the link is alive. If the first carrier rejects a call, the SBC should retry through the second. Otherwise, the first sign of trouble is a user's complaint, then capacity. This is where designs get quietly undersized. Start with peak concurrent calls, not total users. Take your busiest hour from the call records, add growth and add the calls that will move over from the old PBX. Then check each box against that number with one box down. Next transcoding. If your carrier uses one codec and teams uses another, the SBC converts every call between them and that burns processing power. A box that handles a few hundred calls without transcoding might handle far fewer with it. Ask the vendor for the figure with your codec mix, not the headline number from the datasheet and licensing many Sbcs cap concurrent sessions by license, not by hardware. The box can do more, but the license says no and the call fails at the limit, right? The ceiling next to the peak and put the renewal in the same calendar as the certificates. Do all of that and you have a voice path that survives a bad day, but a path that carries calls doesn't yet carry a promise. There's one kind of call where getting it wrong has legal weight, and that's emergency calling, emergency calling the non-negotiable layer. Every other feature in this project can fail and someone gets annoyed. This one can fail and someone gets hurt. Start with the obligation. When a person dials an emergency number, the call has to reach the right responder, and that responder has to know where the person is, not roughly where to send the ambulance. That second part, the location, is what the rules care about, and the rules differ by country. In some places they differ by state or by region within a country. Some require a location tied to a specific floor or room. Some require that the call connect to the right local dispatch center, not a national one. And some countries are still working out what the rules should be for cloud calling. So there's no single standard to meet. There's a standard for each place you operate and your register needs a column for it. Now, why does teams make this harder than the PBX did because PBX had a fixed address. A desk phone was plugged into a wall in a room in a building. Someone mapped that port to a location years ago, and every call from it carried the same answer. The phone never moved, so the location never had to. Teams breaks that link. A user's number follows their identity, not a socket. The same person can place a call from a desk at nine, a meeting room at eleven, a client's office at two, and a kitchen table at six. Same number for locations. And the responder only gets the one the system believes in. That's the flaw to design around. The question was never what's the user's address? It's where is this user right now? And how does teams know? Teams has a few ways to answer that. First, emergency addresses. These are validated civic addresses that you create in teams admin. And they can include a floor or a room as well as the street. You assign one to a user or to a number so that it travels with the call. Second, network based location you build a map of your network using subnets, switches, ports, and wireless access points and tie each one to an address. When a client connects from a mapped subnet, teams recognizes where it is and uses the matching address no matter whose laptop it is. Someone docks in a different building and the location changes with them automatically. Third, what the user tells the client if the client can't find a match, the user may be prompted to confirm or enter where they are. That's the weakest option because it depends on a person doing the right thing in a bad moment. So the order of trust runs from the network down to the individual. And the whole design depends on how complete your network map is. A subnet nobody mapped is a location nobody knows. A guest WiFi range, a new branch, a VPN pool. Each one is a place where an emergency call falls back to a default address. That might be wrong, not missing wrong, and delivered with full confidence. Now the part that changes by connectivity model, the same call can take very different journeys with a calling plan. Microsoft is the carrier. Microsoft handles the routing to the right dispatch center in the countries it supports, and it handles the location handoff. You configure the addresses, and Microsoft carries the call with operator connect. The carrier does that work, which means the quality of emergency handling is whatever that carrier built. Some deliver full location data to the responder. Some deliver less, so ask them to show you how a call from your tenant reaches the dispatch center and what information arrives with it. Get that answer in writing with direct routing, you own it. Your SBC and your trunks carry the call, which means you also own the routing to the correct emergency service, the format of the location data, and the carrier's ability to pass it on. Many direct routing designs add a location information service or an emergency routing provider to do that part properly. It's one more thing to buy and one more thing that has to stay current. Notice the pattern. Every model gets you a working nine point nine nine or nine one one call on day one. The difference is in what the responder sees when it arrives. That's what separates an emergency design that was tested from one that was assumed. And the legal frame only sets the target. What counts is what you configure and how you prove it works. Emergency calling design and testing. Start with the emergency policy teams gives you two policies that matter here and they do different jobs. The calling policy decides what happens when someone dials an emergency number who gets notified, and how you can alert a security desk. A named group or a distribution list. And you can choose whether those people only get a message or can listen in. That's useful on a campus where the fastest help is often a guard walking down a corridor, not a crew on the road. The routing policy decides where the call goes, which numbers count as emergency, which route carries them, and which SBC or carrier handles them. And here's a rule worth repeating to every engineer on the project. Emergency routes get their own entry ahead of everything else. They never share a route with a general rule that could swallow them. Then there's dispatchable location. That means a location a responder can act on a street address alone isn't enough. In a tall building, the call has to say which floor and ideally which wing. So build your addresses to that level and treat the missing floor as a defect, not a nicety. Now, the people who aren't in your buildings remote workers, a home user, places a call from a kitchen and the network map knows nothing about that kitchen. So the client either falls back to the address you assigned or asks the user. And that's where the policy has to be honest with them. Tell them in plain words that the location team sends is the one they've confirmed. If they've moved, they must update it. If they travel, same rule. Put that in the onboarding message and again, in a short pop up, they'll actually read because a worker who set an address at hire and then moved house has a number that points at the wrong city. Some organizations go further. They restrict calling for users who haven't confirmed a location that's a legitimate choice and a heavy one. So decided on purpose. Next testing. And this is where teams make a quiet, serious mistake. You cannot test emergency calling by dialing the emergency number. A live call to a real dispatch center ties up a real responder, and in many places, it breaks the law. Even a hang up can trigger a dispatch, so don't improvise. Instead, use the provider. Most carriers and emergency routing services offer a sanctioned way to test. Some give you a test number that mimics the path. Some. Schedule a window with the dispatch center so they expect your call. Ask for it by name early because the lead time is often a week or more. Then test from each kind of place a mapped desk, a meeting room, a guest network, a VPN session, a home address, and for each check the record, the provider returns because the proof isn't that the call connected. The proof is that the right address arrived with it. Run those tests again. After any change to the network map the SBC or the carrier. An emergency design that passed in March says nothing about June, and now the part nobody wants to write the failure run book. What happens when the SBC is down? Does the route fall through to a second box or to a calling plan fallback, or to nothing? What happens when the carrier fails? Who finds out and how fast? What happens when a user's location is wrong because the map is stale or the person never updated it, who corrects it? And how does anyone learn it was wrong before the day? It matters, right? Each answer down with an owner and a way to alert them. Then put one more thing in the run. Book a plain language fallback for users. If teams can't place the call, use the mobile phone. And here's the number. People forget that a handset in a pocket still works when everything else doesn't. That's emergency design done well, mapped, tested with permission, and written down for the worst day. Which leaves the things people actually hold in their hands every day devices, desk, phones, headsets and rooms. 00:52:20 Speaker: Start with a simple question what will people actually be holding on Monday morning? Teams devices fall into four groups desk phones, headsets, speakerphones and room systems. Each one has a certified list and the list matters. A certified device has been tested against teams, signs in with a code or a tap, and gets managed from the admin center. An uncertified one may ring and then behave strangely on hold, transfer or voicemail, so buy from the list and check the model number, not just the brand desk phones first, because that's where the emotion lives. Someone has used the same handset for twelve years. They know where the transfer button is without looking. They know what the light means. Then you hand them a new device with a touch screen and a different way to park a call. Nothing is broken, but the muscle memory is gone. And to that person, the whole project just got personal. So treat the handset as a change, not a swap. Put the new device in their hands during the pilot, give them a one page card for the three things they do all day. Answer transfer and put on hold. Don't explain every button, cover what they actually use and let the rest wait and be honest about who needs a desk phone at all. A lot of people don't. A headset and the laptop will do and it costs less. But some roles do need the handset reception, warehouse desks. Anyone who works in a place where a laptop isn't always open, look at your call records. Find who really takes calls all day and size the hardware to that group. Headsets matter more than most plans admit, because audio quality, the thing users judge the whole project on depends on the microphone as much as the network. A cheap headset with a poor mic makes a perfect connection sound bad, and a laptop's built in mic in an open office is a complaint waiting to happen. So pick a few certified headsets, wired and wireless, and let people choose from that shortlist. Too many models and your help desk can't support any of them. Then the shared spaces, these are the devices nobody owns and the ones that quietly fail. A common area phone sits in a corridor, a break room or a lab. No person signs in. It has its own number and its own policy, usually with tight limits on what it can dial. A reception desk is different. Again, the receptionist needs to see who's calling, handle several calls at once, and pass them along fast. In teams, that often means a mix of delegation, call queues and a handset with a busy lamp display. Build that setup with the receptionist in the room. They'll find the gaps in ten minutes. Shared line patterns come up here, too. In the old world, three people picked up the same line on three desks. Teams does this differently and will cover how in the features section for devices. The point is simpler. Decide early which handsets are personal and which are shared. Because the sign in model is different for each. Meeting rooms are a separate category. Room systems with a screen, a camera and a speaker bar are built for meetings. They can place calls, but most teams don't want people dialing out from a conference table. So decide whether room devices get a phone license. And if they do what they're allowed to call. Now, the part that decides whether you can run any of this management, every device should be visible in the teams admin center. You see the model, the firmware, the sign in state, and whether it's healthy firmware needs a plan. Updates arrive on the vendor's schedule and a bad one can break a whole floor. So update a small ring first, wait a few days, then roll out wider the same way you'd treat any software provisioning needs a plan two some devices sign in by hand with a code on the screen. That's fine for ten phones and painful for six hundred. Many vendors support zero touch setup where the device finds the tenant when it boots, ask about it before you order, which covers the devices that were built for teams. But a lot of what hangs off your phone system was built long before it, and it doesn't speak any of this analog legacy and special devices. Every building has a few phones nobody mentions in the project. Kick off a fax machine in finance, a door entry panel that rings a desk, a lift phone that dials out when someone's stuck, an alarm dialer that calls a monitoring company. If smoke is detected overhead. Paging in the warehouse. None of them are people. None of them have a teams license, and all of them were wired to the old PBX on analog ports years before anyone on today's team joined. They don't care about your migration, they just stop working. So what are the supported paths? The first is the analog telephone adapter, or ATA, a small box that sits between an analog device and the network and talks SIP on the other side teams supports certain certified Atas, and in that setup, the device registers as an analog extension tied to a team's account that covers a lot of simple cases a basic handset in the stockroom, a phone in a lab. The second is an analog gateway, which is built for volume. Instead of one port, you get dozens and it connects to your SPC or sits behind it. It's the usual answer when you've got forty analog lines in a building and you'd rather not buy forty adapters. But here's the caveat, and it's a big one. Analog is not one thing. A fax machine expects a clean, steady line and a specific protocol. A lift phone expects a particular tone and a particular behavior. When the call drops, an alarm dialer sends data tones, and those tones can get mangled by a codec or a network hop that works fine for speech. Voice survives compression. Data tones often don't. That's why fax is the classic trap. People assume it'll work over the new path because the call connects. Then pages arrive garbled or half sent. Or not at all. If you have to keep fax, test it from the real machine on the real route with a real document and ask whether it's worth the effort. Many teams find they can move to a secure email based service and drop the machine entirely. Life safety devices are different. A lift phone, a fire alarm dialer, a refuge point. These come with rules and often with a certificate that says the system was tested and approved. Change the path and the certificate may no longer apply, so don't touch them on your own timeline. Bring in the facilities team, the installer, and whoever signs off on compliance and agree the plan with them first, which leads to a decision. A lot of teams resist. Some devices should stay where they are. If a handful of analog lines carry alarms and door entry, you don't have to force them through teams. You can keep a small PBX or a standalone gateway just for those. It connects to the carrier on its own lines or to your SBC through a SIP trunk, and it runs quietly in the corner. Less elegant? Yes, but it's cheaper than re-engineering twenty devices and far safer than guessing. That's coexistence. And it needs a plan. Which numbers stay behind, which box carries them, who looks after it, and when it gets reviewed. Otherwise, a temporary leftover becomes a permanent unowned system, and in five years someone finds it humming in a cupboard. And that points to the real rule decommissioning needs discipline. Every device in your register gets three things before you switch anything off an owner, a replacement path, and a date. The owner is the person or team who'll notice if it stops the replacement path. Says what takes over a new ETA, a gateway port, a different technology, or a deliberate decision to retire it. And the date is when it moves. No owner, no shutdown if nobody will claim a line, find out why before you cut it. Sometimes the answer is that nobody needs it. Sometimes it's the line the building depends on. So those are the odd devices handled on purpose, which leaves the behaviors people rely on without ever thinking about them. Until one day the button isn't there. Call features mapping PBX behavior to teams. Nobody ever filed a request for Call Park. It just existed. Somebody used it in twenty fourteen, showed a colleague, and now half the warehouse depends on it. That's what features are in a PBX habits with a button attached. So the job isn't a feature checklist. It's asking for each habit. What does teams do instead? Start with the front door menus and hunt groups. On the old system, a caller dialed the main number, heard press one for sales, and a hunt group rang a list of phones in order. In teams. Two things replace that. The auto attendant handles the menu, the greeting, and the business hours. The call queue handles the waiting and decides who rings and how. The auto attendant is where your old night mode goes open hours, closed hours, holiday schedules, each with its own greeting and its own route. Build those schedules from what the PBX actually did, not from what someone remembers. Pull the config. People forget the Friday afternoon rule. The call queue is the Hunt Group's replacement and it has choices. The old box didn't ring everyone at once, ring in turn, or ring whoever has been idle longest. Set a timeout and decide where the call goes when nobody answers voicemail. Another cue a mobile. That last one gets skipped and it's the one callers notice, but hold one line. A call queue is built for small teams sharing a number, not for a contact center. We'll get to that shortly. Now the pattern every executive office has boss and assistant on the PBX. The boss's line also rang on the assistant's phone and the assistant could pick it up, screen it, or place a call on the boss's behalf. In teams. That's delegation. The boss names the assistant. The assistant gets permission to answer and make calls for them, and the calls ring both. Add simultaneous ring for a mobile and you've got most of the old behavior. Shared line appearances are the close cousin, a reception line that appears on three desks or a team line everyone can pick up. Team supports a shared line for a small group, and a delegate can answer it from their own device. It works, but it's not the same as a physical line key with a lamp, and users who expect the lamp will say so loudly. Then the quieter features voicemail goes to the cloud and arrives as a transcription in email. Most people like that once they notice it, but the old greeting, the old P and the old messages, none of that moves on its own. Decide what you'll migrate and tell people before they ask where their messages went. Music on hold is configurable, and it's a good example of a small thing that causes a big fuss. Pick a file. You have the right to play and pick one that doesn't sound like a hostage video call. Park lets you hold a call and any colleague can pick it up with a code. Teams has it. The code, the range and the retrieval method differ from the PBX, so the warehouse needs a new card on the wall. Group call pickup is the habit of answering a colleague's ringing phone from your own team's has call groups and a pick up option, but it's built around people, not extensions. So if your office worked by a team shouting I've got it across the room. Rebuild that with real groups and test it with the real team. Now honesty. Some of this doesn't map one for one. A few things will feel different or be gone. Busy lamp fields, key system line buttons. Certain forwarding rules with odd conditions. A feature the PBX vendor added in two thousand and nine that nobody can name. For each of these, you have three answers. Rebuild it another way, replace it with a better habit, or retire it with the owner's knowledge and explain the change in terms people care about. Not teams. Users call groups say when someone's phone rings and you want it, here's how you take it. Now show the action. Skip the architecture. One more point worth noting test features with the people who use them every day. The IT team will confirm the Q rings. The receptionist will tell you it rings in the wrong order. Which brings up the place where all of this runs out of road, where calls aren't a convenience. They're the business contact center where teams phone alone falls short. Teams phone was built for a knowledge worker, someone with a name, a desk, and a number. They make calls, take calls and move on. That's the design and it's good at it. A contact center isn't that. It's a group of people handling thousands of calls an hour where the call itself is the product, and nobody in that room cares how nicely teams handles a transfer. They care whether the queue is moving. So here's the claim team's phone by itself is not a contact center. Call queues will ring a team. They won't run a floor. What does a floor need? Start with skills based routing. A caller says they want to talk about a billing dispute in German. The system has to find an agent who handles billing, speaks German and is free right now, not the next person on the list. The right one. A call queue can ring a group. It can't match a call to a skill and weigh it against wait time. Then queue reporting. A supervisor needs to see live how many callers are waiting, how long the longest has waited, and how many agents are free. And afterwards the history service levels, abandoned rates, average handle time. These aren't nice extras. They're how a contact center proves it's meeting its contracts, then supervision. A team leader needs to listen in on a call, whisper advice to an agent, or step in. That's how new agents learn and how problems get caught. Then recording every call stored, searchable, tied to the customer record kept for a set time and workforce management forecasting call volume, building shifts. Tracking who's on break. That sounds dull until you're short. Six agents on a Monday and nobody saw it coming. So the PBX never told you this. The old system, or more often, a separate contact center platform bolted onto it, quietly covered all of that, and now someone has to decide what replaces it. You have three broad options. The first is a team certified contact center solution. These plug into teams so agents work inside the app they already use, and the platform handles routing, reporting and recording on top. Several vendors sell these and they differ a lot. So ask for a live demo with your call flows, not a slide deck. The second is a dynamics based option. If you already run dynamics three hundred sixty five for customer service, Microsoft's own contact center product sits close to it. Customer records cases, and calls live in one place that's attractive when the data is already there. The third is a third party platform connected to your voice path over direct routing or operator Connect. This is the choice many large operations make because they already run one. The contact center stays as it is and the voice trunk moves underneath it. Let's change for the agents and more integration work for you. None of these is the wrong answer. Each one trades cost change and control differently. What matters is that you choose on purpose and early. Because here's what usually happens. In most organizations, the contact center is treated as one work stream among twenty align in the plan that says migrate call queues. Then someone asks in month five about skills routing and the room goes quiet. That's why it's the most common blocker in these migrations. Not because it's technically impossible, but because it carries contracts, compliance rules, and a team of agents whose daily work depends on it. You can't move it on a quiet Saturday. A bad cut over here shows up as unanswered customers and a headline. So give it its own timeline, its own owner, its own pilot with real agents and real call volumes run separately from the knowledge worker rollout. Start the vendor selection before the rest of the design is final, because procurement alone can take months and expect the contact center to finish on a different date than everyone else. That's not a delay. That's the plan working. One more thing to settle early. Who speaks for the contact center in the program? Not it. The head of customer service or whoever answers when the contracts are breached. If they aren't in the room, nobody can say what good looks like for their agents. And whichever platform you pick, two things come with it. Every call may need to be recorded for rules or for training, and the platform has to connect to the systems your agents already use. Both of those carry their own requirements. Recording compliance and integrations. Start with recording because it's the requirement that shows up with a lawyer attached. Some roles have to be recorded. Traders, advisors who give financial guidance. Anyone whose calls count as evidence of what was promised. For those people, the rule isn't record when convenient. It's every call kept for a set period and retrievable. When a regulator asks teams has a built in recording feature. It's meant for meetings and training, and the person recording controls it. That's the problem. Compliance recording can't depend on someone pressing a button. So teams offers a separate model, a policy assigned to a user which pulls a certified recording partner into every call that user makes or takes. The user doesn't choose. The recorder is simply there. That partner is a third party product, and it has to be on Microsoft's certified list, which means a new contract, a new bot in the call path, and a new place where your most sensitive audio is stored. Treat it like a core system, not an add on. Then the retention rules. Seven years in one sector, five in another, shorter in places where privacy law pushes the other way, right the period next to each role and put an owner next to the period, someone has to be able to say who may listen to a recording, how access is logged, and how it gets deleted when time runs out. Now the second layer where the data actually lives. Call audio call metadata. Voicemail transcripts. Each one has a home and the homes aren't always the same country. Some regulated organizations must keep voice data inside a region. Others face rules on who can access it from outside. So ask three questions of every component in the path. Where is the data stored? Who can reach it and can it be held in the region the rules require? That includes the carrier, the SBC logs, and the recording partner, not just Microsoft. Your obligations don't stop at the edge of the tenant. Lawful intercept belongs in this conversation, too. In some countries, carriers must be able to hand over calls to authorities on request under a calling plan. Microsoft deals with that under Operator connect, the carrier does. Under direct routing, you may have obligations of your own depending on where you operate. Don't assume ask your legal team and your carrier and get the answer written down. Now the integrations, the ones nobody put on the list. Remember the register we built in discovery? This is where it pays off. Somewhere in it is a CRM that pops a customer record. When a call arrives, a click to dial button inside a ticketing tool. A script that emails voice mail to a shared mailbox. A paging system triggered by a certain extension. Each one was quietly wired to the PBX, and each one is about to lose its connection. You have a few ways to rebuild them. Many CRMs and line of business apps now have teams aware connectors, so click to dial and screen pop work through the teams client. Others need an API and a developer to write against it, and a few depend on the PBX own protocol, which teams doesn't speak. So they need a bridge, a replacement, or a retirement. So for each one, ask the same two questions. Does the business still need it? And if so, what's the supported path? Don't promise a rebuild until someone has proved it works in a test with real data. Which brings us to the thing that ties all of this together ownership. Every requirement in this section needs a name next to it. Recording retention data. Location. Intercept each integration. Not a team, a person. Because the failure here is rarely technical, it's that nobody remembered the requirement existed until the weekend of cutover, when a compliance officer asks where the recordings are going and the room goes silent. So walk the register line by line before the pilot put an owner against each requirement. Then ask each owner one thing what would you check to know? It works. That's the end of the design work. The components are chosen, the risks have names, and the plan has something to stand on. What it doesn't have yet is a shape. And the way to get one is to start small on purpose with a pilot. Pilot design. Learning on purpose. A pilot has one job. It's there to find out what you got wrong. While being wrong is still cheap, most teams run it as something else a demo, a proof that the project is on track. So they pick the people who'll say yes, which usually means the IT team, a few friendly managers and anyone who owns a good headset. Calls go through. Everyone smiles and the pilot gets marked green. Then the real rollout hits a warehouse desk, a reception line, and a finance team that still sends faxes. And the pilot taught you nothing about any of them. That's the flaw. The pilot group was chosen for comfort, not coverage. So pick people by call pattern. Look at the records from discovery and find the shapes. Someone who takes forty short calls a day, someone who lives on a mobile and rarely sits down. An assistant who answers for three executives. A receptionist. A person who works from a kitchen table. Each one stresses a different part of the design, and you want all of those parts stressed before anyone else is affected. 01:09:45 Speaker: AIM for a group that's small enough to support by hand and varied enough to surprise you. Twenty to fifty people is a common range, though the right number depends on how different your state is. Now success criteria and the rule is simple. Write them before the pilot starts because once the calls begin, every result can be argued either way. A few dropped calls become teething problems or a real defect, depending on who's in the meeting and how much they want to ship. So fix the bar in advance. A quality target measured from the monitoring tools. We just covered a list of features that must work, taken from your mapping exercise. A sentiment check which can be as plain as a two question survey at the end of week one and week three, and make the criteria binary where you can emergency test calls delivered the right address, yes or no. Inbound calls to the ported test numbers arrived. Yes or no. Queue behavior matched the old hunt group. Yes or no? A pilot that ends in mostly fine hasn't ended. Then put a few deliberate traps in the group. First one side with a hard network. The branch on the weak link. The flaw with the old switches. The building where WiFi has always been a rumor. Every other site will have a better network than this one. So if voice holds here, you've learned something real. If it doesn't, you've learned it now with twenty users and not later with two thousand. Second, one person with a strange workflow. Someone who forwards calls to three places, shares a line with a colleague, and has a script nobody remembers writing. That's the user who finds the feature that doesn't map. You want to find that person. So go and ask who in each department has the oddest setup people usually know. Third, a real emergency test run under the arrangement with your provider that we discussed, not left for later. The pilot is the cheapest moment to find out the location data arrives wrong. Now how you capture what you learn. One register, one place every issue, whether it's a dropped call, a missing button, or a complaint about the handset, goes in the same list with an owner and a status. Not email threads. Not chat messages that scroll away a single shared register that the whole project can read, and review it weekly with the people who can actually fix things. Network voice help desk and the business owner for each affected team. Keep the meeting short for each open item, ask three things. Is it a defect, a gap, or a habit? Who owns the fix and does it block scaling? That last question matters most. Some issues are annoying and some are stoppers. A grumble about the ringtone isn't a stopper. A misrouted emergency addresses. Sort them honestly and keep a short list of what must be closed before the next wave. Also, watch the baseline pilot users are your before and after samples, so record their quality numbers early as we said. Then compare once they've moved. If the data and the stories disagree, trust neither alone. Go and sit with the user. When the criteria are met, the register is down to items that don't block, and the pilot group says they'd rather not go back. Then you've earned something, not permission to relax. Permission to scale. And scaling is its own decision with its own risks. One weekend, or many all numbers at once or in groups. A hard stop on the old system or a slow overlap. That choice is your cutover strategy. Cutover strategy. Big bang waves or coexistence three ways to move people off a phone system. Everything else is just a variation on one of them. You move everyone at once, you move them in groups, or you move some of them and leave the rest where they are on purpose. Start with the Big Bang. One weekend, one port Friday night. The old PBX is live and Monday morning it isn't. Every user, every number, every Q lands on teams at the same time. The case for it is real. You run two systems for a very short time, so you pay for two systems for a very short time. There's no awkward middle where half the company can call the other half only through a trunk and a prayer, and the project has a finish line people can see, but the price is risk and it's all in one place. If a number range didn't port, it's wrong for everyone. If the network chokes at the busiest site, the busiest site is the whole company, and the support desk faces every question from every user in the same hour. Big bang works for smaller states, single sites, and organizations with a clean register and a tested design. It fails for anyone still hoping now waves you group users and you move one group at a time. The grouping is a design choice, and there are three common ones by site. So one building moves and the next one waits by department. So finance goes, then sales, then operations or by call pattern. So the easy knowledge workers go first and the shared lines and queues go last. Waves give you something the Big Bang never does. You learn between them. Wave one finds a problem, you fix it and wave two doesn't hit it. The support load is spread out and if something goes wrong, the damage has a boundary. But waves bring their own trap and it's the number ranges. A block of one hundred numbers was probably handed out by department, not by sight, and people moved desks over the years. So the person in wave one may sit in the middle of a range that belongs to wave four. You can't port half a range casually, so you split the ranges carefully with the carrier number by number, if you must, and you check that the split is allowed before you promise dates. This is where the register from discovery earns its keep. Every number has a purpose and an owner. So you know exactly who goes in which wave. And there's the cost of the middle. For weeks or months. Two systems carry the same company. Users on teams call users on the old PBX over an interconnect, and you need that interconnect to work well, because the first thing people compare is how it feels to call a colleague. Which brings us to the third pattern coexistence here. The PBX isn't a stage you pass through. Some of it stays a SIP trunk connects the retained PBX to your SBC and your route calls by number range teams. Users take the ranges that moved. The PBX keeps the ranges that didn't. The SBC sits in the middle and decides who gets what. That's how organizations keep the contact center until its own project is ready. It's how they keep the alarm lines in the door entry we talked about. It's also how a company with three years left on a PBX contract avoids paying to leave early. And it lets you retire the old system in pieces as each piece becomes safe. The risk is permanence. A coexistence plan with no end date is just a second phone system you forgot to name. So write down what stays, who owns it and when it gets reviewed. So how do you choose three things decided. First, risk tolerance. If a failed Monday would cost real money or real safety. Don't bet the estate on one weekend. Second contract dates a PBX or carrier contract ending in four months pushes you towards speed, and one ending in three years gives you room. And third, the size of the porting set ten numbers is a small job. Five thousand numbers across six carriers is a campaign and it will not fit in a weekend. However brave the plan, in practice, most organizations land on a mix waves for the main estate coexistence for the contact center and the special devices, and a small big bang for a single clean site at the start. Whatever shape you pick, write it down with the dates, the owners and the order. A strategy people can't repeat from memory isn't a strategy yet. Then comes the day itself. And on that day, everything you've built gets read out loud, step by step by a named person. Cut over day, runbook and rollback. By Friday, the decisions are already made. Cut over day is just execution. Read out loud in order. So start before the day starts. The pre cut over checklist is a gate, not a formality. Every line gets a yes, a name and a time. The port is confirmed in writing with the carrier's date and window routing has been tested end to end with real calls in both directions. Emergency calling is verified for the sites moving to night with the providers test results attached and staff are briefed. The floor walkers, the help desk reception and whoever answers for the contact center. If one line is a no, the answer isn't. We'll watch it. The answer is to move the date. A postponed cut over costs you a calendar entry. A bad one costs you a Monday. Now the runbook. This is the document everyone follows, and it has one rule no step without an owner. Not a team. A person with a phone number written next to their name. Work backwards from the port window and fill it hour by hour. Early evening the carrier confirms the port is on schedule. Next, the voice engineer takes a final snapshot of the PBX config and the SBC. Then you freeze changes. Nobody edits a route, a queue, or a policy from this point on, because the one tweak made at ten at night is the one nobody can explain at midnight. Then the port window opens, the carrier flips the numbers, and the voice engineer watches the SBC as the first live calls arrive. Within minutes, you run the test calls from your list inbound to a ported number, outbound to a mobile, a call to a queue, a call from teams to a colleague still on a retained line. One emergency call routed through the sanctioned test path. After that, the checks widen its caller ID right on outbound are the auto attendants answering with the correct greeting for the hour is voicemail landing in the right mailbox? Each check ends with someone saying it out loud. Confirmed, and the person running the log writing down the time, which is the part teams skip. Keep a live log. Time action owner result. It looks like overhead at nine at night by three in the morning. It's the only thing keeping a tired group of people from arguing about what already happened. Now the hard part. rollback. Here's the flaw in most cutover plans. They describe how to go forward in detail and describe going back in one line. Revert if needed. Who decides based on what and can you even do it? So settle it in advance and write it as a trigger, a time and a condition, not a feeling. For example, if inbound calls to the main numbers aren't arriving by a set time roll back. If emergency test calls fail to deliver the right location, roll back. If failure rates on outbound calls stay above an agreed level for thirty minutes, roll back. Pick your own numbers, but pick them now while everyone is rested and nobody is invested in the outcome, then name the person who calls it one person, not a committee and not whoever speaks loudest. When the trigger fires, that person decides within minutes and the rest of the room follows. And check that rollback is physically possible. Can the carrier port numbers back or point them at the old PBX? How long does that take? Often the honest answer is that a full reversal isn't fast, so your real rollback may be a foreword from the carrier to the old system, or a reroute at the SBC while the port itself stays. Know which one you have before the night begins and test it in rehearsal. Speaking of which, rehearse. Run the whole run book. Once on a small group, even on a handful of test numbers, the rehearsal will find the step that's missing the owner who's on holiday and the number that was typed wrong. Now, Monday morning, Hypercare starts the moment people arrive, put floor walkers in the buildings visibly with a lanyard or a colored shirt. People don't phone a help desk. When their handset acts strangely, they turn to the person standing nearby, put the strongest people at reception at the contact centers edge and at the executive floor. Because those are the places a small problem becomes a loud one and decide who takes the first angry call. Not by accident. A named engineer with authority to fix, answering a direct line for the first hours. Someone who can say, I'll sort this now and mean it because the cutover itself ends sometime on Sunday. But the real test is the first person who picks up a phone and finds that nothing seems different, and getting to that point is a different kind of work. After cutover Hypercare adoption and decommissioning the first two weeks decide how people remember this project. Not the design, not the port. The fortnight after when real people use real phones on Real Tuesdays. So run hypercare like an operation, not a goodwill gesture. One Q for every issue, triaged twice a day. Sort each item into one of three buckets. Quality missing features and Misrouted numbers. Quality problems arrive as stories. My calls sound underwater. Don't answer the story. Pull the call record. Find the building. The device. The time. As we saw in monitoring a single user complaint is noise. But three from the same floor as a pattern. Take that pattern to the network team the same day. Missing features arrive as a missing button. The assistant can't pick up the boss's line. The warehouse can't park a call. Most of these are mapping gaps. You can close in an afternoon, and a few are real differences you need to explain either way. Answer fast, because a gap left open for a week turns into a rumor. Misrouted numbers are the quiet ones. A direct line that rings the wrong person. A caller who reaches a closed queue at noon. You'll find these by checking the number. Register against live behavior line by line, and by asking reception what callers are complaining about. Reception always knows first. Now adoption. And here's where training plans usually go wrong. They teach the tool Forty minutes on every menu, every setting, every option. People nod and remember nothing. What works is smaller. A short guide for each role built around what that role does all day. The sales rep gets answer transfer and call back from voicemail. The assistant gets delegation. The warehouse gets the park card, one page, maybe a short clip, and nothing about features they'll never touch. Reception gets the most care. One page card pinned where the receptionist sits, who's on which queue, how to transfer to a mobile, what to do when a caller is angry and the transfer fails, and the number of the person who answers the hypercare line, write it with the receptionist, not for them. They'll cut half of what you drafted and they'll be right. And a habit that costs nothing. Ask people what they expect it to be different and wasn't. That's where you find the habit you never mapped. Now the part that feels like a victory lap and is actually a risk decommissioning the PBX. Don't switch it off because the project plan says Friday. Switch it off. When the evidence says it's quiet. Start with traffic. Pull the call records from the old system for the last thirty days and look for anything still using it. Inbound calls to a number nobody listed outbound from a device nobody owns a fax that still tries to send at two in the morning. Every line of residual traffic is an unanswered question, and each one needs an owner before you proceed. Then cut in stages. Isolate the PBX from the carrier first and leave it powered. If nothing breaks in a few weeks, power it down, but keep it only after a full business cycle, including month end and any seasonal peak do you remove it. That sounds slow. It's cheaper than explaining why the alarm dialer stopped reporting in March and only then touch the contracts, cancelled the old trunks, the maintenance agreement and the support line in that order with dates written down. Watch the notice periods because some of these renew automatically and nobody remembers until the invoice lands. Finally, go back to the register you built in discovery. Open it and go line by line. Every number gets a final state ported, retired, or retained on purpose. Every device gets its replacement confirmed. Every open item gets closed or handed to a named owner. In operations that register started as an inventory buy. Now it's the record of what the old system really did and the proof that you replaced it. But a closed project isn't the same as a system someone owns. And that gap is where the next set of problems begins. Risk and governance. The executive view. Step back from the Runbooks for a moment. Look at the project. The way a sponsor looks at it. A sponsor doesn't care about dscp markings. They care about what can hurt the company. Who is answerable and what it costs to keep running. So give them that. There are five risk areas. Everything we've covered fits inside one of them. Porting. If numbers don't move cleanly, customers can't reach you. The risk is lost calls and it's owned by whoever manages the carrier relationship. Emergency calling if location is wrong, someone in trouble gets help late. That's legal exposure and a human cost, and it needs a named owner who can say when it was last tested. Quality. If called sound bad, people stop trusting the system and go back to their mobiles. And once that happens, your recordings, your routing, and your policies stop applying the contact center here. The risk is revenue and contract penalties, because agents can't work around a broken floor and operational ownership, which is the one that gets the least attention and does the most damage. Think about what the PBX had a team, or a person or a vendor on retainer who owned voice. Everyone knew who to ring. Now look at a tombstone estate. The licenses sit with the Microsoft three hundred sixty five admins. The network sits with infrastructure. The SBC belongs to a telecoms engineer or a managed service. The carrier has its own portal. The contact center belongs to customer service. Five groups touch every call and none of them owns the call. That's the ownership group. It stays invisible while things work. Then a user says, my calls drop and the ticket bounces between four queues for two days. So close it on purpose. Name one accountable owner for voice as a service, not a committee. One person or team who owns the outcome can pull in the others and answers to leadership. Give them authority over the runbooks, the monitoring and the carrier and SBC relationships. If they can't make a call across those boundaries, they're an owner in title only. Then budget because the shape surprises people. The one time costs are obvious. Devices the SBC or the setup fee for a managed one and project effort. But the money that keeps coming is where plans slip. Licenses for every user per month. Calling minutes or carrier charges which move with usage the SBC either as hardware maintenance and certificates or as a managed service fee. Device refresh every few years and ongoing monitoring, which means tooling and a person's time presented as run cost per user, not a project total. A project total looks like a number you spend and finish. A per user figure shows what you'll carry for the next five years, and it's the number the old PBX was quietly hiding inside facilities and telecoms budgets and watch for savings claims. The PBX contract ends, and that's real. But some of the saving moves into licenses and carrier fees and some into the team you now need show both sides or the first years review turns into an argument. Now how do you report this to leadership once it's live in outcomes, not in features deployed or numbers ported for measures carry most of the weight called success rate of the calls people tried to make or receive. How many connected quality scores. The share of calls that met your baseline trended by site incident count, how many voice incidents, how long they lasted, and whether the same cause keeps returning and cost per user. The real run cost divided out compared with what the old system quietly cost At one line on emergency readiness date of the last test result and the date of the next. It's a short line, and it's the one a board member remembers. If something ever goes wrong, keep the report to one page with trends, not snapshots. A single bad week means little three months of a site getting worse means a decision. And this brings us back to where we started. The phone was never the project. The project was deciding who carries the risk for routing identity and safety, and then proving every month that someone does. Outro from PBX model to context driven calling. So here's where it lands. The old model treated the phone like a fixed asset a box, a set of lines, a team that knew where everything lived. The new model treats calling as a workload. It follows the user. It depends on identity and policy, and it only works as well as the network underneath it. That shift is the whole project. Everything else is sequence inventory first. So you know what the old system really did. Then the connectivity model because it decides who carries the risk, then porting. Since it runs on a clock you don't control, then the network emergency calling and the contact center, then a pilot built to find problems and a cut over with a rollback you can actually execute in that order because each step protects the next one. Skip one and you meet it again at the worst possible time. And notice what a good result looks like. Nobody celebrates, nobody sends a message saying the phones are great. People just pick up a handset on Monday and the call connects. A migration succeeds when nobody notices the phone changed. That takes planning. Most teams skip not because they're careless, because the phone always felt like the one thing that simply worked. If this saved you from a bad cutover weekend, leave a review of the podcast. It helps more teams find it before theirs. And that's the point. And if you want to keep going, connect with me. Mirko Peters on LinkedIn. Tell me what to cover next. SBC design, contact center platforms, emergency calling in a specific country. Send it in and I'll build the next episode around it. One last note everything in this episode comes down to the same habit. Count it, own it, test it. That applies to numbers, devices, mailboxes, and every other thing you move. If you want help building that discipline into your next migration, take a look at today's sponsor and ask them the questions we covered at the start. Thanks for listening. See you in the next one.