M365 FM - Exchange Online Hybrid - When and How to Retire It 00:00:00 Speaker: Somewhere in your data center, there's an exchange server. Nobody logs into it. Nobody patches it on time, and nobody remembers why it's still there. It was built as a bridge, a temporary one, a way to get from on premises mail to the cloud. The migration finished years ago, but nobody wrote down when the bridge ends. If you want more of this exchange hybrid mail flow decisions, subscribe to the show. By the end of this episode, you'll have three things a decision model, a runbook, and a risk list. But first, what hybrid actually is. Sponsor segment. Stellar. Migrator for exchange. Quick word before we go deeper. Migrations are where hybrid decisions get tested. You can have a clean plan on paper, but the moment mailboxes start moving, every shortcut and every undocumented dependency shows up, that's the part nobody puts in the project charter. This episode is supported by Stellar Migrator for exchange. It's a tool for moving mailboxes and data between exchange environments, including from on premises exchange to exchange online. If you're planning a move or cleaning up after one, it's worth knowing. Tools like this exist. I'm mentioning it for context not to sell you anything. Your situation decides whether you need any tool at all. Some organizations finished their migrations years ago and only have the server left. Others still have mailboxes sitting on premises and that changes the whole conversation. Keep that in mind as we go. Because this episode isn't really about migration tools. It's about a decision. Keep hybrid or retire it. Back to that question. The model hybrid as a bridge, not a destination. Let's start with what hybrid was built for. Exchange hybrid exists for one reason. Coexistence. You have an on premises exchange organization. You're moving to exchange online, and for a while both have to behave like one mail system. Calendars need to show free and busy across both sides. Mail needs to route between mailboxes no matter where they live. The address book has to look the same to everyone. That's the job. It's a bridge. You build it so people can walk across without noticing the river. And the model behind it is simple. On premises is the system of record. The cloud is the guest. Your directory lives in Active Directory. Your recipients are created and managed through the on premises exchange server, and the cloud mirrors what the server tells it. That model made sense on day one. You couldn't trust a brand new cloud tenant with your identity. You couldn't move five thousand mailboxes in a the weekend. So you kept the authority at home and let the cloud borrow it. Here's the problem. The migration ends. Mailboxes finish moving. The last wave goes quietly on a Sunday night. The project closes, the team moves on and everyone calls it done. But the bridge stays. Nobody takes it down because taking it down was never on the plan. The plan ended at mailboxes, moved. It didn't say what happens to the thing that made the move possible. So the model flips and nobody notices. The cloud now holds every mailbox. It runs the mail flow. It does the filtering, the storage, the retention. And yet the authority still sits on a server that holds no mailboxes at all. Think about what that means. You have an on premises exchange server whose only real job is to be a place where someone can click edit on a cloud recipient. That's it. A full server with a full attack surface, a full patching schedule, and a full support lifecycle acting as a form field. That's where it breaks. Not because hybrid is bad. Hybrid did exactly what it was designed to do. It breaks because the model outlived its purpose. The system of record never moved, only the mailboxes did. And when the authority and the workload sit in different places, you pay for it every day in patches, in risk, in tickets that start with we can't change this attribute. So here's how we'll work through this. I want to treat the whole decision as a flow of three things event, reasoning and orchestration. First, the event what triggers the retirement? A support deadline, a security finding, an audit question, a failed patch. Something has to make the bridge a problem worth solving. Second, the reasoning. What actually depends on the server? What do you keep? What do you reduce? What do you retire? This is where evidence beats memory. Third, the orchestration. The order of the steps. Who approves each gate, what you can reverse and what you can't event. Reasoning. Orchestration. Most organizations skip straight to the third one. They open a runbook, start removing connectors, and discover a printer that stopped sending scan to email at nine fourteen on a Tuesday. We're going to do it in order. But to reason about removing a bridge, you have to know what it's made of. So let's open it up. What hybrid actually consists of? Start with the hybrid configuration wizard. That's the tool most admins Remember you run it once, click through a few screens and it builds the connection between your on premises organization and your Microsoft three hundred sixty five tenant. It feels like one action. It isn't. Under that wizard sits a pile of separate objects, and each one is a thing someone has to own first. The organization relationship. This is a configuration object that tells each side how much to trust the other for sharing free and busy data. Calendar details mail tips. It's the reason you can open a calendar and see availability for someone whose mailbox lives on the other side. Next to it sits the Federation Trust. Historically, this was the thing that let the two organizations prove who they were to each other using a Microsoft service in the middle. It's the piece that made the old sharing model work. Then you have the connectors on the cloud side. There's an inbound connector and an outbound connector. On the on premises side, there's a send connector and a receive connector built to match. Together, they decide how mail moves between the two organizations, which certificate is used and which name the other side has to present. And here's what matters. Mail between your own two environments doesn't just flow, it's routed through those connectors on purpose using a shared domain and a routing address on each recipient. If a connector breaks mail between on premises and cloud users stops being internal. It starts looking like outside mail. Now add Uth. OAuth is the authentication layer that lets the two sides call each other for things like free and busy lookups, mailbox moves, and cross premises search. It relies on a trust relationship, certificates and a service principle in your tenant. Another object. Another set of credentials. Another thing that expires. So far that's the mail and sharing side. But there's a second half to hybrid and it's the one people forget. Directory sync. Your identities live in Active Directory. Microsoft Interconnect or Cloud sync copies them up to the cloud on a schedule. Users, groups, contacts all of it flows in one direction by default from on premises to the cloud. Hybrid adds something to that. It adds right back. Right back means certain cloud side information flows back down to your local directory. Things like the mailbox type, the archive status and the safe senders and blocked senders lists. That's how your on premises address book and your cloud recipients stay in agreement. And then there are the attributes that carry the whole thing. Proxy addresses. This is the list of email addresses the recipient answers to. Target address. This tells the on premises side where to forward mail for someone who lives in the cloud. Mail nickname the alias miss recipient type details and its relatives. These tell the system what kind of object it's looking at a user mailbox, a remote mailbox, a shared mailbox. These aren't decoration. They're the routing table. Each sink recipient carries these values in your local directory. And because that directory is the source of authority, those values can only be edited there. That's where the server comes in. Because you can't just open Active Directory users and computers and type in a proxy address and expect it to be correct. You could. Many people do. And that's how orphaned and conflicting values pile up. The supported way to change those attributes for a recipient has always been through exchange. The on premises exchange server, its management tools, know which attributes belong together, and they write them in a consistent set. So the server has a quiet second job. It's not carrying mail anymore. The mailboxes are gone. Instead, it works as a management console, a set of forms in effect for editing cloud recipients that happen to be mastered somewhere else. Think about the full inventory a wizard, an organization relationship, a federation trust. Connectors on both sides, an OAuth configuration. A sync engine with. Write back a set of attributes that act as routing data and one server whose real purpose is to edit them. That's what you're actually keeping when you keep hybrid. Not one thing. A whole system held together by a server nobody wants to touch. So why do so many organizations leave it exactly as it is? Why organizations never retire hybrid. Ask ten admins why the server is still there and you'll hear the same answer in different words. We might need it to edit a mailbox. That's the fear. And it's not irrational. Somewhere in the past, someone tried to change an attribute on a single user without the server. Maybe they edited a proxy address in Active Directory directly. Maybe they changed an alias in the cloud portal and the change either bounced or worse, it looked like it worked and then quietly reverted at the next sync cycle. One bad experience like that and the lesson sticks. Don't touch the recipients. Keep the server. The server is the safe path. So the fear isn't about the server itself. It's about losing the one tool people trust to write those attributes correctly. And since nobody has tested what life looks like without it, the fear stays untested. That's the first reason the second one is quieter. Nobody owns this. Think about who the server belongs to. The messaging team that built the hybrid moved on to other projects. The infrastructure team sees a windows server that's someone else's application. The security team sees a box they can't patch without asking, and the help desk only knows it exists because of one runbook step. Log into the exchange server to change the email address. Everyone touches it. No one is accountable for it, and because no one owns it, there's no deadline that matters more than people admit. A decommission needs a date, and a date needs a person who put it on a calendar. Without that, the server drifts. Year one. It's. We'll clean it up after the migration settles. Year two, it's. We'll do it when we upgrade year three. Nobody remembers there was a plan. There's also no incident. Think about how most infrastructure work actually gets approved. A thing breaks, someone pays for it, then budget appears. But a hybrid server that sits idle doesn't break in any way you'd notice. Mail keeps flowing. Calendars keep working. The tickets stay low. Quiet systems don't create urgency, and that feeds the reflex. We all know if it works, don't touch it. It's a good rule in plenty of places. A stable system is valuable, and constant tinkering has caused its own outages. But the rule has a hidden assumption that leaving it alone is free. That working means safe for this server. Those two ideas have separated. It works and it's exposed. It works and it's drifting out of support. We'll get to those. For now. Just notice that it works. Is measuring the wrong thing. It measures whether mail flows. It doesn't measure what you're carrying to keep that true. Now put yourself in the seat of the person who has to approve the change. An executive looks at two columns in the first column, a project. It has a name, a budget, a timeline, and a list of things that could go wrong. A printer might stop sending scans. A sync might fail. Someone might lose the ability to edit a distribution list for a week. Every risk has a face in the second column, leaving it as is. And what's written there? Nothing. That's the asymmetry. The cost of change is visible. It's a line item with an owner's name next to it. The cost of inaction is spread out and unlabeled. It lives in patch windows, in ordered footnotes. In hours, someone spends every quarter on a server. Nobody wants. No invoice arrives for it. No dashboard turns red, so the decision keeps losing. Not because the argument for retiring is weak, but because the argument against it has a number, and the argument for it doesn't. Until something forces the issue a vulnerability announcement, a support date, a new auditor with a sharper question. That's usually how it happens. Not by choice, but by deadline, someone else said. Which means the useful move is to put a number on that second column before anyone else does. So let's price it. The real cost of keeping hybrid. Start with the line item people forget exists. Licensing and exchange server isn't free just because it holds no mailboxes. It needs a Windows Server license underneath it. It needs a server license on top of that. And if you want to keep managing cloud recipients from it, there's a licensing path for that too, which we'll cover later in the episode. For now, just note that the box has a paper trail and someone renews it every year. Then comes patching. Exchange has a cumulative update model. Microsoft ships a cumulative update on a regular schedule, and security fixes only apply on top of a supported one. That sounds simple. It isn't. To install a security update, you first have to be on a recent enough cumulative update and to get on to that one, you often need the Net version, the visual C++ runtime, and a few other components to match. So a single security patch can turn into a chain update the prerequisites, run the cumulative update reboot, then apply the fix, then check that services came back clean on a server that carries real mail. A team does this because it has to. On a server that carries nothing, the work gets pushed a month, then a quarter. Then it's two cumulative updates behind and the chain just got longer. That's the cadence cost, not the hour of patching the compounding delay before anyone starts. Now look underneath the application hardware or the virtual machine that stands in for it. Disk space that has to stay healthy, backups that have to run so you can restore a server whose only job is to be a form monitoring agents, antivirus exclusions that were set up for a mail server and nobody has revisited and certificates. Hybrid mail flow depends on a certificate on the server. Public certificates expire when one lapses, the connectors between your two organizations start failing, and mail between on premises and cloud recipients begins to bounce. It's one of the more common ways a quiet hybrid server suddenly becomes loud. Somebody renews it, or somebody scrambles at two in the morning. Then there's the operating system. Windows server has its own life cycle, separate from exchange. Each version has an end date. When it passes, you don't just lose the server's own updates. You may lose your ability to run a supported exchange version on it. So a decision about the operating system quietly becomes a decision about the mail server, even though neither one carries a single mailbox. Which brings us to the cost that doesn't show up on any invoice. People think about who actually knows how the server works. The admin who built the hybrid often gone. The consultant who ran the wizard long gone. What's left is a set of habits someone remembers which step in a runbook starts with log into the server. Nobody remembers why knowledge decays faster than hardware, and that has a sharp edge. The day a certificate expires or a patch fails or a connector throws an error. Nobody recognizes. You need someone who understands exchange internals, not exchange online. The server. Those skills are getting rarer on every team because the work that built them has moved to the cloud. So you're holding a system whose experts are leaving and whose failure modes call for exactly that expertise. Now add the last piece, the one that turns a maintenance burden into a risk. Where does the server sit on the network? For hybrid to work, it has to talk to Microsoft's cloud. In a classic setup, that means it's reachable from the internet, mail connectors need to accept connections from Microsoft's data centers. Web services need to answer requests, so a port is open, a firewall rule exists, and a public name points at it. That's an internet facing server, and it isn't a quiet, static website. It's a full mail platform with a large web application built over many years sitting on the edge of your network, an unpatched forgotten one run by a team that stretched thin. So you're paying for licenses, patches, hardware certificates, and aging operating system and skills that are draining away. And in return, you're carrying exposure at your front door. Add up the other costs and you can still say they're annoying. This one is different because this one is the one attackers actually price. So let's look at that side in detail. Exchange server attack surface and threat exposure. Let's look at the record. Over the past several years, Exchange Server has been one of the most targeted pieces of software in the enterprise. Not a niche target. A favorite in twenty twenty one. A chain of flaws known as Proxylogon. Let attackers run code on servers without logging in. Tens of thousands of organizations were hit within days. Then came Proxyshell the same year, then Proxy nutshell in twenty twenty two, and more fixes after that at a steady pace. Different names, same pattern. The attackers didn't need to trick a user. They didn't need a password. They sent crafted requests to the web services of a server that was reachable from the internet, and the server did the rest. And here's the part that matters for this decision. Those flaws didn't care what the server was used for. A hybrid only server is still a full exchange server. It runs the same web application. It exposes the same services. It carries the same code that attackers study for weaknesses. The fact that no mailbox lives on it doesn't shrink any of that. The software doesn't know it's retired from mail duty. So when a vulnerability lands, Your quiet little management box is exactly as exposed as a server with five thousand mailboxes on it. People miss that because the server feels small. Low traffic, no users, easy to forget, but attackers don't scan for important servers. They scan for reachable ones. A forgotten box with an old build number is easier to break than a well-run one, and a successful break gives them a foothold inside your network, often with deep writes and Active Directory. Because exchange has historically held those. Now think about the response side. When a serious flaw is announced, the clock starts that day. Microsoft publishes a fix or a mitigation attacker starts scanning within hours and your team has to decide, do we apply the update, run the mitigation script, or take the server offline on a server with a dedicated owner? That's a bad day on a server with no owner, it's worse. One person, maybe two drops other work. They check the build. They find out the server is behind so the fix can't install yet. They run the cumulative update chain we talked about under pressure on a system nobody has touched in months, and they do it without a test environment because nobody kept one. That's the emergency mitigation burden. It lands on a tiny team at a bad time for a server that delivers almost nothing. Think about the trade one person's week every time a floor drops to protect a form field and there's a new pressure on top of the technical one. Auditors have started asking about this. Not in a vague way. The questions are specific. Which servers in your environment are internet facing? What software versions do they run? How fast do you apply security updates? What's your support status for each one? A hybrid server answers badly. Internet facing. Yes. Running a mail platform. Yes. Patched on a schedule maybe. And when the auditor asks what the server does, the honest answer is it edits attributes. That's a hard sentence to defend in a review. Cyber insurance carriers ask similar things. So do customers who send you security questionnaires. An unsupported or lagging exchange server is the kind of finding that turns into a remediation item, a risk acceptance memo, or a higher premium. So the exposure isn't only technical, it's also a paper problem. Someone has to sign a document saying, yes, we know, and we're keeping it anyway. Which raises a fair question if this is so risky, why hasn't Microsoft done something about it? It has. And the rules changed in a way that affects every hybrid organization, whether they noticed or not. 00:17:09 Speaker: Microsoft's dedicated hybrid app and lifecycle changes go back to the oath peace for a moment in the original hybrid design. The authentication between your server and the cloud ran through a shared identity. Every hybrid organization used the same service principle, one that lived in Microsoft's own tenant and was trusted by all of them. Your server presented a certificate and the cloud accepted it because that shared identity said so. It worked, but it carried a structural weakness. A shared identity means shared exposure. If someone found a way to abuse that trust, they weren't attacking one organization. They were standing at a door that opened into many. Microsoft warned about this publicly. A flaw in how that shared trust handled tokens could, in theory, let an attacker with admin rights on an on premises server reach into the cloud side, and the reach went further than most admins expected. So Microsoft changed the model. The replacement is a dedicated exchange hybrid application. Instead of leaning on the shared service principle, your tenant gets its own application registration with its own credentials used only for your hybrid traffic. The trust is yours. It isn't borrowed from a pool. Notice what changed in the logic. The old model assumed the on premises server was a safe place to anchor trust whatever it said. The cloud believed the new model assumes that server might be the weak point and scopes the trust, so that a problem on one side stays on that side. That's a real shift, and it comes with real work. If your hybrid was built years ago, it probably still uses the legacy model. Moving to the dedicated app means running a script, adding the new application, and updating the configuration on both sides. Microsoft published tooling for it, and it's a supported path, but someone has to know it exists and someone has to own the change. And this is where the earlier point comes back around. An unknown server doesn't get this update. Nobody reads the announcement. Nobody schedules the work, the legacy model keeps running, and the gap between what Microsoft recommends and what your server does keeps growing. Now add the Lifecycle Exchange Server twenty sixteen and Exchange Server twenty nineteen. Both reached the end of support in October twenty twenty five. Past that date, Microsoft stops shipping security updates for them. No more fixes for newly found flaws. No more fixes for the next proxy. Whatever. Read that again in the context of what we just covered. The server is internet facing. It runs a platform attacker study closely and the vendor has stopped patching it. That's not a maintenance problem anymore. That's a standing exposure with no remediation path other than replacing the software. There's a successor exchange server subscription edition. It's a different licensing and update model, and it's what Microsoft points hybrid customers toward if they decide to keep a server will weigh that choice in the decision itself. But it's worth saying now keeping hybrid on a supported footing is no longer a matter of leaving the old server alone. It means moving to a new product version with its own licensing, its own upgrade path, and its own project. So there are two separate questions hiding here. What does Microsoft support and what merely still runs? They sound the same. They aren't. Your twenty sixteen server will keep booting after the deadline. Mail will keep flowing through the connectors. Calendars will keep showing free and busy. Nothing breaks on the date. The lights stay on, but still runs and supported are different promises. One means the software executes. The other means that when something goes wrong, there's a fix, a vendor to call, and a position you can defend to an auditor. An unsupported hybrid server also loses a quieter protection. Microsoft's hybrid guidance. Its tooling and its fixes are written for supported builds. Drift too far, and you may find that the wizard, the sync components, or a newer cloud feature simply isn't tested against what you're running, so you can keep the bridge standing. You just can't call it maintained, which means the real question isn't whether the server still works, it's whether you want to pay to keep it supported, shrink what it does, or take it out. That's the decision, the decision framework. Keep, reduce or retire. Most teams frame this as yes or no, keep hybrid or kill it. That framing is the first mistake. It hides the option most organizations actually need. There are three outcomes, not two. Keep, reduce, retire. Keep means the server stays fully supported with a plan behind it. Reduce means the server stays, but you shrink. What it does and what it exposes. Retire means it goes away completely. Each one is a legitimate answer, but each one has to be earned with questions, not with a feeling. Start with keep. What would justify it? Ask whether you still have mailboxes on premises, real ones, not leftovers. Ask whether regulation or contract forces certain mail to stay in your own data center. Ask whether an application you can't change needs a local exchange server to talk to. If the honest answer to any of those is yes, keep is on the table, but keep has a price tag. You move to a supported version. You assign an owner, you patch on a schedule and you move to the dedicated hybrid app. Keep isn't. Leave it alone. It's. Run it properly now. Reduce. This one fits when you can't retire yet, but you also can't justify the full footprint, so you ask different questions. Does the server need to be reachable from the whole internet or only from Microsoft's address ranges? Does it still need to host relay for devices, or can that move first? Can you drop the services nobody uses? Reduce is a stepping stone. It buys you time and cuts exposure while the dependencies get cleared. The danger is treating it as a destination. A reduced server with no end date is just a smaller version of the same problem and then retire. The questions here run in a different order. Is every mailbox in exchange online? Do you know every system that sends mail through the server? Can you manage recipients without it? And can you say what happens step by step if something goes wrong on the day? Notice the pattern. Retire isn't blocked by whether you want it. It's blocked by whether you can answer those four questions with evidence, which is why the rest of this episode is built around them. Now who decides this is where most projects stall? The decision doesn't belong to the messaging admin. They can describe the risk, but they can't accept it. It doesn't belong to the security team alone either. They can demand a fix, but they don't own the business. Impact of a broken scan to email workflow. The decision needs a named owner with authority over both the risk and the budget. Usually that's the head of infrastructure or whoever owns the Microsoft three hundred sixty five platform, and it needs a signature, a short document, one page that says which outcome you chose, why and by what date. That last part matters. A decision without a date is a wish. If the answer is keep. The signature also covers the cost of keeping it supported. If the answer is reduce, it names the end date for the reduction, and if the answer is retire, it names the gates, which we'll build later. Writing it down forces something useful. It makes the quiet cost visible. Someone has to put their name next to either we accept this exposure or we're removing it. Now, a hard truth about how this tends to land. The answer is rarely never retire. Think about what never requires. Years of patching a mail platform that attackers study a permanent owner for a server that delivers almost nothing. Staff who keep skills alive for software you're trying to leave. A standing explanation for every auditor. Every insurer. Every customer questionnaire. Some organizations do have a real reason. If you do, keep is honest, but for most, the reasons given are old fears wearing the clothes of requirements. We might need it to edit a mailbox. Some device might use it. Those aren't requirements. They're unknowns. And unknowns get answered with data. So that's where you start. Not by deciding by finding out what actually depends on the server. With evidence, you can put in front of whoever signs, because you can't choose between keep, reduce and retire until you know what you'd be breaking. Dependency discovery. Start with evidence, not memory dependency discovery. Start with evidence, not memory. Ask the team what depends on the server and you'll get a list. It'll be short. It'll be confident. And it'll be wrong. Not because people lie. Memory stores the things that were announced. The projects with the kickoff meeting. The system someone documented on purpose. What memory doesn't store is the thing a contractor set up in twenty seventeen on a Friday afternoon because a vendor said, just point it at your mail server. So the first rule of discovery is simple the server knows more than your people do. Ask the server first. Start with message trace. Exchange online keeps a record of every message that passes through your tenant for the recent window. You can pull it in the admin center for older data. You can run a historical search and get a report back. You're hunting for mail that touched your on premises side, messages that entered through your inbound connector from the server, and messages that left through the outbound connector toward it. Group that data by sender, by connector, and by volume. Then look at who shows up that you didn't expect a sender address. Nobody on the team recognizes a mailbox name like scanner three or no reply ERP. A burst of messages every night at two a m. Each of those is a system, and each system is a dependency you'll have to move. Now go to the server itself. Exchange writes protocol logs for its connectors, turn them on for the receive connectors, and every Smtp conversation gets recorded. Which IP address connected, which connector accepted it, whether it authenticated or just walked in, and whether it relayed mail to an outside domain. That log is the closest thing you'll get to a witness, it doesn't care what anyone wrote in a wiki, it records what actually happened and when. One tip from the field leave logging on long enough to catch the slow cycles. A weekly report, a month end job. A quarterly backup notice. If you only watch for three days, you'll miss the system that speaks once a month and then breaks loudly the day it can't. Smtp is only one door, though. The server also runs IIs the web server underneath exchange its logs, sit on disk in plain text, and they record every web request that hits the server, every client connecting to exchange web services, every call to Autodiscover, every ActiveSync device, and every request from an application that talks to the server over https. Read those logs and ask three questions. Which user agents appear, which accounts are making the calls, and which source addresses keep coming back. That's where you find the monitoring tool that pulls the mailbox, the archiving product that reads folders, the old line of business app that was built against the server's web services and has never been touched since. Put all of that together and you're building an inventory, not a spreadsheet of what you think exists, a table of who talks to the server and how for each one, record the source, address, the protocol, the account and use the volume and how often it appears. Then add a column for what it is and a column for who owns it. Some rows you'll fill in within minutes. Others will sit blank for weeks. That's fine. A blank row isn't a failure. It's a finding. It says, here's something that depends on the server and nobody can tell me why. Only now do you talk to people. Interviews come last on purpose. If you start with them, you collect opinions and then spend your time confirming or arguing with them. If you start with data, the interview changes. You walk up to the application owner with a specific line. This address sent four thousand messages through the server last month. What is it? That's a different conversation. Faster, harder to wave away and it turns. I think we're fine into. Here's what I found. It also protects you when something breaks. After cutover, you can point to the evidence you collected and the owners you notified. The record shows you looked. By. Now a pattern starts to show. Most of what appears in the logs is expected users mailboxes, hybrid traffic doing its job. But one category keeps surfacing again and again in ways nobody planned for. It's quiet, it's old, and it's usually the reason a decommission stalls three weeks before the date. It's the stuff that sends mail without ever being a person. Smtp relay the dependency. Nobody documented Smtp relay the dependency. Nobody documented. Think about the last time you sent an email from a device. A printer scans a contract and mails it to you. A monitoring tool sends an alert. At three a m, an ERP system emails an invoice to a customer. A building access system tells facilities that a door was left open. None of those are people. None of them have a mailbox you'd ever look at, and almost none of them were written down. In most organizations, these devices share one trait. They were set up years ago by someone who needed email to work once. Right now, the vendors guide said, enter your mail servers name. So the admin typed in the name of the exchange server. It worked, the ticket closed and the setting has sat inside a web page on a printer ever since. That's the whole documentation. A text field on a device nobody logs into. Now look at how the server accepted that traffic on an exchange server. A receive connector is what listens for incoming Smtp hybrid created one for traffic from Microsoft's cloud, but admins often built another for devices and to make it work without hassle, they set it to trust by address. Any machine coming from this IP range can send mail. No username, no password, no questions. That's anonymous relay or IP based relay. It's simple and that's why it's spread. A printer from twenty twelve can't do modern authentication. It can barely do a password, but it can say hello from a fixed address and the connector says fine, go ahead. Here's what that means for your decision. When you remove the server, you remove the thing that was saying yes. Every device that relied on that trust now points at a name that doesn't answer, and it doesn't fail loudly. It fails the way old devices always fail. Silently. The scan sends, nothing arrives. Nobody complains until someone needs the contract. That's why relay shows up late. Think about the order of a typical decommission. You move the mailboxes first. They're visible. They have owners and people notice if they break, then you deal with the directory, then the connectors. Everything on the project plan has a name. Relay isn't on the plan because nobody knew it was there. So it surfaces at the worst moment three weeks before the date or worse, the Monday after the server goes dark when the first invoice run fails and the finance team opens a ticket that says the system stopped sending emails. By then, the evidence is gone and you're guessing. So find it first and you already have the tool. Remember the protocol logs on the receive connectors. This is where they pay off. Every connection to the connector is a line in the log, and every line carries the address it came from. Pull those files and group them by source IP, then sort by count. What you'll see is a shape at the top, a handful of addresses with thousands of connections. Those are your busy systems and application server maybe, or a monitoring platform in the middle. A band of addresses with a few hundred each, probably the multifunction printers, one per floor and at the bottom a long tail of addresses with a handful of connections. Don't ignore the tail. The tail is where the dangerous ones live. A single connection per month is not noise. It's the quarterly report, the annual certificate warning, the backup job that only speaks when it fails, which is exactly when you need it most. For each address, add three things what it is found through DNS, your asset tools, or a plain ping and a look at the device, who owns it and what it sends, which you can read from the sender and recipient fields in the same log. Also note one detail did the connection authenticate or did it work in anonymously? That column becomes your risk list. Anonymous sources can't be moved by changing a password. They need a different path altogether. Which raises the real question. Once you know what's out there, what do you point it at instead? There's more than one answer, and the right one depends on what each device can actually do. Smtp relay replacement options. You've got the list. Every device, every address. Every sender. Now you sort it by one question. What can this thing actually do? Because there are three real paths into exchange online, and each one asks something different of the device. The first is direct send. Here the device skips your server and talks straight to Microsoft. It connects to your tenant's own mail endpoint, the one built from your domain name, and hands the message over on port twenty five. No username. No password. Microsoft recognizes your public IP address and it accepts the mail. It's the closest thing to what the old receive connector did. That's the appeal. A printer that can't do anything modern can still do this, but the limits are sharp. Direct send can only deliver to recipients inside your own tenant. Try to mail a customer and it fails. It also depends on a fixed public IP, and it leans on your SPF record to be believed. And mail sent this way gets no special treatment if the device spoofs a sender, spam filtering sees it for what it is, so direct send fits one job well. Devices that only notify your own people, a scanner mailing you a PDF, an alert going to the help desk. The second path is Smtp client submission. This one is authenticated. The device signs into a real mailbox on port five hundred eighty seven over TLS, using a username and password. In return, it can send to anyone inside or outside the company because it's acting as a licensed sender that solves the outside recipient problem, and it's the cleanest route for an ERP system. Emailing invoices to customers. The catch is the device has to support it. It needs modern encryption, it needs to store a credential, and someone has to manage that credential. Passwords expire, mailboxes need licenses, and there's a daily cap on how much one mailbox can send. So a noisy application can hit the ceiling and go quiet. Which brings us to the pressure underneath this whole option. Authenticated submission relies on a setting called Smtp auth. For years it worked with a plain username and password, what Microsoft calls basic authentication. And Microsoft has been shutting basic authentication down. Protocol by protocol because stolen passwords are how most mail attacks begin. For Smtp auth, the timeline has been pushed back more than once, but the direction hasn't changed. Treat any design that depends on basic auth as borrowed time. So when you choose this path, ask what the application supports. If it can do modern sign in good. If it can only send a password, you're building on something with an expiry date. The third path is the connector based one, and it's the one that most closely replaces the old setup. You create an inbound connector in exchange online, it tells the cloud to trust mail from a specific public IP address or a certificate, and to accept it as if it came from your own organization. The device then points at your tenant's endpoint and sends with no password involved. What you gain is a relay that can reach outside recipients without a licensed mailbox behind it. What you take on is a fixed address that has to stay yours, a connector that someone has to own, and a trust rule that's only as safe as that address. If someone else can send from that IP. They can send as you. So use it sparingly and scope it tightly. Now, some devices won't fit any of these. An old fax gateway, a scanner that speaks only unencrypted Smtp, a system the vendor stopped supporting a decade ago, but the business still needs. For those. There's a fourth option, and it's the least pretty one. Put a small relay in front of them that can be a third party relay service that accepts the old traffic and forwards it properly, or it can be a lightweight relay. You run yourself a single small Smtp host with a narrow job. The legacy devices talk to it the way they always did. It talks to Exchange online the way Microsoft now expects. The rule is to keep it dull and small. One purpose a short allow list its own owner. If it grows into a second exchange server, you've rebuilt the problem you set out to remove. So the sorting is simple notify only devices go to direct. Send anything that mails outside goes to authenticated submission or a scoped connector, and the stubborn few go behind a small relay with an end date of their own. Once each device has a destination, one question is left when someone sends mail to your company, and when your company sends mail out, where does it travel after the server is gone? 00:34:31 Speaker: Male flow before and after hybrid. Start with the inbound path as it runs today. Someone outside your company sends a message. Their server looks up your MX record, finds an address, and delivers there. In many hybrid setups, that address is the on premises exchange server or a gateway sitting in front of it. From there, the server checks the recipient. If the mailbox lives on premises, it delivers locally. If the mailbox lives in the cloud, it forwards the message to exchange online over the hybrid connector. So a message for a cloud user takes a detour. It lands on your server first, and then it travels on outbound runs the opposite way a cloud user sends to the outside world, and the message may route back through your data center before it leaves. Same connector, other direction, and one more stop on the way out. Now look at where the MX record points that one DNS entry decides where every inbound message lands first, and it's easy to treat it as a footnote in the plan. It isn't. It's the front door. If the record points at your server, then removing the server removes the door. Mail has nowhere to go. If it points at a third party filter, the filter has to be told where to deliver and that setting has to change to the target for most organizations is the exchange online protection endpoint. The one built from your domain name mail arrives there first, gets scanned, and goes straight to the mailbox. No detour. Change the record and propagation takes time. DNS caches hold the old value for as long as the time to live. Says so. Lower that TTL days before the change. Otherwise, some senders keep hitting the old address for hours after you've moved, and you won't know which ones that brings up centralized mail transport. It's a hybrid option, and some organizations turn it on. It forces all outbound mail from the cloud to route back through your on premises server. The usual reasons are compliance inspection or a gateway that has to see every message. It works, but it ties your cloud mail flow to a server in your data center. If that server is down, patched badly, or blocked by a certificate problem, outbound mail from Exchange Online stops. The cloud is healthy and your mail still doesn't leave, so turning it off changes who's responsible. Mail leaves straight from Microsoft's side. Every control you built into the on premises path has to be rebuilt in the cloud or retired on purpose, which leads to everything else sitting in that chain. Edge filtering is the first one. If a third party gateway scans your inbound mail, it's pointed at your server today after the change it has to deliver to Exchange Online instead. And you have to lock down the cloud side so that only the gateway can send mail into your tenant. Otherwise, attackers can skip the filter and hit Microsoft directly. Journaling is the second one. Some organizations copy every message to an archive, and the server does that copying. When the server goes. The journal rule goes with it. Either you recreate journaling in exchange online, or you move the archive to a cloud native path. Miss this and your compliance team finds the gap. Months later during a request for old mail that was never captured. Then there are the gateways. Nobody remembers a data loss tool, a disclaimer appliance, a signature service that stamps every outgoing message. Each one sits somewhere between the world and your mailbox, and each one was wired to the server's address. So draw the path every hop in order, inbound and outbound. Then ask of each one what does it deliver to and what delivers to it. That drawing is your mail flow plan. Without it, you're changing the front door and guessing what's behind it. Once mail has a clear path, one problem is left and it's the one that makes admins hold onto the server the longest. How do you manage the people and mailboxes themselves? management without on premises servers. Here's the question that keeps the server alive longer than any certificate. How do I edit a mailbox without it? To answer that, you have to know how the server got this job in the first place. Think back to how hybrid was built. Your users live in Active Directory. That directory syncs up to the cloud, and the cloud creates a matching user in entry ID, but the mail related details of that user. The addresses, the aliases. The hidden routing values were written by exchange on premises exchange. The server owned the schema and the schema held the attributes. So when someone needed to add an alias to a cloud mailbox, the change had to start at home. You open the exchange console on the server, change the object in Active Directory, waited for the sync cycle and watch the change land in the cloud. Edit it in the cloud instead. And the cloud told you no. Or worse, it let you try in the next sync overwrote your work. That behavior has a name source of authority. Every attribute on a synced object has one place where it's allowed to be changed. The other side holds a copy. For years, the mail attributes in a hybrid organization had their authority on premises. The cloud reflected them. It didn't own them. That's the rule that turned a migration tool into a permanent management console. Nobody planned it that way. Microsoft designed hybrid so that mailboxes could move to the cloud while the identity system stayed where it was. The server stayed because the attributes stayed and the attributes stayed because nothing told them to move. So admins built a habit around it. Mailbox changes need the server, every runbook said so every new hire learned it in their first week, and the server stopped being a bridge and became a tool. A piece of kit. You reach for the way you reach for a wrench. Now look at the assumption. Inside that habit. You need the server to edit a mailbox. For a long time, that was simply true. It isn't anymore. Microsoft heard the complaint for years, admins would finish a full migration, every mailbox in the cloud, and be told they still had to keep a server running, patched, and exposed just to change an alias. The vendor's own guidance said it plainly keep the last server. Leave it alone. Don't touch it. That advice has changed. Microsoft now documents a supported way to manage mail attributes from the cloud, and with it a supported way to remove the last exchange server. The central idea is the one we just covered. You change the source of authority for those attributes from on premises Active Directory to exchange online. Once the cloud owns them, the cloud is where you edit them and the server has nothing left to say. Notice what that does to the logic of the whole project. The old assumption said the server was required because of how the system was built. The new guidance says the server was required because of where the authority sat. Move the authority and the requirement goes with it. That's not a workaround, it's the structural fix. Of course it isn't a switch you flip on a Friday. The change touches attributes on real objects. It affects how sync behaves. It depends on versions of the sync tools being recent enough, and it asks you to be sure that nothing else a script, a provisioning system, an HR tool is still writing those attributes from the on premises side. If something is, the two sides will fight and the one that syncs last wins. So the work isn't the change itself. The work is knowing what else writes to those values before you take authority away from it. But the direction is settled. You can run exchange online without a single exchange server in your data center, and Microsoft supports it. Which leaves the practical part if the server is no longer the tool, what is and what does each of those tools actually let you do? And where does it stop the supported management paths after hybrid. Start with the tools you already own, the Exchange Admin Center in the cloud and PowerShell connected to Exchange Online. Those two are the whole toolbox. No console on a server, no remote session into your data center, just a browser and a module for a mailbox that already lives in the cloud. They work the way you'd expect. You open the recipient, you add an alias, you set a forwarding rule. You change a mailbox, permission, the admin center shows it. PowerShell does it in bulk, but for synced objects, there's a condition attached. If the source of authority still sits on premises, the cloud tools will read the object and refuse to write some of its mail attributes. You'll see a grayed out field or an error that says the object is being synchronized from your local directory. That's the old rule still enforced. The cloud holds a copy and a copy can't be edited. So the first real step isn't a tool. It's a change in who owns the data. Microsoft's supported path is to switch the source of authority for mail attributes from on premises Active Directory to exchange online. It's done per object, not for the whole company at once. You flag a user group or contact as cloud managed, and from that point the cloud is where its male attributes get written. Aliases. Male nickname, the address list settings all of it. That per object detail matters for how you plan. You don't have to bet the company on one move. You can take a single test account, switch it, and look at what happens before you touch another. Now what happens on the sync side? This is where people get nervous and it's fair. Interconnect or cloud sync is the thing. Moving data up from Active Directory. When authority flips for an object, the sync tool has to stop sending those mail attributes for it. If it keeps writing them, you get the fight we described earlier. Two sides last writer wins. The supported behavior is that sync stops overwriting the cloud values for objects you've moved. The local copy becomes a leftover. It still sits in Active Directory, but nothing treats it as the truth anymore. Two conditions to check before you try this. First, the version of your sync tool. The feature depends on a recent build, and an old interconnect install may simply not know the setting exists. Update first, then test second. Whichever you run, interconnect, or cloud sync. Read what Microsoft says about that specific tool. The two don't behave identically, and the guidance for one doesn't automatically carry over to the other. Don't assume. Check the current documentation for the one you actually use, then watch the object. After the change, look at the sync status. Look at the attributes in both places. Edit something in the cloud and confirm it holds through the next sync cycle. If it holds, that's your evidence. If it reverts, something on the local side is still writing and you need to find it before you go further. Now the honest part this isn't a perfect replacement for the old console. The exchange server gave you a rich set of tools. Some of them have no direct match in the cloud. A few older attribute types still can't be fully managed from Exchange Online alone. Some scripts that admins wrote against the on premises shell won't run because the cmdlets differ, or the parameters changed, and certain bulk operations that were quick on the server need to be rewritten for the cloud module. There's also a gap in the other direction. If you ever have to rebuild an object from scratch or repair one that's sync damaged, you'll be doing it with fewer levers than before. That doesn't make the move wrong. It means you should know where the edge is and test your most common tasks. Adding a user. Changing an alias. Hiding someone from the address list before you rely on them right those tasks down. Run each one against a cloud managed test object. Anything that fails goes on a gap list, and each item on that list gets either a workaround or an owner who accepts the limit. That's the realistic picture. The cloud can manage users. It can manage mailboxes. It can do it without a server. But users are the easy case. The objects that cause the most trouble are the ones that belong to nobody. In particular. Distribution lists, shared mailboxes, rooms, equipment, things that carry membership, routing, and years of accumulated history. That's where the next set of problems lives. Distribution groups, shared mailboxes, and resource objects groups are where the old model leaves its fingerprints. A distribution list looks like a small thing. A name and address, a list of members. But in a hybrid organization, that object was usually created on premises in Active Directory by someone using the exchange console, so it was mastered there. The cloud holds a synced copy, and that copy follows the same rule as everything else. You can read it. You can't properly edit it. Now think about how many of these you have. Most companies carry hundreds. Some carry thousands. Sales teams, project aliases, old mailing lists for people who left in twenty sixteen. Nobody owns most of them. And each one is a mail address that something somewhere sends to. So moving them to cloud ownership isn't a cleanup task, it's a routing task. If a group goes missing or loses its address, mail to it bounces and the sender never knows why. The supported move is the same one we covered for users. You switch the source of authority for the group's mail attributes to exchange online one group at a time. After that, membership and settings get managed in the cloud, but start with a small group. A test list with five members, one that nobody will miss. Switch it, edit it in the cloud, send mail to it, and confirm the change holds through a sync cycle. Here's a detail that catches people. Group type matters a mail enabled security group, a plain distribution group, and a Microsoft three hundred sixty five group all behave differently. Some can be moved this way, others follow different rules, and a few have no clean path at all. So sort your inventory by type before you pick which ones to move first. Then there are the objects that look like mailboxes but aren't people. A shared mailbox has no user behind it. It has an address, a set of permissions, and often years of mail that a team treats as a common inbox. Rooms and equipment work the same way. A conference room that accepts bookings. A projector that people reserve if those mailboxes already live in exchange online, you're mostly fine, but check where each one is mastered. A shared mailbox created on premises and then migrated is a synced object with a disabled user account in Active Directory. Standing behind it. That account is the anchor. Leave it alone and the mailbox keeps working. Delete it in a hurry and the mailbox goes with it. So confirm three things for each one. The mailbox lives in the cloud, the permissions, who can read it and who can send, as it were, migrated and still work. And for rooms, the booking settings survived or to accept the booking window. The delegate who approves those are easy to lose and hard to notice until someone books a room and gets no reply. Now the quiet one dynamic groups a dynamic distribution group, has no fixed member list. It builds the list by running a query. Everyone in this department. Everyone in this office. Everyone whose title contains manager. The query reads attributes on user objects and the group changes membership as those attributes change. That's where the hidden dependency sits. The group works only if the attributes it filters on are present and correct. If those attributes were written by an HR system into Active Directory and you've moved authority for some. Objects. The query may start returning different people than it did last week. Nobody changed the group. The data underneath it changed. So for each dynamic group, read the filter list the attributes it uses, then confirm where each of those attributes is written and by what if the answer is an on premises process we haven't mapped? That's your next finding. Finally, the order of operations. Moving groups without breaking things comes down to two rules move membership and routing together, never one without the other, and test with a group that has the same shape as the real one. Nested members included, external senders included before you touch the critical ones, because behind every one of these objects sits the same set of attributes, addresses, aliases, routing values, and those are small, technical, and unforgiving. That's the part of the directory worth reading line by line attribute hygiene, proxy addresses, mail nicknames, and routing for values. Decide whether a mailbox works after cutover. Miss each mailbox guide you proxy addresses, target address and the remote routing address, which lives inside proxy addresses as an entry that ends in your tenant's mail on Microsoft dot com domain. They look like trivia, but each one answers a different question for the system. The mailbox guide says which mailbox this object is tied to. Get it wrong, and the cloud and the directory disagree about who owns the mailbox. Proxy addresses is the full list of addresses the object answers to, and the one marked as primary is the address people see. Target address tells routing where to send mail when the mailbox isn't local, and the remote routing address is the hidden address. That hybrid used to hand a message from the server to the cloud. So here's what happens when they drift. A user has a mailbox in the cloud, but target address points somewhere stale, or the routing address is missing, or the ID doesn't match mail to that person doesn't fail on day one. It fails the first time something has to resolve the object without the server's help. That's why the cleanup belongs before the cutover. After is the wrong time, because after is when you've lost the server's tools, and the only evidence you have is a bounce message. Before you can read every object, compare it to the cloud, and fix the difference. While the old path still works as a safety net, start by pulling the values for every synced recipient directory on one side, exchange online on the other, then compare them in a table you're hunting for three patterns a mailbox in the cloud with no matching routing address. A target address that points at a domain you no longer use, and objects where the guy in the directory differs from the one in the cloud. Each of those is fixable. None of them is fun to find at eight a m on the Monday after. Then there's the failure that stops sink dead duplicate proxy addresses. Every address in the tenant has to be unique. One alias, one object. But years of hybrid leave behind pairs of objects that claim the same address. A contact someone created for an external vendor and then a user with the same address added later. A group that kept an alias after its owner left a mailbox that was migrated with a stale copy left in the directory. When two objects claim one address. Entra rejects the second, it doesn't crash. It records a sync error against the object quietly and carries on with everyone else. So the object looks fine locally and simply never updates in the cloud. And this is exactly the problem that moving authority makes louder. Once the cloud owns the attributes, the conflict can surface in the middle of a change you thought was routine. So search for it on purpose. Export every proxy address in the directory, lowercase them all. Strip the prefix and count duplicates. Then look at the sync errors report in intra because it already lists the objects that failed. And why clear those first. They're rarely a mystery. Once you see both objects side by side, usually one of them shouldn't exist. Now, don't trust your clean up script on the whole company at once. Pick a sample ten to twenty objects that cover every type. You have a user with a plain mailbox, a user with six aliases, and a changed primary address, a shared mailbox, a room, a group with nested members. An account that was renamed after a marriage or a merger. Those odd ones are the ones that break. Run the full sequence on them, fix the attributes, switch authority, edit an alias in the cloud, wait for a sync cycle, and send a message to the old address and the new one. Check that it arrives. Check that the reply comes from the right primary address and check the sync status says exactly what you expect. If the sample passes, scale up. If it fails, you learn something cheaply and the server is still there to catch you. That covers the people and the lists, mailboxes, groups, rooms, and the small values that tie them together. But there's one more category, and it doesn't fit into any of that. It's older than most of these objects, and it was never really built to leave public folders. And the other things that still point at the server. 00:50:51 Speaker: Public folders, journaling and other legacy anchors. Public folders were built in the nineteen nineties. A shared tree of folders living on the server, holding calendars, contacts, and mail that a whole department treats as common ground. Think of the shared inbox for a sales region, or the old contact list that every receptionist still opens first thing in the morning. Nobody calls it a system. They call it the folder, and it has a different relationship with hybrid than mailboxes do. Public folders can't just be moved with the mailbox migration. They're a separate workload in exchange online. They live in a dedicated set of public folder mailboxes, and getting content there means a batch migration of its own. You export the folder structure, check sizes and item counts, create the target mailboxes and run the sync. Then comes a final cutover where the folders go briefly read only while the last changes copy across. So that's the first thing to settle. Is the content still on the server? If it is, the server isn't ready to leave. The second thing is quieter hybrid public folder access. Some organizations left their public folders on premises, on purpose and configured cloud users to reach them through the hybrid connection. The cloud mailbox asks the server for the folder the server answers that works until the server goes away. Then every cloud user who relied on that tree loses it, and the folder icon just sits there empty. Check the setting. Look at which mailboxes are configured to point at on premises public folders and check the usage first. Many of these trees are mostly dead. A few thousand folders nobody has opened since twenty nineteen. Migrating all of it out of habit is a waste. Archive what's called migrate, what's live and let the rest go on purpose. Next, journaling. Journaling means a copy of every message gets sent to a separate mailbox or archive so that nothing can be deleted without a record. Regulated industries do it. Finance, healthcare, legal and the rule often lives on the server as a journal rule that nobody has looked at since the compliance officer who requested it retired. When the server goes, so does the rule. Mail keeps flowing. The copies just stop. That's the dangerous part, because nothing visibly breaks. The gap shows up months later when a regulator or a lawyer asks for messages from a specific week, and the archive has nothing for it. So trace where the journal goes a mailbox, a third party archiving product, then decide what replaces it. Exchange online has its own journaling, and it also has retention policies and e-discovery that cover many of the same needs. But those are different tools with different guarantees, and your compliance team has to sign off on the swap, not infer it, sign it. The same applies to anything compliance bolted on anti-spam appliances, data loss prevention gateways, email encryption disclaimers, signature stampers. Many were wired to the server through a transport agent or a connector. They inspect mail on its way through, and they were certified for that path. Once mail skips the server, they may skip those tools to. Unless you move the integration for each one, ask two questions. Does it still see the traffic and is there a cloud replacement already licensed that does the same job? Often the answer is yes, and the old appliance has been paid for twice. Then the oldest leftovers fax and voicemail. Unified messaging, the exchange feature that let voicemail land in a mailbox as an audio file, was retired in the cloud years ago, but a phone system wired to the on premises version may still be depositing messages there, and fax servers often send inbound faxes as email through the same relay we covered earlier. These are rarely in anyone's plan. The phone team owns them and the phone team may not know the server is leaving. Ask them directly. Don't ask whether it uses exchange. Ask where voicemail goes and where faxes arrive. Those are the anchors that sit around the mail itself, but some of the strongest dependencies don't send mail at all. They call into the server like a database through an interface written by a developer who left years ago. Transition. That's the next layer. The applications that call exchange applications and integrations that quietly depend on hybrid. Somewhere in your company, a piece of software reads mail without anyone. Opening outlook, a CRM that files customer emails against an account. A ticketing tool that turns a message into a case, a calendar sync for a booking system, a script that checks a shared inbox every five minutes and acts on what it finds most of them talk to exchange through one interface Exchange, Web Services, or AWS. It's been around since two thousand and seven. Developers liked it because it did almost everything read mail, create events, move items, set permissions so it ended up inside hundreds of products and in a hybrid setup. Plenty of those products were pointed at the on premises server because that's where the interface lived when they were built. Now look at where AWS is going. Microsoft has announced its retirement for Exchange Online. The date has moved before, so check the current one rather than trusting mine. But the trajectory hasn't wavered. Microsoft is pushing everything toward Microsoft Graph, and AWS is on the way out. That matters for you in two ways. If an app calls the on premises server, it breaks the day the server goes. If it calls the cloud version of AWS, it breaks on Microsoft's schedule instead. Either way, the app has an end date. You're just choosing which clock to follow. So the first job is finding these callers. You've already seen how the IIs logs on the exchange server show every request to the AWS path with a user agent and a source address. Group them an unusual user agent, a service name, an old library version. Each one is a clue to a product, and each product has an owner who may not know any of this. Then comes the real work, moving them to graph. Graph is the replacement a single API built around modern sign in with permissions you can scope tightly for a vendor product. This is usually a support ticket and an upgrade. Ask whether the product has a graph version and when many already do, the upgrade just never reached your install because nothing forced it. For software you built in-house, it's a rewrite, a real one. The cores look different, the permissions work differently, and the old code assumed things. Graph doesn't promise budgeted as a project, not a patch. And be honest about the ones where the developer is gone and nobody understands the code. Those need a decision, rebuild, replace, or retire the process. Which brings us to the credentials these things use. Look at how the app signs in. Often it's a service account, a plain user with a password that never expires because an expired password would break the integration at some random Tuesday. Sometimes it's an app password, and often it's basic authentication. The username and password method Microsoft has been disabling across Exchange Online. That's a collision. The app was built for a method that's being turned off, and it's tied to an account that was never meant to be audited. So list every service account that touches mail for each one. Record what it does, who owns it, what permissions it holds, and how it signs in. You'll find accounts with full access to every mailbox in the company. Set up once for a backup tool and never trimmed back. That's worth fixing whether or not the server leaves. Then there's the last group, and it's the hardest to find third party tools with a direct reference to the server, not a call through an interface. A name typed into a config file. A backup product that backs up mailboxes by connecting to the server's name, a monitoring tool, checking that a service is up, and archiving product. A mobile device manager. A migration utility from the last project. Each one holds the server's hostname somewhere in a field the vendor's documentation told you to fill in. The server name is the search term grep. Your config repositories. Search your documentation. Ask each tool owner a plain question. If this hostname stopped answering tomorrow, what would you notice? Once those are mapped, the technical picture is mostly clear. What's left is the part leadership will ask about first. What does all of this cost and what does it save? Licensing cost and the business case. Let's start with the part most people get wrong. Licensing for hybrid management. Microsoft has a specific rule here. If you keep an exchange server only to manage recipients in a hybrid organization, you can get a free license key for it. It's called the Exchange Hybrid Edition Product Key, and you request it through the Microsoft three. Sixty five Admin Center. No purchase, no server license fee. That's the reason so many admins think the server costs nothing, but the key covers the license. It covers nothing else. The Windows Server license underneath still counts. The virtualization host still counts the backup agent, the antivirus, the monitoring seat, the certificate renewals. Every one of those is a line item somewhere, just not on the exchange invoice and there's a condition attached. The free key is meant for a server that holds no mailboxes. The moment someone puts a mailbox back on it, you're in a different licensing situation. Check your own setup against the current Microsoft terms before you assume you're covered. Now what can be dropped and when? Think in layers. The hybrid key goes away when the last server does. That's the end of the line, not the start. Before that, you can stop paying for things that only exist to feed the server. The third party filter pointed at it, the backup product that protects it, the monitoring agents, the separate certificate for its public name, and any disk or storage tier you are keeping for its databases. Each of those has a different contract date. So list them with their renewal dates and you'll see something useful. Some of those dates fall before your planned decommission. Renew them for a year, and you pay for protection of a server that no longer exists. Then there's the cost. Nobody puts on a spreadsheet staff time count the hours patching windows on a weekend, the emergency response when a new vulnerability drops the yearly certificate scramble the person who has to remember how the console works because nobody else does. Even a quiet server takes a few days of attention every quarter, and the people spending those days are usually your best ones, because they're the only ones who know where everything is. Add it up and you rarely find a huge number. Server some licenses, some hours. A mid-sized company might be looking at tens of thousands a year in total, which is exactly why a cost argument alone tends to lose. Someone in finance. Looks at that number and compares it to the project cost consultants testing overtime risk. The project looks bigger than the saving, and they're right on those terms, so don't make it a cost case. Make it a risk case. Take the server's exposure that we covered earlier the internet facing surface, the emergency patches. The audit questions then put a price on the other side of the ledger. What does one compromised exchange server cost incident response downtime notification loss trust. Most organizations that have lived through one will tell you it dwarfs the project budget. You aren't claiming it will happen. You're saying the server is a standing exposure and the project removes it. Frame it with three numbers what you pay each year to keep it, what you'd pay to remove it once, and what you'd lose if it failed badly. Let the third number do the arguing and pair it with something concrete. A leader can approve a date, an owner, a budget. Because a business case without a timeline is just a well written wish. So that's the next job. Turning a decision into a schedule with phases, gates and people who sign off on each one. The retirement roadmap, phases and gates. A timeline isn't a list of dates, it's a list of conditions. And the dates only matter once the conditions are true. So build the roadmap in five phases discover, prepare, shift, stabilize, remove. Discover is what we've already walked through. Logs. Relay. Inventory. Application. Callers. attribute checks. It ends with a document. Every dependency its owner and its replacement prepare is where the cloud gets ready to stand alone. Shift is where control and mail flow actually move. Stabilize is a waiting period with the server still alive and remove is the last step, not the first. Notice the order. The server is the final thing to go because it's the only safety net you have. Now every phase needs two doors. One to get in, one to get out. The entry rule says what has to be true before you start. The exit rule says what has to be proven before you're allowed to move on. And proven is the word that matters. A feeling doesn't count. A green check mark in someone's head doesn't count. You need evidence you can show to another person. Take discover. Entry is simple. A named owner and a start date. Exit is assigned inventory with no dependency marked unknown. If one line says unknown, you're not done. Prepare enters. With that inventory in hand, it exits when every mailbox is in the cloud. The connector list is documented and a baseline configuration is saved somewhere other than the server itself. Shift enters only after the pilot objects pass. Exit means authority has moved. Mail flows on the new path and message trace shows real traffic arriving where it should stabilize. Enters with shift complete and exits on time, not on mood. Thirty days is a common choice. Pick a number, write it down and don't shorten it because everyone's tired. Remove enters when stabilize closes with zero open incidents tied to the old path, its exit is the server gone, the hybrid configuration deleted and the end state documented. That's the skeleton. The people around it matter just as much, because the biggest failures in a project like this aren't technical, they're surprises. A manager learns on Monday that the scanner stopped sending scans. On Friday night, a finance team finds out its invoices went nowhere. So communication has to be part of the plan, not an afterthought. Tell people three times weeks before with what's changing and what they might see days before, with the exact window and right after with what changed and who to call. Keep the message short and concrete, not mail. Infrastructure updates say scanners may need new settings. And here's the contact. If yours stops working, then pick your change windows with care. Avoid month end. Avoid quarter close. Avoid the week the company runs its biggest campaign. Mail flow changes are best done late Friday or early weekend, with the people who can fix things still on call. And with a full business day of cushion before the heaviest traffic returns on Monday and never scheduled two risky steps in the same window. If something breaks, you want to know which change caused it. Finally, governance. Who says yes? Each gate needs a named approver and it shouldn't be the person doing the work. The engineer proposes. A second person checks the evidence against the exit rule and someone with business authority signs. Often that's the head of it, sometimes the security lead. And for the final removal. Ideally both keep it light. A one page checklist per gate with the evidence attached is enough. Three signatures on a form is fine. A weekly meeting nobody attends is not. And write down who can stop the project. If a gate fails, someone needs the standing to say not yet. Without that being treated as a failure. That's the structure. Now to the first real work inside it. Before anything moves, the cloud has to prove it can carry the load alone. Phase one prepare the cloud to stand alone. Phase one has one question. If the server vanished tonight, would the cloud notice? Don't answer from memory. Answer from a report. The first check is simple, and it's the one people skip because it feels too obvious. Count your mailboxes. Run a query against exchange online and list every recipient by type. User. Mailboxes. Shared mailboxes. Room. Mailboxes. Equipment. Mailboxes. Then run the matching query against Active Directory and look for mail enabled users that have no cloud mailbox behind them. Those are the leftovers. A mailbox that never finished moving. A remote mailbox object pointing at nothing. A test account someone created in twenty eighteen. Sort the gaps into two piles objects that should be mailboxes and aren't there yet, and objects that should never have existed. The first pile gets migrated, the second gets deleted after someone confirms nobody needs it. Next, the part that decides whether the server is really empty ask the server itself. List every mailbox database and count what's inside. Then check for archive mailboxes. Arbitration, mailboxes and audit mailboxes. Some of those system mailboxes are expected and fine. A user mailbox, even a forgotten one is not a single live mailbox on that server means a single person whose mail depends on it, then public folders. If any public folder mailbox still holds content. We covered what that costs you here. The job is only to verify. Run the public folder statistics, confirm the migration finished and confirm no cloud mailbox still points back to the on premises tree. If the count isn't zero, you're not in phase one yet. You're still in discover. Now look at the edges of the cloud tenant. Start with accepted domains. Every domain your company sends mail from is listed there, and each one has a type. Authoritative means Exchange online owns delivery for that domain. Internal relay means it hands mail onto somewhere else if the recipient isn't found in the cloud, that second type is the one to hunt. In many hybrid setups, the main domain was left as internal relay, so mail for a person who isn't in the cloud gets passed to the server that was useful during migration. After it. It's a trap door. A mistyped address no longer bounces cleanly. It travels to a server that may soon not exist and then it disappears. So list every accepted domain, note its type, and mark the ones that have to change. You won't change them yet. You're building the list that phase three will use. Then the connectors open the inbound and outbound connector list in exchange online and read every entry. The hybrid wizard created a pair. Past projects probably created others a connector for a filtering service, one for a partner who needed a fixed route. One for an application nobody remembers for each. Write for things. Name direction, what it connects to, and why it exists. If you can't fill in the last field, find the person who created it. The audit log will tell you who and when and if the answer is still a blank. That's a finding and it goes on the risk list. Do the same on the server side. Receive connectors and send connectors with their address ranges and authentication settings. We've seen what hides there. Now it just needs to be written down in one place next to the cloud list, so you can see which pairs belong together, which leads to the last task of this phase and the one you'll thank yourself for. Take a baseline. Export the whole configuration while everything still works. Accepted domains, connectors, transport rules, organization relationships, mail flow settings, the hybrid configuration object, DNS records for your mail domains, and the certificate details. Use PowerShell and save the output as plain files. Screenshots are fine as extras, not as the record. Store it outside the server, a repository, a document library, a locked shares somewhere that survives if the machine doesn't and dated months from now. When someone asks what the settings looked like before the change. This file is the only honest answer. When the baseline is saved, the cloud is ready to stand alone. But ready isn't the same as in charge. The mailboxes live there. The control still lives somewhere else. Phase two change the source of authority. Phase two starts small on purpose. Pick ten to twenty recipients. Not the easy ones. Only include a plain user. A user with several aliases, a shared mailbox, a room, a distribution list, and one object that has a strange history. The renamed account, the migrated mailbox with the disabled user behind it, and pick people who will tell you when something feels wrong. Your own team works well. IT staff notice a missing alias before a customer does. Write the list down next to each name. Record the current values of the mail attributes primary address, aliases, mail nickname, routing address. That's your before picture. Without it, a later something changed is just an opinion. Now the switch itself. For each pilot object, you change the source of authority for its male attributes from on premises active directory to exchange online in the supported process. That's a setting on the object applied per user, group or contact. Follow the current Microsoft documentation for the exact steps, because the tooling and the minimum sync versions have changed more than once. Before you touch the first object, confirm two things. The sync tool is on a version that supports the feature, and nothing on the local side is still writing those attributes. A provisioning script, an HR connector, an old tool that stamps aliases on new accounts. If one exists, the two sides will fight over the same value and sync decides the winner. Then flip one object only one. Wait for a sync cycle and look at it from both sides. Check the sync status in entry, read the attributes in Active Directory and in exchange online. The local copy should now sit still. It's a leftover, not a source. Then do the real test. Edit something in the cloud. Add an alias. Change the display name in the address list. Wait for another full cycle and look again. If the change holds, you have evidence. If it reverts, something local is still writing, stop right there and find it moving. One hundred more objects won't fix a writer you haven't found. Once the first one holds, move the rest of the pilot. Then run the checks that matter to people. Send mail to the old address and the new one. Reply from the mailbox and confirm the sender address is the primary you expect. Book the room. Send to the list from outside the company. Look for sync errors, especially the duplicate address kind we covered earlier. Give the pilot time a few days at minimum, and across a weekend if you can. Some problems only show up when a scheduled job runs or a manager returns from leave and opens a mailbox nobody touched. When the pilot is cleaned. Widen in waves, departments or object types. Never. Everything in one night. After each wave, check the sync error report and the helpdesk queue before you start the next. If the error count rises, the wave pauses. That rule is the whole safety mechanism. So what if it goes wrong? Be honest about this part. The switch isn't a one way door, but it isn't free to reverse either. Microsoft documents a way to move authority back to on premises for an object. The cost is in what comes with it. Any changes made in the cloud since the switch have to be reconciled by hand. An alias added after the flip a membership edit a changed nickname, reverse it blindly and the old local values come back and overwrite the new ones. That's a quiet loss and a hard one to notice, so the cost of rollback grows with time for a pilot object that's been cloud managed for two days, it's trivial for a group that's had six weeks of edits. It's real work, which is a good reason to keep the pilot short, wide and in small waves. And note every change made in the cloud so you can replay it. Keep a rollback sheet object date switched, who switched it? What was edited since it's boring and it's the thing you'll want at the worst possible moment and keep the local side intact. Don't clean up the on premises values yet. Don't delete the leftovers. They're the cheapest insurance in the project and they cost nothing until the very end. At this point, the cloud owns the attributes and the people who edit them know it. Management has moved, but mail still takes the old road. Inbound messages, outbound messages and every printer relaying through the server still follow a path built for hybrid. And that path is next. 01:10:35 Speaker: Phase three redirect mail flow and relay. Phase three changes the road itself. Everything before this was preparation. Inventories. Pilots attribute checks. Now real mail changes direction and people will feel it if you get it wrong. Start with inbound. Look at where your MX record points today. In a lot of hybrid setups, it points at the server or at a filter that hands mail to the server first the server, then forwards to the cloud. For anyone who lives there, that was the design. It's also a hop you no longer need. The target is simple. Your MX record points at Exchange Online Protection using the address Microsoft gives you for your domain, or it points at your third party gateway. If you keep one and the gateway delivers straight to the cloud. Either way, the server leaves the inbound path. Before you touch DNS, check the time to live on the record. If it's set to a full day, a change takes a full day to spread and a rollback takes just as long. Lower it a few days ahead to something like five minutes. Then the change lands fast and so does the undo. Make the change in the window you agreed on. Then validate it from outside. Query the MX record from several public resolvers, not just your own network. Send a text message from a personal account on a different provider. Send another from a partner's domain, then open message trace in the Exchange Admin center and follow each one. You're looking for a single clean path from the internet into the cloud with no stop at your data center. Next, the part that takes the longest relay. Take the list you built during discovery and work through it one dependency at a time. Not all at once. One printer, one application. One monitoring tool. Each has an owner, a replacement path from the options we covered and a test. The routine is the same every time. Pick the replacement, change the device or application settings. Send a real message from it, then confirm in message. Trace that the message arrived in the cloud from the right source without touching the server. Only then do you mark that line. Done. Some will be quick. A scanner that supports modern authentication takes ten minutes. Others will fight you. A legacy application that can only send in the clear with no sign in at all that one may need the lightweight relay we discussed and a ticket to the vendor in parallel. Keep a running table source owner old path. New path. Test result date. when the last row turns green, relay is finished, not before. Now the testing itself deserves more than a handshake test. Traffic is polite. Real traffic isn't. So watch real traffic over the first few days, pull message, trace on a schedule and look for failures, delays, and anything marked as deferred or rejected. Look at outbound mail to your largest customers and partners. Look at automated senders like invoicing and alerts because those are the ones nobody will report until money is late. Watch the old server to its logs. Tell you the other half of the story. If receive connectors are still getting hits, something still believes the old path exists. Group those hits by source. Address a device you missed shows up there as a steady drip every day at the same time, and this is where the server earns its keep one last time. Don't turn it off. Leave it running healthy and reachable throughout this phase. If a forgotten application fails, you can point it back at the server in minutes and buy yourself time to fix it properly. If an MX change misbehaves, the old route is still there to fall back to. That safety net has a price, which is the exposure we've already talked about. So give it an end date. The window is for catching mistakes, not for keeping a comfortable habit. When the logs go quiet, the trace stays clean and the relay table is all green. The road has moved. What's left is the server sitting at the end of a path nothing uses anymore, and taking it apart has an order of its own. Phase four decommission the server. Phase four is quieter than people expect. No big cut over, no window with a bridge call, just a sequence of small removals, each one reversible until it isn't so. The order matters more than the speed. Start with the hybrid configuration itself. Open the hybrid configuration wizard one last time and use it the way Microsoft documents newer versions of the wizard can remove the hybrid configuration, and that's the cleaner path. It deletes the hybrid configuration object, and it takes out the connectors the wizard created. Run it from the server with the baseline you saved in phase one, open next to it. Then check what it left. The wizard only removes what it built. A connector. Somebody added by hand a certificate binding a transport rule that references the old path. Those stay. So go back through the connector list in exchange online and remove the hybrid pair if it's still there, then read every remaining entry against your documented inventory. If a connector has a purpose, keep it. If it only existed to talk to the server, it goes next. The relationship layer. When hybrid was set up, it created an organization relationship in each direction, cloud to on premises and on premises to cloud. It also created a Federation trust on the server side. Together they let calendars free and busy data and mailbox moves work across the boundary. After the last mailbox has moved, that trust has nothing left to carry. But leaving it behind has a cost. An old trust is a standing door between your tenant and a server that nobody patches anymore. So remove the organization relationship in exchange online first, then remove the Federation configuration and its relationship objects on the server and clean up the intra organization connector and the OAuth settings, the wizard wrote. Check the DNS side to the hybrid setup often leaves an auto discover record, and sometimes a Federation TXT record pointing at the old world. Autodiscover must point at the cloud now. The others can be removed once the logs show nothing is asking for them. Then comes the question people argue about do you uninstall the server or just power it off? Both have a place they just belong at different times. Power off first. Not delete. Shut it down. Leave the disks intact and keep the virtual machine and its backups exactly as they are. Then wait. Your stabilization window isn't over until the quiet has lasted. If nothing breaks for thirty days, you've learned something. No log could tell you nothing real was talking to it. Why not uninstall straight away? Because a clean uninstall is a one way door. Once the exchange set up program has removed the roles, the server can't come back as itself. A powered off machine can be started again in five minutes. When the window closes clean, then you uninstall and do it properly using the Exchange Setup program, not by deleting the virtual machine. Run the uninstall so exchange removes its own entries from Active Directory, its server object, its connectors, its certificates in the configuration partition. If you skip that and simply wipe the machine, the directory still believes the server exists. That leaves orphaned objects and a later cleanup with a manual tool that can hurt if you misread it. Take a last backup before you run it, then remove the roles. Restart and retire the machine through your normal process. Remove it from monitoring, from backup jobs, from the patch tool, and from the asset list. Those entries outlive the machine and keep sending alerts about something that isn't there. Finally, think about what stays in the directory. Removing the server doesn't remove exchange from Active Directory. The schema extensions that exchange added are permanent. They can't be rolled back, and Microsoft doesn't offer a way to strip them out. The attributes on your user objects stay two, along with the configuration container and the set of groups and permissions. That isn't a failure. It's the shape of the tool, but it does have consequences for how you manage objects afterward, and for what an auditor will find when they look. So the server is gone, the path is clean, the trust is removed, and the machine is retired. What remains is smaller and in some ways harder to see what stays behind in Active Directory. Here's the part that surprises people. You uninstalled the server, the machine is gone, and your directory still has exchange all over it. Start with the schema. When exchange first arrived, it extended active Directory with new classes and attributes hundreds of them. Those extensions are permanent. Microsoft doesn't give you a supported way to remove them, and nobody should try with a hand edited schema in production. So the attributes we talked about in the mailbox guide, the proxy addresses the routing values. They stay on your user objects as columns that exist. Whether or not anything reads them. That's fine. It's a shape, not a fault, but it means exchanges. Gone is the wrong sentence for your documentation. The accurate one is no exchange server remains and the schema extensions do. Then come the leftovers. The objects that were never part of the server, but only made sense because of it. Look in the directory for the exchange security groups, the ones that grant rights across the whole forest organization management, recipient, management, exchange, trusted subsystem. They sit in their own container and several of them hold permissions on your domain route. Those permissions are the part to watch with no server to use them. Nobody needs them, but they're still there, and a compromised account in the right group still carries real power. So read them. Check who belongs to each group and remove anyone who doesn't need to be there. Review the access control entries on the domain object and on the containers where users live. Entries added for exchange often grant broad write rights and they outlive the product that needed them. Don't strip them blindly, though. Some of those rights also affect how directory sync works, so test the change on a copy first and do it when someone can watch the sync status afterward. You'll find smaller things to mail enabled contacts. Nobody uses dynamic distribution group objects with no owner. A few system mailbox accounts disabled but present. Some of these are harmless. Some are clues to a process that's still running somewhere. Which raises a fair question. Now that you can manage everything in the cloud, do you ever need a local tool again? Sometimes, yes. And it's worth saying plainly some organizations keep one exchange management server or just the management tools for edge cases. A synced object stuck in a bad state. A sync tool that still writes a few attributes. A vendor product that insists on a local recipient object. Microsoft has acknowledged this need. And for the cases where the cloud can't yet do the job, there is documented guidance on keeping a minimal management setup. But keep it honest. That's a deliberate choice with an owner and a reason, not a leftover if you keep it. It holds no mailboxes, takes no mail, and doesn't face the internet. It's patched on the same schedule as everything else, and someone's name is attached to it. And if the reason for keeping it disappears, so does the machine. Then write everything down and end state that lives only in someone's head is a future incident. So document it in one place. List what was removed with dates. List what remains and why. Record the schema level, the groups you kept, the permissions you changed, and the sync settings now in force. Note which attributes the cloud owns, which the directory still owns and who can change each one. Link the baseline you saved in phase one so anyone can compare before and after. Add the awkward items to the management tool you kept. The group you couldn't clean yet. The relay you replaced with a stopgap. Those are the lines the next admin will thank you for, because they're the ones that would otherwise look like mistakes. With the document written, the project is technically complete, but a clean plan on paper doesn't survive contact with every environment. Plenty of teams followed steps like these and still ended up with a bad Monday transition. So let's look at exactly how that happens. Risks to avoid the failure patterns. Most failed decommissions look alike, not the technology. The sequence. Somebody did the right things in the wrong order or skipped a check that felt optional. So here are the patterns, one at a time. The first is the most common removing the server before relay discovery finishes. It starts with confidence. The logs look quiet. The pilot passed. Someone says, let's just shut it down and see what happens. And that sentence turns production into the test environment. A week later, the finance team notices that no payment confirmations have arrived. The device sending them was on a receive connector that nobody listed because it only fires once a month. Quiet logs don't prove nothing depends on the server. They prove nothing, depended on it during the days you watched. So stretch the observation across a full business cycle, a month end, a quarter end if you can, and treat every unexplained source address as unfinished work, not as noise. The second pattern is quieter, missed attribute conflicts and silent sync errors. Mail Male attributes live in a directory that syncs to the cloud and sync has opinions. If two objects claim the same alias, one of them loses. The loser doesn't get an alarm, the attribute just fails to update, and the error sits in a report that nobody opens. So a new hire gets an address that never goes live. A renamed user keeps the old primary address. A mail enabled group stops receiving external mail. The fix is dull. Read the sync error report on the schedule not once before and after every wave. Count the errors and compare. A rising number is information, even if no user has complained yet. Users complain late and usually to the wrong person. Third, lost ability to manage orphaned objects. Here's how it happens. You retire the server and months later you find a mail enabled object in a half broken state. A contact with a bad routing value. A group whose cloud side was deleted but whose local side survived. You open the admin center and the edit button is grayed out. The cloud says this object is owned by the directory. The directory says it has no exchange tools anymore. Neither side will let you fix it. That's the orphan. And the way out is rarely pleasant either. You restore a management tool for one afternoon, or you edit raw attributes in the directory, which is exactly the kind of work the project tried to retire. So hunt orphans before the server goes. Query for objects with male attributes, but no matching cloud recipient. And for the reverse, clean them or move their authority. Every orphan you fix now is an incident you don't have later. Fourth, forgotten connectors and broken mail from an old app. A connector is a promise. It says mail from this place or to that place takes this route. When the server disappears, the promise goes stale, but the connector stays. Now mail for a partner domain. Routes to a host that doesn't answer, or an app keeps trying to send through an address that rejects it and the bounce goes to a mailbox nobody watches. The sneaky version is the transport rule that references the old path. It doesn't error. It just misdirects some of your mail some of the time. So after the removal, read every connector and every rule that mentions a host name or a smart host. If the name doesn't resolve to something alive, ask why it's there. Last and worst, no rollback plan and no owner after cutover. A project team disperses fast. The engineer returns to other work. The manager moves on to the next initiative and three weeks later an NDR spike hits. And the question is simple who owns this now? If the answer is a pause and a shrug, the incident gets longer by the length of that pause. So before the last gate, name a person, not a team. A person with a backup who owns mail flow and relay. After the project closes, give them the baseline, the relay table and the rollback sheet, and write down which steps you can still reverse because a plan nobody can find at two in the morning isn't a plan. Which brings up the obvious next question. Suppose you did most of this right and something breaks anyway. What does recovery look like when things break? Rollback and recovery. Every step in this plan falls into one of two groups, the ones you can undo and the ones you can't sort them before you start lowering the DNS. Time to live is reversible. So is moving authority for a pilot object if you caught it early. Pointing the MX record back at the old path is reversible, and it takes about as long as the TTL you set. Powering off the server is reversible too. Even removing a connector is as long as the baseline file has its exact settings. Now the other group uninstalling exchange with its setup program, deleting the virtual machine and its backups. Letting a mailboxes retention window run out. Those are one way doors, and you walk through them once. So put the one way steps last and put a gate in front of each. Nobody should uninstall anything because it's Thursday. That brings up the safety net and a simple rule. Keep a recoverable image of the server until the stabilization window ends. Not the running machine alone. A full snapshot or backup taken after the last mailbox moved stored somewhere. The server's own failure. Can't touch? Test the restore at least once. A backup you've never restored is a guess, and a bad time to find out is the night you need it. Then the window closes and only then does the image go. Write the deletion date next to the approvers name. Now the bad night itself mail is missing, or senders are getting bounced messages. What do you do? First, don't start by changing things. Start by finding out who's affected and since when. Open message trace and look at the failed and deferred messages. Read the bounce code. A recipient not found points at an address or attribute problem. A host unreachable. Points at a stale connector or a relay still aimed at the old server. A rejection from a partner points at DNS or authentication. Each code leads to a different fix, and guessing across all of them is how an hour becomes a day. Then sort by direction. Inbound broken. Check the MX record and the accepted domain type. Outbound broken check connectors and transport rules. A single device failing. Check its settings against the relay table. A single person failing. Check their attributes against the before picture you saved and keep a change log during the incident with times. Every edit. Every. Revert. If your fix makes it worse, you'll want a clean way back. Know your fast exits too. If the server is still powered off and intact, starting. It takes minutes. If the MX changes the cause, the low TTL makes the undo quick. If one application is the casualty, pointing it back at a working path buys time. Pick the smallest move that stops the damage, then fix the cause. Once mail is moving again. Now the people side. This is where a technical problem turns into a business one tell the business early. Even if you don't have the answer, say what you know, what you don't and when you'll update again. Something like some outbound mail is delayed. We've found the likely cause. Next update in thirty minutes. That's enough. Silence is what makes people forward the same complaint to six managers. Name an incident lead and give them one job communication. The engineers fix things and the lead tells everyone else what's happening and when it's over, send a plain summary. What broke? Who felt it? How long? What changed? No blame, no jargon. Then comes the harder question. Not what to do when it breaks, but who answers for it afterward, and who makes sure the next bridge never gets built and forgotten? That's a leadership question, and it needs a different conversation. The executive view governance after hybrid. The project ends. The ownership doesn't. That's the shift leaders miss. A migration has a start date, a budget, a steering group, and a closing slide. A platform has none of those. It has a service that runs every day and someone has to answer for it. In most organizations, the migration team gets thanked, the project gets closed, and mail quietly becomes everybody's problem, which means nobody's. So the first governance task is simple convert the project into a service. Take everything the team built during the work the baseline, the relay table. The rollback sheet, the end state document and hand it over as an operating record, not a folder. Somebody archives a living document with a name on it and a review date. Now, how do you know the work paid off? Not with a feeling. With numbers. A leader can read in under a minute. Start with attack surface before you had one internet facing exchange server. Now you have zero. Say that plainly because it's the cleanest result of the whole project at the second part. Open inbound ports to a mail server down to none and externally reachable admin endpoints down to none. Then tickets count mail related incidents per quarter before and after include the dull ones like certificate expiry and relay failures. Watch for a dip after the cutover, then a flat line if tickets climb. Instead, something moved to the wrong place. Then patch cycles track how many emergency exchange patches your team applied in the last two years. That number should now read zero, and the hours attached to it become hours returned to the team and audit findings pull the last report. Count the lines that mentioned the server, its patch level, or its exposure. Each one that disappears is a finding. You won't write a response to. keep the before and after side by side and show it at the next review for numbers. That's enough. More than that, and nobody reads them. Now, the question that decides whether any of this holds who owns the pieces? Name them one by one. Mail flow. Who owns the connectors, the accepted domains, the MX record, and the transport rules. Relay who owns the list of devices and applications that send mail and who approves a new one. The exchange online configuration. Who can change policies and who reviews those changes. Often these land with three different people or with nobody. Pick one accountable owner for each and a named backup, not a team alias. An alias can't answer a phone at two in the morning. Then draw the lines. The messaging owner decides how mail moves. The security lead, decides what's allowed to send, and from where. The identity owner decides what syncs and who holds authority over each attribute. When those three roles are clear, a change request has a path. When they aren't, changes happen in a corner and show up later as incidents add a review rhythm a short check each quarter. Connect is still in use. Rules still needed. Relay source is still alive. Accepted domain types still correct. Thirty minutes with the documents open. Drift in a cloud. Tenant is slow and quiet, so the review has to be regular to catch it. That leaves the last risk. And it's the one that created this problem. Hybrid was meant to be temporary. Nobody wrote down when it ends. So the next bridge will arrive with the same promise and the same silence. Stop it at the door. Every temporary arrangement gets three fields before approval an owner, an end date, and the condition that triggers removal, a connector for a partner. A relay for a vendor appliance. An exception to a security policy. If it can't fill in those fields, it isn't temporary. It's permanent and should be treated that way with a real owner and a real review. Then make the end date visible. A list of open exceptions sorted by expiry reviewed in the same quarterly meeting. When a date passes, someone either removes the item or renews it on purpose with a reason renewal is allowed. Forgetting isn't do that and the organization learns the lesson. The server taught it the hard way, which changes what daily operations look like, not just who owns what, but how the whole thing runs once no server stands in the middle. 01:30:11 Speaker: And the new model cloud first exchange operations put the two models next to each other. In the old model, the server sat in the middle. Mail pass through it. Recipients were edited on it. Every change started with a login to a machine, and the machine's health decided the health of the servers. In the new model, there's no middle. The tenant holds the mailboxes, the recipients and the routing change doesn't start with a server. It starts with a rule. And that's the real difference. The old model asked, is the server up? The new one asks, is the policy right? Think about what that does to a normal week. Nobody's watching a disk fill up. Nobody's scheduling a restart after a cumulative update or hunting for a maintenance window that suits three time zones, Microsoft runs the platform. Your team runs the intent. Who can send from where, under what conditions, and what happens when something doesn't match. So what does a Tuesday look like? A new vendor needs to send invoices as your company. Nobody builds a receive connector. Someone checks the relay table, picks the right submission path, confirms authentication, and records an owner and a review date. A department wants a shared mailbox. It's created in the admin center or by a script that already exists, and the attributes live in one place. A message goes missing message trace answers it in minutes because there's one path to follow, not two organizations stitched together. Even the surprises are different. When something breaks, you're rarely rebuilding anything. You're reading a setting, comparing it with the baseline, and finding the line that drifted. That's where the discipline moves. It leaves the data center and lands in three habits configuration. Every connector, rule and accepted domain has a purpose, an owner, and a place in the documentation. If it can't be explained, it gets questioned. Monitoring, not server counters. Mail flow reports, message trace trends, sync errors, sign in patterns on the submission paths. You watch outcomes because there's no machine left to watch. Review the quarterly check we talked about, plus a short look at every change someone made in between. Drift in a tenant is slow and quiet, so the review is the control. None of this is harder than running a server. Most of it is easier, but it's less visible. And that's the risk a server gives you something to point at. A policy only gives you a result, and results get ignored until they fail, so the work doesn't disappear. It gets quieter and it asks for different people to pay attention. Which brings us to the end of the road. Conclusion retire the bridge on purpose. So here's the decision in order. Dependencies. First, find what talks to the server using logs, not memory. Then control. Move authority over male attributes to the cloud. Prove it with a pilot. Then the server goes last. After the quiet has lasted long enough to trust. Get the order wrong and you're guessing. Get it right and the final step feels almost boring. Here's the fact worth keeping. That server was only ever supposed to be temporary. It was built as a way across. Somewhere along the line. The way across became the place people lived. If this episode helped you make that call, leave a review of the podcast. Mention exchange hybrid retirement if you can. It helps other admins staring at the same server. Find this, and if you want to keep the conversation going, connect with me. Mirko Peters on LinkedIn. Tell me which topic you want next. One more note on tooling. Stella Migrator for exchange is one of the products that supports this kind of work. I mentioned it for context only. Closing sponsor segment. A quick word before we close. Every decision in this episode, from the pilot to the last cutover, depends on moving mailboxes and data cleanly. That's where tools like Stella Migrator for exchange come in. It's built for exchange migrations. Worth a look when you're planning your own path off hybrid, treat it as one option to evaluate, not the answer. Whatever you use, test it on a small set first. Same way you test everything else we covered. Next time we pick up another piece of the Microsoft three. Sixty five puzzle. Same question applies what depends on it and who owns it. See you in the next episode.