A platform that scaled. An architecture that didn't.
When I joined Ria's web team, the company operated in roughly 60 locales on Prismic. Over the next several years, we expanded into new markets, launched new products and services, and consolidated legacy sites into a single global website.
By the time we started evaluating a new CMS, we were managing more than 100 locales and 3,000+ pages across 40+ countries and territories. But the underlying content architecture had largely stayed the same: every page in every locale existed as its own standalone document, so a global update still had to be made manually, locale by locale, even when the content was identical.
When Ria's network grew past 600,000 locations worldwide, just updating that number across our localized homepages could take more than five hours of manual work.
Improving the workflow wasn't enough. We needed to rethink the architecture underneath it.
Where the old architecture broke down.
I started with a full audit of how we created and managed content: page types, components, locales, translation process, publishing workflows, and the recurring requests consuming the most time. Three structural problems kept coming up.
- Every locale required its own page, even when content was identical
- Launching a new locale meant recreating pages field by field
- Extending a promotion across 10 countries and 30 locales meant updating the same terms 30 separate times
- No way to push a shared change across all locales at once
- 1,000+ send/receive pages combining two different sets of country info
- No programmatic way to maintain shared sections
- Every new corridor page required a full manual build
- Duplication scaled linearly with every new market pairing
- Structure had grown around individual locales, not reusable content
- No good way to view pages across markets or organize beyond locale groupings
- Limited permissions and asset-usage visibility
- Blog ran on a separate CMS (WordPress), splitting the team across two platforms
Together, these issues pointed back to the same problem: we had built a global platform on a one-to-one content model. We needed to move toward one-to-many.
Evaluating platforms. Choosing Storyblok.
I started raising the need for a larger architectural change in 2024. From there, I led a structured CMS evaluation focused on the most impactful problems we needed to solve. I documented our requirements, met with vendors, and organized demos. We evaluated each platform against the realities of managing a global website: 100+ locales, complex language-country combinations, reusable and market-specific content, translation workflows, API flexibility, and the needs of a lean content team.
We evaluated an enterprise upgrade of Prismic alongside Storyblok, Contentful, Sanity, and Webflow.
Each had strengths. Contentful offered powerful custom content modeling and roles. Sanity was developer-friendly. But recreating the localization structure we needed on either would have required significant custom infrastructure. Webflow couldn't natively support the locale structure we needed, while upgrading Prismic still wouldn't solve the folder and global limitations at the center of the problem.
Storyblok mapped most closely to the architecture we wanted to build. Its folder structure fit our language-country model, and reusable and cascading components gave us a native way to solve the one-to-many problem.
Its APIs gave engineering room to extend the platform, while the Visual Editor gave the content team a better day-to-day editing experience. Just as importantly, it gave us room to build the workflows we wanted next rather than recreating the ones we already had.
I brought the recommendation through marketing and product leadership and worked through the final commercial terms. We signed with Storyblok at the end of 2025.
From one-to-one to one-to-many.
The most important change wasn't the CMS itself. It was how we structured the content inside it.
The principle was simple: reuse what should be global, and keep local what genuinely needs to be local.
That distinction matters at Ria. Our locales aren't just translations of the same website. Products, services, payment methods, promotions, limits, and legal requirements can all vary by market. A scalable architecture couldn't flatten those differences. It needed to make them easier to manage.
We approached that in three ways.
Old: every page is a standalone document. A change means 100+ manual edits.
New: content lives once, referenced everywhere. A change means 1 edit.
Result: a lean team manages 5,000+ pages across 100+ locales.
- One document per page per locale
- Identical content duplicated across 100+ locales
- Global updates required manual changes to each document
- No folder structure beyond locale grouping
- New locales required full page rebuilds
- Blog running on a completely separate CMS
- Asset management at page/slice level only
- Reusable global components referenced across markets
- Content keys for dynamic values updated in one place
- Programmatic and AI-assisted translation and content workflows
- Full folder structure: global, country, page type
- New locales via translation workflow, not rebuild
- Blog unified onto the same platform as the rest of the site
- Global asset management with page-level tracking
Reusable global components. Shared sections (promotional banners, trust modules, app CTAs) get created centrally and referenced across market-specific pages as linked blocks. Take a homepage update: before, that meant editing the same section individually across all 100+ locale homepages, at roughly three minutes each, or about five hours of manual work. Now that same section lives as one global component. We edit it once in English, run it through AI translation, and it cascades to every locale automatically, in roughly five minutes.
Content keys. Frequently repeated values can live as centrally managed keys rather than being typed independently into every page. One update propagates everywhere they're referenced. We can also use content keys to programmatically adapt information displayed on a page based on query parameters.
Programmatic and AI-assisted workflows. We partnered with engineering to build new tools around the structured content model, including workflows for managing content at scale and AI-assisted translation. New locales and updates can now move through the platform without rebuilding pages field by field, with the content team retaining control over review and quality.
Redesigning the experience around the content.
We didn't want to spend two quarters migrating the limitations of the old website into a better CMS. So the migration became an opportunity to rethink the platform more broadly: its content model, components, URL structure, information architecture, and UX.
Some of that work had already started. When I joined Ria's web team, our main navigation was largely transactional: track a transfer, find a location, get help. Over the following years, I led my team in building out a much deeper acquisition-focused content ecosystem, including ways-to-send pages, receive-method pages, regional hubs, B2B partner landing pages, and more than 1,000 money transfer corridor pages.
The CMS migration gave us the opportunity to bring that content architecture together with a new global UX design system. I led the content strategy and information architecture behind that experience, partnering with our UX and brand teams on the redesign and with engineering on the components needed to support it.
The result is a website designed around both sides of the customer journey: helping existing customers complete tasks, while giving prospective customers a clearer way to understand where they can send money, how recipients can receive it, and which Ria products and services are available in their market.
The "Money transfer" dropdown surfaces the content architecture we built: ways to send, popular send-to countries, regional hubs, and the receive methods available in each market. The nav is the content strategy made visible.
Cross-functional from day one.
A migration at this scale was cross-functional from the beginning. The development team roughly doubled over the course of the project, with content, SEO, design, and product all dedicating time directly to the work. I led the content strategy and architecture work and served as a bridge across those teams throughout the migration.
We created a migration workflow inside Storyblok that moved each piece of content through a clear set of stages:
- Migration audit — mapping every page and asset that needed to move
- Content in progress — rebuilding on the new content model in Storyblok
- Design review — validating against the new global UX system
- Translation — running through AI-assisted translation with content-team review
- Ready to publish — QA, SEO checks, and scheduled release
We originally planned to launch region by region. Chile came first, with three locales, as our proof of concept. It gave us a contained market where we could validate the architecture, design system, components, and workflows in production.
The US followed. As our largest digital market and the country with the most content, it gave us the opportunity to finish many of the templates, tools, and page types the rest of the rollout would need.
Our original roadmap called for several more regional phases after that. But once Chile and the US had validated the system, we changed course: instead of continuing market by market, we launched every remaining country and locale globally at once.
The full migration went live in June 2026, completing the core Prismic-to-Storyblok migration within the two quarters we had planned.
What changed after launch.
Today, more than 5,000 pages across 100+ locales run on the new architecture, with the blog now migrated and live on Storyblok rather than operating separately in WordPress. But the biggest change is how the platform scales.
Global content changes take minutes instead of hours. Updates that once required editing the same information across dozens or hundreds of documents can now originate from a shared source.
New locale launches require about 75% less content-team labor. Based on internal ticket tracking, building the core page set for a new locale previously took an estimated 30 to 75 hours, with translation adding additional turnaround time. On the new architecture, that same work takes an estimated 8 to 16 hours. Individual workflows show the same improvement: a landing page that used to take four to five hours now takes about one, while one team member's full locale build has dropped from three to four days to roughly two to three hours.
Our global content and SEO team stayed the same size while the website grew from roughly 3,000 pages to more than 5,000. Engineering has a better foundation to build on, too: before the migration, developers estimated that roughly half of their week went toward maintenance and content-related requests rather than new features. The new architecture reduces the repetitive work created every time the site grows.
Performance improved too. Lighthouse scores increased by roughly 20 points on both desktop and mobile, with the largest gains in LCP and CLS.
The migration solved an existing problem. The more important outcome is what it prevents next: adding another market no longer means adding the same amount of manual work, and creating another thousand pages doesn't have to create another thousand independent things to maintain.
Now the content and platform can keep growing without the work growing with it.