We delivered a 60% reduction in annual CMS costs for a mid-sized US bank regulated by the SEC and FINRA. The comparison used the bank's costs in the first month after go-live.
The length of time the bank had been carrying the problem matters as much as the headline number. Platform familiarity had made rising cost and an unresolved governance gap seem safer than change.
If you are a CTO or managing partner at a regulated firm, that tension may be familiar. You know how the current platform behaves, and migration introduces risk. The decision is whether that familiarity remains worth its cost and whether the platform still meets the controls your organisation requires.
What we walked into
The bank had been running on Contentful, a well-known headless CMS. The platform was capable, but the fit had deteriorated.
Costs were climbing unpredictably. That is the word the SVP of Digital Technology used: “unpredictably”. The changes did not follow a pattern the team could readily connect to usage, which made annual budgeting feel like guesswork. A CFO who is already sceptical about digital spend will reasonably challenge a cost increase that the technology team cannot explain.
Cost was not the primary trigger. Governance was. The bank's compliance and technology teams had defined data residency, control and audit requirements that the existing SaaS arrangement did not meet. Content was sitting on infrastructure the bank did not control or audit to the standard it required.
Escalating costs and a widening governance gap finally forced the conversation.
The assessment
We ran a 14-day structured assessment covering the dimensions that mattered for this institution: capability against current needs, technical debt, integration architecture, editorial experience, performance, security posture and scalability.
The bank was paying for a significant amount of platform capability it did not use. Contentful is a powerful tool. Like many SaaS platforms, its commercial model covers a breadth of capability that this organisation did not need. The bank's content operations were relatively straightforward: publishing research, maintaining regulatory content and managing a website. It was not running the personalisation or complex multi-channel orchestration that could have justified the overhead.
The development team were sceptical when we presented the finding. They had built their workflows around Contentful and understood its workarounds. Moving to a self-hosted open-source CMS, Payload running inside the bank's cloud environment, transferred responsibility as well as control. One senior engineer asked whether we wanted them to swap a known problem for an unknown one. That was a fair challenge.
We spent more time on that conversation than on almost anything else in the engagement. The people doing the work every day needed to trust the recommendation and understand the operational consequences before they would commit to it.
Comparing three viable options
We presented three options:
- Optimise the existing Contentful setup and accept the remaining governance limitations.
- Migrate to an alternative managed SaaS platform with controls better aligned to the bank's requirements.
- Move to self-hosted Payload CMS within the bank's secure cloud environment.
The third option performed best against the bank's chosen criteria. It gave the bank control over data residency, audit logging connected to its existing compliance systems, and role-based access controls configured for its governance model. It also reduced licence costs because an open-source, self-hosted CMS has a different cost structure from a per-seat, usage-based managed SaaS platform.
Self-hosting is not free. The organisation becomes responsible for infrastructure, monitoring, upgrades, security and operational support. This bank had the cloud environment, engineering capability and governance processes to carry those responsibilities. A firm without those foundations could reach a different conclusion from the same comparison.
We recommended Payload because it fit this specific situation. If the assessment had pointed elsewhere, we would have said so.
What happened during migration
The migration ran alongside a full website redesign, so we could build what the bank needed instead of replicating the old site on new infrastructure. Combining the work also meant that content models, editorial workflows and front-end components could be designed around the new operating model.
The cutover had zero downtime. The bank treated continuity of its public-facing service as a hard launch requirement, and we built the migration plan around it.
After go-live, annual CMS costs were more than 60% lower and page speed had improved by 23%. The development team's productivity improved too, partly because they were working with a modern, documented codebase and partly because the self-hosted model removed vendor dependencies from routine changes. One developer told me a few weeks after launch that he had forgotten what it felt like to deploy something without filing a support ticket first.
Hosting the platform inside the bank's cloud environment brought the audit trail, data residency and access controls under its existing security governance. The compliance team could stand behind the arrangement. Their SVP described the transition as “remarkably smooth” and said the results “exceeded expectations”.
What other firms should take from the case
The useful lesson is not that every regulated firm should move from Contentful to Payload. Platform fit depends on the required controls, content operation, integration estate, internal capability and cost horizon.
The lesson is to compare the familiar platform with the organisation's current requirements rather than with the disruption of migration alone. A complete comparison includes:
- Current and forecast licence costs.
- Hosting, monitoring and support.
- Internal engineering and editorial time.
- Workarounds and manual processes created by platform constraints.
- Integration changes likely over the next three to five years.
- Data residency, access, audit and security controls.
- The cost of planned migration and the risk of a forced one.
- Capability the organisation is paying for but does not use.
Migration is expensive, risky and disruptive. The current platform also carries ongoing cost and risk. A useful business case makes both visible and separates costs that will genuinely disappear from those that will move into a different budget line.
For example, removing a SaaS licence does not remove the need for hosting, security maintenance or skilled support. A credible total-cost comparison includes them. It should also value the internal capacity consumed by a platform, while avoiding the easy mistake of treating every hour released as a cash saving.
I've written about the broader comparison in The Replatform Reckoning. Use your own licence, support, delivery and internal-capacity figures. A generic benchmark cannot decide whether migration is justified for your firm.
What we'd do for you
Our 14-day assessment examines what your current platform costs, what it delivers, where its risks and constraints sit, and which options are realistic. Sometimes the recommendation is to optimise what you have. Sometimes it is to move, with a clear explanation of how.
For this bank, the assessment turned a vague sense that the CMS cost too much into a business case with specific options and a defined path. The SVP later described it as the most useful two weeks they had received from an external partner in years.
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.
For this bank, the outcome was a 60% cost reduction, zero downtime at cutover and a platform that met the controls its compliance team had set. It began with a direct comparison between the familiar platform and the bank's actual requirements.
