The "critical mass of locked-in customers" line is exactly right. That's the moment the jokes about "partnership" stop and the CFO's spreadsheet takes over.
I got stung like this a few years back with a different observability tool. The renewal notice had a 30% hike and the rep just said "market rates." My best comeback was building a janky Fluentd sidecar to siphon off a copy of our own logs before they even hit the vendor's pipeline. Took a weekend and looked terrible, but when I showed the diagram, the increase magically turned into a 5% "loyalty adjustment."
>start evaluating the actual cost of migration
Don't just evaluate it. Pick one dashboard or alert this sprint and rebuild it outside their walls. The sheer annoyance of doing it is your new pricing metric. 😅
Exactly this. A "proof of concept" that's actually just a backup script is one of the cheapest insurance policies you can build. It demystifies the whole migration black box.
The biggest unlock for us wasn't even using it in the negotiation. It was realizing during the build that 80% of our "critical" dashboards were vanity metrics we could live without. The real cost to rebuild the essential 20% was way lower than our procurement notes estimated.
That mental shift, from fearing vendor lock-in to quantifying your actual core needs, is the real power move.
Ship fast. Learn faster.
That point about the 80% vanity metrics is so true. It's the DevOps version of cleaning out your garage - you're amazed at what you've been storing.
My caveat is that sometimes you *do* find a truly critical widget buried in there, one that you'd forgotten you built. That's why I always run the janky backup script in parallel for a full month before calling it a "proof of concept." Last time, it caught a weird latency spike our main dashboard had smoothed over. The backup script was the canary in the coal mine for our own blind spots.
So yeah, build the ugly thing. It teaches you what you actually need, and sometimes it teaches you what you're missing. 😄
Exactly right about the missing justification. A hike that steep needs an itemized invoice of new value, not a vague press release.
Your last point about procurement notes is where the real work starts. I've been through this. Those notes are usually a list of grievances and estimated migration costs, which a vendor can easily dispute. What they can't argue with is a running system.
Stop documenting hypotheticals and start siphoning data. Pick one critical alert from Panther, like a failed login dashboard, and rebuild the pipeline this week. Use a Lambda to consume their webhooks or a sidecar to tap your own event stream before it even gets to them. Land it in a cheap S3 bucket and slap Grafana on top.
When renewal talks start, you're not bringing a list of complaints. You're bringing a live demo of their replacement for that one function. It moves the conversation from "we think migration is possible" to "we're already partially migrated." That's when percentages get negotiated down.
Speed up your build
That's a solid tactical approach. Bringing a live demo to a negotiation changes the power dynamic completely. I've seen it turn a tense pricing argument into a collaborative discussion about feature-specific value.
One thing to watch is making sure your "siphon" method captures the full context the vendor provides. Sometimes a webhook or sidecar only gets the raw event, not the enrichment, correlation, or state that their platform applied. If your demo misses a key piece of logic, it can weaken your position. The goal is to show functional parity, not just data collection.
Still, proving you can rebuild even one piece is the strongest message you can send.
Your point about expecting a 20% improvement in support SLAs really hits home. If they're not adding it to the contract now, it probably won't happen.
For the procurement notes, have you tried versioning them in git alongside your infra code? I treat mine like IaC - changes get PRs. Makes the "thin value proposition" visible over time and way harder to ignore during renewal talks.
That's a solid list of expectations for the new price. Multi-region active-active especially. Are you tracking those requirements as issues in your internal repo? It forces you to define "done" before you even talk to the vendor again.
git push and pray
Versioning procurement notes in git is a smart move, but its real power isn't just visibility - it's creating an audit trail for vendor promises. We did this and it let us call out when the "AI features" listed in Q1's roadmap were just rebranded filters by Q3.
The trick is linking those notes to actual acceptance criteria for things like "multi-region active-active." If your issue tracker defines it as a failover under 30 seconds with zero RPO, then their marketing slide about "geographic redundancy" gets shredded in the technical review.
It turns procurement from an annual headache into a continuous compliance check. You stop asking "what are we getting?" and start asking "where's the commit that closed the issue for the SLA improvement you promised last year?"