Past SendGrid?
You are not alone.

The cost story with SendGrid is more interesting than the headline numbers suggest. At low volume their pricing is sane. The Free tier covers 100 emails per day. The Essentials tier at 50,000 messages per month runs €15. By the time you are sending a million per month and need a dedicated IP, the line item starts looking different. Once you cross 500,000 monthly volume the cost trajectory bends sharply because the dedicated IP add-on (€80 per month each), the dedicated channel sender support (variable), and the Pro plan minimum (€89 per month plus per-message charges) compound on top of each other.

Three lines on the chart. The dashed line is SendGrid's published price tier scaled across volume. The solid teal line is what SendGrid actually costs in production once dedicated IPs and overage charges land — typically 25 to 40 percent above the headline. The third line is our equivalent service all-in, no add-ons. The crossover happens around 250,000 monthly volume. Below that we are more expensive. Above that, the gap widens fast — at 1M monthly we are roughly half the SendGrid all-in cost; at 5M we are a third. The honesty cuts both ways. Below 250k we are not the right answer. Above 250k the math gets uncomfortable for SendGrid, and the procurement teams that build their own model land on the same conclusion every time.

The takeaway is that SendGrid's pricing structure is rational up to a specific operational scale and then becomes punishing in a way the public pricing page does not show. The dedicated IP charges, the volume-tier minimums, and the channel-sender add-ons are not hidden — they are documented — but they are line items that procurement teams underestimate when they build the first-year budget. We have read enough SendGrid invoices to know the pattern. The clients who migrate to us did the math at month nine of their SendGrid contract and decided they would rather have the dedicated IPs, the included support, and the predictable monthly invoice on our side than the per-line-item billing on theirs.

The application-side change is small. SendGrid speaks SMTP and HTTPS POST against a JSON endpoint. Our infrastructure speaks SMTP and HTTPS POST against a JSON endpoint. The credentials change; in many cases nothing else does. For SendGrid SDK users specifically, we publish a thin compatibility shim on GitHub at bigbox-lu/sendgrid-compat — drop-in replacement for the SendGrid\Mail\Mail object with our endpoint, no other application changes needed. Most teams cut over in an afternoon.

The reputation-side change is the part that takes 4-6 weeks. SendGrid's shared-pool reputation does not transfer. When you leave, the sending IPs you were using stay with SendGrid; the reputation built into them is theirs, not yours. What transfers is the per-domain reputation that Gmail and Microsoft and Yahoo have built about your sending domain — that part lives at your DNS, not at the IP, and it follows you. Practically: a sender on SendGrid for two years with clean numbers will have decent domain reputation that helps the new IPs warm faster, but the new IPs themselves still need a 4-6 week ramp.

The suppression list is the operationally critical piece. SendGrid exposes the suppression list (hard bounces, unsubscribes, complaints, spam reports) through their API; we pull it on day one of the migration, deduplicate against your active list, and load it into our suppression infrastructure before any traffic flows. Without this step, the most common migration failure is re-mailing a few thousand hard-bounced addresses on the new IPs in week one and torching the new reputation immediately.

The traffic cutover runs in parallel. We provision the new infrastructure, warm the new IPs on your most-engaged segment, and gradually shift traffic from SendGrid to us in 10% increments while we monitor per-domain placement. Both pipelines are active throughout — your application is configured to talk to either endpoint based on a routing flag. We measure placement at Gmail and Microsoft and Yahoo and Apple every day during the migration window and we hold the cutover at any percentage where the numbers look worse than they did on SendGrid. Most migrations complete the cutover in 4 weeks; 2-3 stretch to 8 weeks because of edge cases (large suppression list to reconcile, multiple subdomains warmed in parallel — transactional and marketing streams separated for the first time).

Migration timing is the question every prospect asks within the first ten minutes. The honest answer is between 14 and 21 days for most cases, with the variance driven entirely by how quickly the prospect's DNS team responds to change tickets. The technical work on our side is mostly automated. The political work on the client side is what stretches the calendar. Below is the actual phase breakdown of a typical SendGrid migration we ran in Q4 2025, with each phase mapped to days elapsed and the failure modes that surface in each phase.

Five phases, fixed sequence. Day 1-2 is intake and DNS audit — we read your existing SendGrid setup, your authentication records, and your sending volume distribution. Day 3-5 is provisioning on our side — IP allocation, DKIM key generation, MTA-STS policy publication, monitoring dashboard configuration. Day 6-9 is parallel running — your application sends through both providers simultaneously, we compare delivery metrics in real time, you stop traffic on whichever path performs worse. Day 10-14 is cutover and reputation monitoring — application repointed at our endpoint, SendGrid traffic ramped to zero, daily aggregate report review for two weeks. Day 15-21 is the closeout window where SendGrid's contractual obligations expire and the financial side of the migration completes. Of those five phases, only the cutover (Day 10-14) needs sustained attention from the client. The other four are mostly us working alongside their DNS person.

Each phase has its predictable failure mode. The intake phase fails when the client's existing SendGrid setup is more complicated than they realised — typically because three teams used SendGrid for three different purposes and nobody mapped it. We add three to five days for inventory work in those cases. The provisioning phase fails when DNS changes get blocked on a cross-team ticket queue. The parallel running phase fails when the comparison data shows that the SendGrid path was actually performing better than expected and the client wants to stay. We have lost two prospects this way. They were correct decisions and we said so. The cutover phase fails when reputation has not warmed enough on our side to absorb the full volume — handled by extending the parallel running window rather than rushing the cutover. The closeout phase rarely fails technically. It fails commercially, when SendGrid's renewals team gets aggressive about retention and the client has to make the same decision twice.

Feature checklists in this category are usually marketing tools dressed up as comparisons. Vendors put the checks where they win. They omit rows where they lose. The matrix below tries to do better — it includes rows where SendGrid wins, rows where we win, rows where the answer is "both, but differently," and rows where the honest answer is that neither party offers what enterprise procurement actually wants. The procurement teams reading this can ignore the cells where we look good and focus on the cells where we admit we do not. That is where the real comparison lives.

Three things we do not have that SendGrid does. You might need them. Native click and open tracking through their tracking pixel infrastructure is the first — we do raw delivery only, the analytics layer is your responsibility or a separate tool you bolt on. Drag-and-drop email template builder for non-technical marketing teams is the second. We expect you bring your own templates. SAML SSO with granular role-based access control at every plan tier is the third — we have these on Enterprise but not below, which is a real gap for buyers procuring under enterprise security policy. If any of those three are deal-breakers, SendGrid is the right answer. We will tell you so during the call rather than push you to a tool that does not fit. The rest of the matrix is where we sit comfortably.