Sixty percent. That's the actual reduction in annual CMS costs we delivered for a mid-sized US bank regulated by the SEC and FINRA. Not a rounding error, not a negotiation trick - the real number, confirmed in the first month after go-live.
The bit that surprises people when I tell this story isn't the number. It's how long the bank had been sitting on the problem before anyone actually looked at it properly.
I want to walk you through this one, because if you're a CTO or managing partner at a regulated firm, there's a decent chance your platform costs look a lot like this bank's did. And there's an equally decent chance you've been avoiding the conversation about whether to do anything about it.
Our platform costs are high, but we know what we have. Switching is risky and disruptive.
I've heard that exact sentence - or something very close to it - in probably a dozen boardrooms over the past few years. And it's not wrong, exactly. You do know what you have. The question is whether what you have is worth what you're paying for it. In this case, the answer was a pretty emphatic no.
The bank had been running on Contentful. On paper, a perfectly respectable choice - it's a well-known headless CMS with a decent reputation. The reality on the ground was different.
Costs were climbing unpredictably. That's the word the SVP of Digital Technology used - "unpredictably." Not gradually, not in line with usage, but in ways that made annual budgeting feel like guesswork. I've been in budget meetings where someone asks why platform costs went up 30% that year and the honest answer is "because the pricing model changed and we added some content." It's a proper nightmare to explain to a CFO who's already sceptical about digital spend.
But the cost wasn't even the primary trigger. The bigger issue was governance. This is a bank regulated by the SEC and FINRA. Data governance and audit requirements aren't optional extras - they're existential. And Contentful, as a SaaS platform hosted on someone else's infrastructure, couldn't meet the bank's data residency and audit trail requirements. Content was sitting on infrastructure the bank didn't control, couldn't fully audit, and couldn't guarantee would survive the next round of regulatory scrutiny.
That combination - escalating costs and a governance gap that was only going to get wider - is what finally forced the conversation.
We ran a 14-day structured assessment across the dimensions that actually matter for a regulated financial institution: capability against current needs, technical debt, integration architecture, editorial experience, performance, security posture, and scalability.
What came back was revealing - and, honestly, a bit more stark than I'd anticipated. The bank was paying for a significant amount of platform capability it wasn't using. Contentful is a powerful tool, but like a lot of SaaS platforms, the pricing reflects the full breadth of what it can do, not what any given organisation needs it to do. The bank's actual content operations were relatively straightforward. They weren't running personalisation engines or complex multi-channel content orchestration. They were publishing research, maintaining regulatory content, and managing a website. Important work, but not work that required the overhead they were carrying.
The development team were sceptical when we first presented this back to them, and I don't blame them. They'd built their workflows around Contentful. They knew where the bodies were buried. The idea of migrating to a self-hosted open-source CMS - Payload, running inside the bank's own cloud environment - felt like a significant risk to people who'd spent years managing the existing setup. One of their senior engineers basically said, "so you want us to swap a known problem for an unknown one?" Which is a fair question.
We spent more time on that conversation than on almost anything else in the engagement. Not because the technical case was weak - it wasn't - but because the people doing the work every day needed to trust the recommendation before they'd commit to it. That's not something you can skip.
We presented three options. The short version: optimise the existing Contentful setup and accept the governance limitations; migrate to an alternative managed SaaS with better compliance controls; or move to self-hosted Payload CMS within the bank's own secure cloud environment.
The third option won on every dimension that mattered. Full control over data residency. Audit logging that fed directly into existing compliance systems. Role-based access controls configured to match their internal governance model. And dramatically lower costs, because the licensing model for an open-source, self-hosted CMS looks nothing like the per-seat, usage-based pricing of a managed SaaS platform.
I should be honest: we didn't recommend Payload because it's trendy or because we have some exclusive relationship with them. We recommended it because it was the right fit for this specific situation. A bank that needed absolute control over its content infrastructure, ran a competent development team, and was haemorrhaging money on a platform that offered more than they needed while delivering less than regulators required. If the assessment had pointed somewhere else, we'd have said so.
The migration ran alongside a full website redesign, which made the whole thing more efficient - we weren't trying to replicate the old site on new infrastructure, we were building what they actually needed.
Zero downtime during cutover. That matters more than it sounds when you're talking about a regulated bank. Any interruption to public-facing digital services in that environment triggers reporting obligations and some very uncomfortable conversations with compliance. So "zero downtime" isn't a nice-to-have metric - it's a hard requirement, and one we'd built the entire migration plan around.
The numbers after go-live: 60%-plus reduction in annual CMS costs. A 23% improvement in page speed. The development team's productivity improved noticeably too - partly because they were working with a modern, well-documented codebase instead of fighting platform constraints, and partly because the self-hosted model meant they weren't waiting on a vendor for changes that should have been routine. One of their developers told me, a few weeks after launch, that he'd forgotten what it felt like to just deploy something without filing a support ticket first. Small thing, but it stuck with me.
The compliance piece resolved itself almost as a side effect. Because the platform now lived inside the bank's own cloud environment, the audit trail, data residency, and access controls all fell under the bank's existing security governance. The compliance team could stand behind it without caveats. Their SVP put it well: the transition was "remarkably smooth" and the results "exceeded expectations." Which, given how sceptical some of the team had been at the start, felt like a genuine win.
Not to show off. I'm telling you because I've sat across the table from enough CTOs and managing partners in regulated firms to know that this story will sound familiar to some of you - except you haven't done anything about it yet.
Maybe your Sitecore licence renewal just came through and the number made someone wince. Maybe your Contentful bill has been creeping up and nobody's quite sure why. Maybe your compliance team has been making pointed comments about data residency that everyone's been politely ignoring. Maybe you've been quoted something eye-watering for a migration and decided the devil you know is cheaper than the devil you don't.
That last one is worth unpicking, because it's usually where the conversation stalls. The assumption is that migration is expensive, risky, and disruptive - and therefore the ongoing cost of the current platform is the safer bet. But when you actually run the numbers - and I mean really run them, including the maintenance overhead, the customisation costs, the opportunity cost of a development team spending half its time on workarounds, and the growing compliance exposure - the maths almost always points the other way.
I've written about the broader case for replatforming in The Replatform Reckoning, which includes a three-year TCO comparison that tends to make CFOs sit up. The short version: legacy maintenance typically runs $3-5m over three years, while a modern platform investment comes in at $2-3m with significantly better capability. Emergency migrations - the ones you do when something breaks or a regulator forces your hand - cost two to three times more than planned ones.
The question isn't really "can we afford to migrate?" It's "can we afford to keep paying for something that costs more than it should, delivers less than it could, and creates risk we can't fully quantify?"
If any of this is resonating, the starting point is simple. We run a 14-day assessment - not a sales exercise, an actual diagnostic - that looks at your current platform across the dimensions I mentioned earlier. What it's costing, what it's delivering, where the gaps are, and what the realistic options look like. Sometimes the answer is "actually, you're fine - optimise what you have." Sometimes it's "you need to move, and here's how."
For this bank, that assessment was the thing that turned a vague sense of "this is costing too much" into a clear business case with specific numbers and a defined path. The SVP told us afterwards it was the most useful two weeks they'd had from an external partner in years. I'd like to think that's because we told them the truth rather than what would have generated the biggest project fee.
If you want a quick sense of where your platform stands before any conversation, our Fragility of Digital Foundations scorecard takes about ten minutes and will give you a benchmark against the patterns we see across the sector.
Sixty percent cost reduction. Zero downtime. A compliance team that can actually sleep at night. It's not magic. It's just what happens when someone finally asks the question they've been putting off.