The client had been running an IBM-hosted email service for years. Every internal system and every multifunction printer pushed outbound mail through it. A classic setup for a classic problem: about ten on-prem services and a fleet of printers, all needing a reliable path out to the rest of the email world.
Then the client decided to move to Microsoft 365. The old mail service had to go. And that's when IBM showed up with a quote.
Option A: touch everything
IBM's recommendation was straightforward: every sending system — all ten services and every multifunction printer — should be reconfigured to send directly through an M365 connector. Each one separately. Each one tested. Each one documented.
Price tag: roughly 150 hours of work.
The proposal was technically sound. Microsoft's own documentation says exactly this: if you want a system to send mail through M365, you configure it to send to M365. Logical. And when you're billed by the hour, the logical path is also the longest one.
But the proposal missed something. The sending systems do not actually care who is running the server behind the IP address they've been talking to for years.
Option B: touch nothing
I proposed a different route to the client. Stand up a single Postfix relay server. Give it the same IP address and the same TLS certificate that IBM's old service had been using. Postfix has exactly one job: accept mail at the familiar old address and forward it on to M365.
No sending systems are touched. No printers are touched. No configuration files are opened. No test rounds for every device. No user communication explaining that "tomorrow your scan-to-email might stop working."
Just one new server on the network, fluent in two tricks: listen and forward.
Price tag: roughly 15 hours.
Why the simple option won
Postfix has been around since 1998. It is one of the most trusted mail relays in the world, and configuring it for a single, well-understood purpose is an hour of work for anyone who has done it before. The remaining hours went into networking, moving the certificate, sorting out the M365 connector, and verifying that all ten services and every printer were still sending normally.
The difference wasn't expertise. IBM's consultants know this material as well as I do, probably better. The difference was perspective. When you approach a problem through a vendor's request-for-quote, the answer is usually "do exactly the thing you asked for." When you approach it through the customer's day-to-day reality, the first question is different: "what is the absolute minimum we have to change here?"
Less changing means less breaking. Less testing. Less time spent rewriting users' email habits. And in the long run it also means that all outbound mail flows through one server, where logging, certificate renewal, and per-sender restrictions all live in one place — not scattered across ten different configurations.
The numbers
Option A (the vendor's proposal): 150 hours of work, 10+ system reconfigurations, every change carrying its own risk, ending in a decentralized setup where each sender's settings drift on their own.
Option B (what we built): 15 hours of work, zero changes to any sending system, one centralized point for outbound mail routing, identical result for the client.
I billed myself out of 135 hours of work. The client kept the money, the time, and the internal noise that the larger change would have generated. Mail flowed through on the same day the old service was shut down.
What to take away
Expensive solutions are not automatically the best ones. Nor are they automatically the worst — sometimes a 150-hour project really is what's needed. But if a vendor offers you exactly one path, it is worth pausing to ask whether any alternatives were even considered.
A vendor billing by the hour is not motivated to find the route with the fewest hours. That is not the same as saying the vendor is dishonest — it just means their incentives point in a different direction than yours. This is exactly why an independent second opinion is often the best money you spend on a project.
And one more thing. Every IT environment has spots like this. Old architectural decisions left in place because "that's how it has always been done." Behind almost every one of them sits a simpler alternative that has been there the whole time — it just hasn't been suggested by anyone looking at the situation from the outside.
Is there a place in your IT environment where the answer is always "that's a big project"? Digital Renovation starts by looking at it again. Project Guardian is the continuous version of the same idea: an outside set of eyes that stops the 135 hours before they get billed.