Structured content distribution is the decoupling of content from presentation through a headless CMS and Content as a Service (CaaS) architecture. It is a sound strategy for organizations managing complex content distribution networks across multiple channels. 

To be the most successful, this digital transformation requires organizations to change both their publishing workflows and their content ownership structures. Governance complexity affects 41% of CaaS adopters (PDF), workflow mismatches impact a third, and training requirements average 14 to 18 weeks. 

We have implemented these systems for clients in healthcare, financial services, and higher education, and the pattern is consistent: the three failures that kill structured content initiatives are the preview gap, the ownership vacuum, and the training deficit. Here is what we have learned about each one — and what actually works.

The Promise 

The pitch for structured content distribution is compelling: create content once, store it as modular data in a headless CMS, deliver it via API to any channel (web, mobile, kiosks, AI agents) without reformatting. The CaaS market is projected to reach $2.8 billion by 2035, and over 65% of enterprises have adopted headless CMS architectures.

What they do not tell you is that integration challenges affect 46% of adopters using legacy CMS platforms, and that 31% of enterprises encounter deployment delays exceeding six months. The technology works, but the governance requires just as much attention and is often overlooked. We have seen this avoidable pattern repeat across many structured content implementations.

Why Do Structured Content Migrations Stall?

In short, because organizations implement the technology without redesigning how their teams create, review, approve, and own content. That’s the governance problem.

A headless CMS decouples content from presentation. But most editorial teams have spent years, sometimes decades, working in systems where creating content and seeing how it looks are the same activity. WordPress, Drupal, and even SharePoint have a visual editing experience: build a page, see the page, publish the page.

Structured content does not work this way. Authors fill in fields like title, body, metadata, and related entries to publish content objects, not pages. As one analysis of Contentful’s editorial interface notes, “content editors work in structured content entry forms without seeing how content will render in production.” The front-end determines how those objects appear to users.

That architectural distinction is the correct one for consistent omnichannel delivery. It is also the one most likely to break editorial workflow expectations when teams do not deliberately plan for this big shift. In our experience, three governance failures account for the vast majority of structured content stalls.

What Is the Preview Gap, and Why Does It Derail Teams?

The preview gap is the loss of visual context that editorial teams experience when moving from a WYSIWYG (what you see is what you get) environment to a structured content interface, and it is the most immediate friction point in any headless CMS migration.

Authors who previously built pages visually are now filling in form fields and trusting that a front-end will render them correctly. The shift from “building a page” to “managing a content object” takes adjustment, and “once teams adapt, the structured approach tends to produce more consistent, reusable content.” The problem is what happens before they adapt.

What happens is that authors create workarounds. They paste formatted content into rich text fields, breaking the structured model. They submit tickets to developers asking “what will this look like?” multiple times per week. They maintain shadow documents in Google Docs so they can see their work in context. Every workaround is a governance failure — content that exists outside the system, formatting that undermines the content model, and developer time consumed by preview requests instead of feature development.

The planning that pays off includes building live preview environments for as many content sources as possible. This development work typically gets deprioritized because it is not user-facing, but it determines the success of the new system. As one migration guide puts it, headless platforms deliver excellent editorial experiences “when configured correctly — visual editing, live preview, flexible page-building, role-based permissions. But that configuration is work, it doesn’t happen by default.” Budget for it, build it first, and do not launch editorial access without it.

What Is the Ownership Vacuum?

The ownership vacuum is what happens when structured content crosses departmental boundaries without clear governance over who maintains the content model, who approves changes to shared components, and who is accountable when content is reused in a context the original author never intended.

In a traditional CMS, the marketing team owns the marketing pages, the product team owns product pages, etc. Structured content breaks this model deliberately — a product description created once might appear on the website, in a mobile app, in an email campaign, and through a chatbot simultaneously. But governance complexity affects 41% of CaaS adopters, and multi-team collaboration across 6 to 10 departments increases governance overhead by 27%.

Questions seldom asked include: 

We have seen organizations discover these questions six months post-launch, usually during a content audit that reveals inconsistencies no one can trace. In regulated industries — healthcare, financial services, higher education — those inconsistencies are compliance risks.

Knowing these pitfalls ahead of time can lead to the establishment of a content model governance board before migration begins. A small, cross-functional group (typically 3 to 5 people spanning content strategy, development, and compliance) owns the content model as a shared organizational asset. They approve changes to content types, evaluate reuse implications, and maintain a living inventory of where shared content objects appear. This role does not exist in traditional CMS organizations because it’s not needed. But in structured content environments, it is absolutely necessary.

Why Does the Training Deficit Compound Everything?

Because organizations allocate 90% of their transformation budgets to technology and implementation, and only 10% to change management — the part that determines whether anyone actually uses the system they built.

Training requirements for CaaS implementations average 14 to 18 weeks, the elapsed time from initial exposure to genuine editorial fluency. This training creates the confidence for authors to create, structure, and publish content without reverting to old habits or filing developer tickets. Most implementation budgets account for a one-day training session and a knowledge base article. The gap between that and actual fluency is where adoption dies.

The compounding effect of the training deficit makes this particularly damaging. Undertrained authors hit the preview gap and panic. Without clear governance ownership, there is no one to answer their questions authoritatively. They build workarounds. Those workarounds corrupt the content model. The corrupted content model undermines the case for structured content. Stakeholders lose confidence. The transformation stalls.

BCG’s study of 850+ companies found that only 35% of digital transformations meet their value targets globally. The failure rate is a change management problem that looks like a core problem with the technology itself.

To avoid this failure spiral, structure editorial onboarding as a phased engagement, not a one-and-done event. In our implementations, we start with a pilot group of 3 to 5 authors working with the system while the front-end is still being built. They surface friction points the development addresses in real-time. When the broader editorial team is onboarded, the common pain points have been resolved, and the pilot group serves as advocates who can answer questions and support their peers. This approach adds little cost and dramatically improves adoption velocity.

What Should Organizations Do Before Starting a Structured Content Migration?

Treat governance design as a foundation to build a successful digital transformation:

  1. Audit your editorial workflows as they actually operate. Map who creates content, who reviews it, who approves it, and where informal workarounds exist. As one migration planning guide advises, most publishing workflows “are often based on legacy systems, informal approvals, or staff availability. The result? Delays, missed steps, and content that never quite gets finished.” Your structured content governance must account for the real workflow, not the theoretical one.
  2. Define content model ownership before selecting a platform. Determine who will own the content model as an organizational asset, who can request changes, and what the approval process looks like. This governance structure should be platform-agnostic — it is an organizational decision, not a technical one. We have helped clients build this through our roadmapping and strategy engagements, and it consistently reduces mid-project governance confusion.
  3. Budget for editorial experience parity. If your authors currently have WYSIWYG editing, live preview, and visual page building, do not assume they will accept a simpler and more limiting form-based interface. Calculate the development effort required to provide contextual preview in your new architecture and include it in the implementation scope, not as a phase-two enhancement. Phase two rarely arrives before editorial frustration does.

Wrap Up

The CaaS pitch is not wrong. Structured content distribution is the right architecture for organizations publishing across multiple channels, and it is increasingly the right architecture for AI readiness — structured data is what AI systems consume most effectively. But the promise underestimates the organizational effort to make it successful.

Technology is the easy part. Governance, training, and editorial adoption are harder, and that is where implementations succeed or fail.

We have built these systems on Contentful, Drupal, and composable architectures for organizations in regulated industries where getting content wrong has real consequences. The lesson we keep relearning is the same one: start with the team, not the platform.

If your Drupal site relies on Acquia Search leveraging Solr, you’re likely facing a migration from Acquia Search to SearchStax. We’ve guided numerous organizations through this transition and want to share our proven approach to help you navigate this change successfully.

Before diving into the migration process, this transition presents an excellent opportunity to reassess your search strategy entirely. While Solr remains a powerful and robust solution, the search landscape has evolved significantly with innovative alternatives now available. For organizations considering broader platform transitions, this moment offers strategic value beyond search improvements. Modern React-based solutions can deliver dramatically faster user experiences. Our recent work with ONS demonstrates this potential—by replacing their Solr solution with Algolia Instant Search, we helped them achieve a 40% improvement in search response times while creating a more intuitive experience for their members.

Why the Move to SearchStax?

Acquia announced earlier this year that they’re sunsetting their Acquia Search offering in 2026, positioning SearchStax as the recommended migration path through their new partnership. This transition offers enhanced search capabilities and more direct control over your search environment through SearchStax’s comprehensive dashboard, providing visibility into Solr server performance, data analysis tools, search preview functionality, and advanced configuration options.

The architectural similarity ensures a seamless end-user experience—Solr remains the foundation, requiring no front-end changes for this migration path while delivering improved administrative control.

Our Proven Migration Framework

Through multiple successful migrations, we’ve developed a structured approach that minimizes risk and ensures smooth transitions. Here’s our step-by-step framework:

Phase 1: Foundation Setup

Phase 2: Testing and Validation

Phase 3: Production Implementation

Phase 4: Configuration Management

Phase 5: Transition Management

Addressing Technical Challenges

Our experience across multiple migrations has revealed common technical hurdles that require proactive attention. Configuration issues with Boost by Date Processor settings, Highlighted Fields errors during index rebuilding, and Facet configuration mismatches between environments are frequent challenges. The key to success lies in early identification during lower environment testing and leveraging Acquia support resources to resolve issues before they impact production.

Each migration presents unique challenges based on your specific configuration and content structure. Our approach prioritizes thorough testing and validation to surface these issues early, ensuring smooth production deployment.

Strategic Search Optimization

Successful migration extends beyond technical implementation. Understanding your content architecture, user behavior patterns, and business objectives enables you to optimize search effectiveness during the transition. This migration provides an ideal opportunity to evaluate search performance metrics, refine content indexing strategies, and enhance user experience design.

By following this proven framework and preparing for potential challenges, your organization can successfully transition to SearchStax while improving both administrative capabilities and user search experience. The result is a more robust, manageable search solution that positions your site for future growth and enhanced user engagement.

Our comprehensive migration expertise extends beyond search implementations to complete platform transformations, ensuring your digital infrastructure supports your long-term strategic objectives.

Ready to begin your SearchStax migration? Don’t wait until the 2026 deadline creates a migration rush. Our fixed-price SearchStax migration service ($2,500) provides the structured, proven approach outlined in this guide—from foundation setup through transition management. Get started with your SearchStax migration today.

Drupal has long been known for its flexibility, robustness, and scalability. But for many marketers and content creators, that flexibility can come with a steep learning curve — especially when it comes to building layouts and managing design without the help of a developer. That’s about to change in a big way.

Enter Drupal Canvas (previously called Experience Builder), a new initiative in Drupal that promises to radically streamline and simplify how we build and design pages. While still in its early stages, Experience Builder is ready for testing and experimentation — and it’s something marketers should absolutely have on their radar.

Complementary Drupal Canvas Implementation Consult

What is Drupal Canvas?

Drupal Canvas is the evolution of Drupal’s current method of flexible page building called Layout Builder. It takes what we know from layout builder and expands it into a unified, user-friendly tool that allows non-developers to build and theme websites directly in the browser. It’s a huge leap toward making Drupal more accessible for site builders, marketers, and content creators alike.

Unlike other page builders, Canvas doesn’t just provide drag-and-drop layout tools. It leverages Drupal’s core strengths — structured data, fine-grained access controls, and reusable components — to ensure consistency across channels and scalability across enterprise-level websites. This makes it uniquely powerful for large organizations managing multiple digital properties.

Dries Buytaert, Drupal’s founder, described it as a response to the fragmented landscape of site-building options in Drupal today. The vision is to consolidate functionality from tools like Paragraphs and Layout Builder into a single, cohesive solution. One that’s intuitive, efficient, and packed with modern capabilities.

Here is a fantastic video demo from DrupalCon Atlanta that was shown by Dries during the keynote address:

Why Now?

The timing couldn’t be better. While Layout Builder was a step in the right direction when it launched in 2018, its limitations became clear as more site builders demanded easier workflows, styling tools, and richer content composition features.

At recent Drupal conventions, the community has rallied around the idea of enhancing user experience across the board. As part of the broader Drupal CMS, Canvas is a key component in bringing Drupal’s usability in line with the expectations of modern content teams.

Why I’m Excited About It

As an engineer who has worked closely with Drupal for years, what excites me most is how Canvas can bridge the many gaps in Drupal’s current page-building ecosystem. Today, there are so many ways to structure content — Blocks, Paragraphs, Layout Builder, Panels — that choosing the right one can be overwhelming.

Drupal Canvas is shaping up to be that “one-stop-shop” we’ve needed. It reduces decision fatigue and gives teams a faster way to get projects off the ground without needing to architect every page structure from scratch.

Even better, it supports creating single-page overrides, component-level editing, and even React-based components right in the editor. That’s something I’ve personally looked forward to for a long time. The ability to build and save reusable components that can be dropped into any page makes this a tool that truly enhances productivity — not just for developers, but for marketers and content creators, too.

My First Look

I had the chance to see Drupal Canvas in action at DrupalCon Atlanta this year. The live demos were impressive and really opened my eyes to what this tool could do, both for newcomers to Drupal and seasoned site builders. Along with Drupal CMS, and recipes, Canvas is easily one of the hottest topics in the Drupal ecosystem right now.

The energy in the room during the sessions was palpable — people are genuinely excited about this. It’s not just another experimental module; it’s a shift in how we think about building on Drupal.

A Game-Changer for Marketers

One of the biggest barriers for marketing teams has always been reliance on developers to make even small layout edits. That’s starting to change.

With Canvas, non-developers will be able to build out dynamic, visually engaging pages — without needing to dive into code. That’s a massive win, especially for small teams in government, education, or nonprofit sectors, where resources are limited and time is of the essence.

Being able to make changes quickly, reuse content intelligently, and maintain a consistent brand without touching a template file is something many organizations have wanted for years. Drupal Canvas delivers on that promise.

Want to Try It Yourself?

If you’re curious to see what the buzz is about, you have two great options to get started:

  1. Try it yourself: Head to Drupal.org and download the latest version of Drupal CMS. It now comes with an optimized installer that makes getting started faster than ever. Once you’re up and running, you can add the Drupal Canvas module and start exploring.
  2. See it in action: Not ready to dive in alone? Schedule an implementation consultation with our team for a live demo and personalized guidance on how Drupal CMS can work for your organization.
Complementary Drupal Canvas Implementation Consult

Looking Ahead

It’s important to note that this is just the alpha version of the Canvas initiative. The team behind it is committed to rapid iteration and community feedback, which means what we’re seeing today is just the beginning.

If this is the foundation, I can only imagine how powerful the tool will become in the next year or two. The Drupal community is known for its collaborative spirit and constant innovation — and Canvas is shaping up to be one of the most important steps forward in years.

So if you’re a marketer, content strategist, or anyone who’s ever been frustrated by the limits of page building in Drupal — now’s the time to dive in. Drupal Canvas is here, and it’s ready to change the game. Ready to explore Drupal Canvas for your organization? Contact us for a complimentary consultation.

Digital accessibility can be difficult to stay ahead of. The laws have been evolving and now the European Union (EU) has entered the arena with their own version of the Americans with Disabilities Act (ADA).

If your business sells products, services, and/or software to European consumers, this law will apply to you.

The good news: 

The bad news:

Keep reading for a breakdown of how the Act works and what your business needs to prepare.

What is the European Accessibility Act? 

In 2019, the EU formally adopted the European Accessibility Act (EAA). The primary goal is to create a common set of accessibility guidelines for EU member states and unify the diverging accessibility requirements in member countries. The EU member states had two years to translate the act into their national laws and four years to apply them. The deadline of June 28, 2025 is now looming.

The EAA covers a wide array of products and services, but for those that own and maintain digital platforms, the most applicable items are:

Who Needs to Comply?

The EAA requires that all products and services sold within the EU be accessible to people with disabilities. The EAA applies directly to public sector bodies, ensuring that government services are accessible. But it goes further as well. In short, private organizations that regularly conduct business with or provide services to public-facing government sites should also comply.

Examples of American-based businesses that would need to comply:

There are limited exemptions. Micro-enterprises are exempt, and they are defined as small service providers with fewer than 10 employees and/or less than €2 million in annual turnover or annual balance sheet total.

What is required?

Information about the service

Service providers are required to explain how a service meets digital accessibility requirements. We recommend providing an accessibility statement that outlines the organization’s ongoing commitment to accessibility. It should include:

Compatibility and assistive technologies 

Service providers must ensure compatibility with various assistive technologies that individuals with disabilities might use. This includes screen readers, alternative input devices, keyboard-only navigation, and other tools. This is no different than ADA compliance in the United States.

Accessibility of digital platforms

Websites, online applications, and mobile device-based services must be accessible. These platforms should be designed and developed in a way that makes them perceivable, operable, understandable, and robust (POUR) for users with disabilities. Again, this is no different than ADA compliance in the United States.

Accessible support services

Communication channels for support services related to the provided services must also be accessible. This includes help desks, customer support, training materials, self-serve complaint and problem reporting, user journey flows, and other resources. Individuals with disabilities should be able to seek accessible assistance and information.

What are the metrics for compliance?

The EAA is a directive, not a standard, which means it does not promote a specific accessibility standard. Each member country can define its regulations for standards and conformance and define their penalties for non-compliance. Each country in which your service is determined to be non-compliant can apply a fine, which means that one infraction could accumulate fines from multiple countries. 

Just like the Americans with Disabilities Act, most EU member states are implementing Web Content Accessibility Guidelines 2.1 AA as their standard, which is great news for organizations that already invest in accessibility conformance.

If a member country chooses to use the stricter EN 301 549, which still uses WCAG as its baseline, there are additional standards for PDF documents, the use of biometrics, and technology like kiosks and payment terminals. These standards go beyond the current guidelines for business in the United States.

Accessibility overlays (3rd Party Widgets)

It should be noted that the EAA specifically recommends against accessibility overlay products and services — a third-party service that promises to make a website accessible without any additional work. Oomph has said for a long time that plug-ins will not fix your accessibility problem, and the EAA agrees, stating:

“Claims that a website can be made fully compliant without manual intervention are not realistic, since no automated tool can cover all the WCAG 2.1 level A and AA criteria. It is even less realistic to expect to detect automatically the additional EN 301549 criteria.”

The goals for your business

North American organizations that implemented processes to address accessibility conformance are well-positioned to comply with the EAA by June 28, 2025. In most cases, those organizations will have to do very little to comply. 

If your organization has waited to take accessibility seriously, the EAA is yet another reason to pursue conformance. The deadline is real, the fines could be significant, and the clock is ticking.

Need a consultation?

Oomph advises clients on accessibility conformance and best practices from health and wellness to higher education and government. If you have questions about how your business should prepare to comply, please reach out to our team of experts.

Additional Reading

Deque is a fantastic resource for well-researched and plain English articles about accessibility: European Accessibility Act (EAA): Top 20 Key Questions Answered. We suggest starting with that article and then exploring related articles for more.

The U.S. is one of the most linguistically diverse countries in the world. While English may be our official language, the number of people who speak a language other than English at home has actually tripled over the past three decades. 

Statistically speaking, the people you serve are probably among them. 

You might even know they are. Maybe you’ve noticed an uptick in inquiries from non-English speaking people or tracked demographic changes in your analytics. Either way, chances are good that organizations of all kinds will see more, not less, need for translation — especially those in highly regulated and far-reaching industries, like higher education and healthcare.

So, what do you do when translation becomes a top priority for your organization? Here, we explain how to get started.

3 Solutions for Translating Your Website

Many organizations have an a-ha moment when it comes to translations. For our client Lifespan, that moment came during its rebrand to Brown Health University and a growing audience of non-English speaking people. For another client, Visit California, that moment came when developing their marketing strategies for key global audiences. 

Or maybe you’re more like Leica Geosystems, a longtime Oomph client that prioritized translation from the start but needed the right technology to support it. 

Whenever the time comes, you have three main options: 

Manual translation and publishing

When most people think of translating, manual translation comes to mind. In this scenario, someone on your team or someone you hire translates content by hand and uploads the translation as a separate page to the content management system (CMS).

Translating manually will offer you higher quality and more direct control over the content. You’ll also be able to optimize translations for SEO; manual translation is one of the best ways to ensure the right pages are indexed and findable in every language you offer them. Manual translation also has fewer ongoing technical fees and long-term maintenance attached, especially if you use a CMS like Drupal which supports translations by default.

“Drupal comes multi-lingual out of the box, so it’s very easy for editors to publish translations of their site and metadata,” Oomph Senior UX Engineer Kyle Davis says. “Other platforms aren’t going to be as good at that.” 

While manual translation may sound like a winning formula, it can also come at a high cost, pushing it out of reach for smaller organizations or those who can’t allocate a large portion of their budget to translate their website and other materials. 

Integration with a real-time API

Ever seen a website with clickable international flags near the top of the page? That’s a translation API. These machine translation tools can translate content in the blink of an eye, helping users of many different languages access your site in their chosen language. 

“This is different than manual translation, because you aren’t optimizing your content in any way,” Oomph Senior UX Engineer John Cionci says. “You’re simply putting a widget on your page.” 

Despite their plug-and-play reputation, machine translation APIs can actually be fairly curated. Customization and localization options allow you to override certain phrases to make your translations appropriate for a native speaker. This functionality would serve you well if, like Visit California, you have a team to ensure the translation is just right. 

Though APIs are efficient, they also do not take SEO or user experience into account. You’re getting a direct real-time translation of your content, nothing more and nothing less. This might be enough if all you need is a default version of a page in a language other than English; by translating that page, you’re already making it more accessible. 

However, this won’t always cut it if your goal is to create more immersive, branded experiences — experiences your non-English-speaking audience deserves. Some translation API solutions also aren’t as easy to install and configure as they used to be. While the overall cost may be less than manual translation, you’ll also have an upfront development investment and ongoing maintenance to consider. 

Use Case: Visit California

Manual translation doesn’t have to be all or nothing. Visit California has international marketing teams in key markets skilled in their target audiences’ primary languages, enabling them to blend manual and machine translation. 

We worked with Visit California to implement machine translation (think Google Translate) to do the heavy lifting. After a translation is complete, their team comes in to verify that all translated content is accurate and represents their brand. Leveraging the glossary overrides feature of Google Cloud Translate V3, they can tailor the translations to their communication objectives for each region. In addition, their Drupal CMS still allows them to publish manual translations when needed. This hybrid approach has proven to be very effective.

Third-party translation services

The adage “You get what you pay for” rings true for translation services. While third-party translation services cost more than APIs, they also come with higher quality — an investment that can be well worth it for organizations with large non-English-speaking audiences.

Most translation services will provide you with custom code, cutting down on implementation time. While you’ll have little to no technical debt, you will have to keep on top of recurring subscription fees.

What does that get you? If you use a proxy-based solution like MotionPoint, you can expect to have content pulled from your live site, then freshly translated and populated on a unique domain. 

“Because you can serve up content in different languages with unique domains, you get multilingual results indexed on Google and can be discovered,” Oomph Senior Digital Project Manager Julie Elman says. 

Solutions like Ray Enterprise Translation, on the other hand, combine an API with human translation, making it easier to manage, override, moderate, and store translations all within your CMS. 

Use Case: Leica Geosystems

Leica’s Drupal e-commerce store is active in multiple countries and languages, making it difficult to manage ever-changing products, content, and prices. Oomph helped Leica migrate to a single-site model during their migration from Drupal 7 to 8 back in 2019. 

“Oomph has been integral in providing a translation solution that can accommodate content generation in all languages available on our website,” says Jeannie Records Boyle, Leica’s e-Commerce Translation Manager. 

This meant all content had one place to live and could be translated into all supported languages using the Ray Enterprise Translation integration (formerly Lingotek). Authors could then choose which countries the content should be available in, making it easier to author engaging and accurate content that resonates around the world.  

“Whether we spin up a new blog or product page in English or Japanese, for example, we can then translate it to the many other languages we offer, including German, Spanish, Norwegian Bokmål, Dutch, Brazil Portuguese, Italian, and French,” Records Boyle says.

Taking a Strategic Approach to Translation

Translation can be as simple as the click of a button. However, effective translation that supports your business goals is more complex. It requires that you understand who your target audiences are, the languages they speak, and how to structure that content in relation to the English content you already have. 

The other truth about translation is that there is no one-size-fits-all option. The “right” solution depends on your budget, in-house skills, CMS, and myriad other factors — all of which can be tricky to weigh. 

Here at Oomph, we’ve helped many clients make their way through website translation projects big and small. We’re all about facilitating translations that work for your organization, your content admins, and your audience — because we believe in making the Web as accessible as possible for all. 

Want to see a few recent examples or dive deeper into your own website translation project? Let’s talk. 

If you’ve been following along, Drupal 11 was set to be released during one of two windows in 2024 — either in July or later in the year in December — and a stable Drupal 11 release was just tagged earlier on Friday. The buzz is real because this major milestone is the first indicator that the community is on track to set the groundwork for the monumental efforts the Drupal community is rallying around with Drupal Starshot.

What is it?

Drupal 11 builds upon the significant updates that shipped with version 10.3, brings optimizations and the removal of old code, and sets the stage for upcoming releases that will support Drupal Starshot initiatives.

Drupal 10.4 (yet to be released) is being positioned as a long-term support (LTS) release that will continue to be supported until mid-2026, so there’s no urgency to update to Drupal 11 immediately. While in the past, site owners felt some urgency to upgrade as soon as possible, this time around there’s a longer runway before that needs to happen. That being said, sites will need to be upgraded to 10.3 before being updated to Drupal 11, so if you’re not yet on the current version of Drupal 10, that should be your priority.

Chart that outlines the proposed release schedule for Drupal 10, 11, and 12

Slide shared at Drupalcon Portland outlining release plan for v10 support through mid-2026

Why is it important?

Over time software at all points in your technology stack will see updates — at least that is what we hope for! — which means that not only does Drupal get updated, but the technologies that Drupal is built to run on will see updates, too. One of the most important changes with Drupal 11 is the new platform requirements that include updating to PHP 8.3.

PHP 8.3 brings significant performance improvements that will result in a faster Drupal application as well as the opportunity for lower costs to run the application, which means less impact on the environment — a definite win in our book. 

Beyond updates to support the latest and greatest platform versions, other improvements include the removal of some lesser-used core modules and deprecated code—so, some code-level housekeeping. 

Most importantly, the introduction of official LTS releases means that site owners will have a more predictable roadmap for when updates need to happen without feeling like they need to be early adopters when contributed modules may be lagging behind the new core releases.

Why are we excited about it?

With Drupal 11 cementing changes that were introduced with Drupal 10.3.x, updating dependencies, and removing lesser-used features, this release lays the foundation for the Drupal Starshot initiative to build upon and includes Single Directory Components (this provides support for a component-based development approach) and (experimental) Recipes support, which is a Starshot initiative feature that will allow sites to add new complete features to a site through bundled configuration settings.

Oomph has been contributing to the Starshot initiative since it was announced at Drupalcon, and we’re really looking forward to what’s ahead! We’re also thrilled to see Drupal in a position to adopt newer versions of the libraries and packages it depends on because that means streamlined development support and the benefits of the updates and improvements that those communities are making to their software reach us as well.

Drupal 11 Release changes

Notable changes to Drupal 11 include:

See the release notes for full details.

There’s a new acronym on the block: MACH (pronounced “mock”) architecture. 

But like X is to Twitter, MACH is more a rebrand than a reinvention. In fact, you’re probably already familiar with the M, A, C, and H and may even use them across your digital properties. While we’ve been helping our clients implement aspects of MACH architecture for years, organizations like the MACH Alliance have recently formed in an attempt to provide clearer definition around the approach, as well as to align their service offerings with the technologies at hand. 

One thing we’ve learned at Oomph after years of working with these technologies? It isn’t an all-or-nothing proposition. There are many degrees of MACH adoption, and how far you go depends on your organization and its unique needs. 

But first, you need to know what MACH architecture is, why it’s great (and when it’s not), and how to get started. 

What Is MACH?

MACH is an approach to designing, building, and testing agile digital systems — particularly websites. It stands for microservices, APIs, cloud-native, and headless. 

Like a composable business, MACH unites a few tried-and-true components into a single, seamless framework for building modern digital systems. 

The components of MACH architecture are: 

  1. Microservices: Many online features and functions can be separated into more specific tasks, or microservices. Modern web apps often rely on specialized vendors to offer individual services, like sending emails, authenticating users, or completing transactions, rather than a single provider to rule them all. 
  2. APIs: Microservices interact with a website through APIs, or application programming interfaces. This allows developers to change the site’s architecture without impacting the applications that use APIs and easily offer those APIs to their customers.
  3. Cloud-Native: A cloud-based environment hosts websites and applications via the Internet, ensuring scalability and performance. Modern cloud technology like Kubernetes, containers, and virtual machines keep applications consistent while meeting the demands of your users. 
  4. Headless: Modern Javascript frameworks like Next.js and Gatsby empower intuitive front ends that can be coupled with a variety of back-end content management systems, like Drupal and WordPress. This gives administrators the authoring power they want without impacting end users’ experience. 

Are You Already MACHing? 

Even if the term MACH is new to you, chances are good that you’re already doing some version of it. Here are some telltale signs:

If you’re doing any of the above, you’re MACHing. But the magic of MACH is in bringing them all together, and there are plenty of reasons why companies are taking the leap. 

5 Benefits of MACH Architecture

If you make the transition to MACH, you can expect: 

  1. Choice: Organizations that use MACH don’t have to settle for one provider that’s “good enough” for the countless services websites need. Instead, they can choose the best vendor for the job. For example, when Oomph worked with One Percent for America to build a platform offering low-interest loans to immigrants pursuing citizenship, that meant leveraging the Salesforce CRM for loan approvals, while choosing “Click and Pledge” for donations and credit card transactions. 
  2. Flexibility: MACH architecture’s modular nature allows you to select and integrate individual components more easily and seamlessly update or replace those components.  Our client Leica, for example, was able to update its order fulfillment application with minimal impact to the rest of its Drupal site. 
  3. Performance: Headless applications often run faster and are easier to test, so you can deploy knowing you’ve created an optimal user experience. For example, we used a decoupled architecture for our client Wingspans to create a stable, flexible, and scalable site with lightning-fast performance for its audience of young career-seekers.     
  4. Security: Breaches are generally limited to individual features or components, keeping your entire system more secure. 
  5. Future-Proofing: A MACH system scales easily because each service is individually configured, making it easier to keep up with technologies and trends and avoid becoming out-of-date. 

5 Drawbacks of MACH Architecture

As beneficial as MACH architecture can be, making the switch isn’t always smooth sailing. Before deciding to adopt MACH, consider these potential pitfalls. 

  1. Complexity: With MACH architecture, you’ll have more vendors — sometimes a lot more — than if you run everything on one enterprise system. That’s more relationships to manage and more training needed for your employees, which can complicate development, testing, deployment, and overall system understanding. 
  2. Challenges With Data Parity: Following data and transactions across multiple microservices can be tricky. You may encounter synchronization issues as you get your system dialed in, which can frustrate your customers and the team maintaining your website. 
  3. Security: You read that right — security is a potential pro and a con with MACH, depending on your risk tolerance. While your whole site is less likely to go down with MACH, working with more vendors leaves you more vulnerable to breaches for specific services. 
  4. Technological Mishaps: As you explore new solutions for specific services, you’ll often start to use newer and less proven technologies. While some solutions will be a home run, you may also have a few misses. 
  5. Complicated Pricing: Instead of paying one price tag for an enterprise system, MACH means buying multiple subscriptions that can fluctuate more in price. This, coupled with the increased overhead of operating a MACH-based website, can burden your budget. 

Is MACH Architecture Right for You? 

In our experience, most brands could benefit from at least a little bit of MACH. Some of our clients are taking a MACH-lite approach with a few services or apps, while others have adopted a more comprehensive MACH architecture. 

Whether MACH is the right move for you depends on your: 

  1. Platform Size and Complexity: Smaller brands with tight budgets and simple websites may not need a full-on MACH approach. But if you’re managing content across multiple sites and apps, managing a high volume of communications and transactions, and need to iterate quickly to keep up with rapid growth, MACH is often the way to go. 
  2. Level of Security: If you’re in a highly regulated industry and need things locked down, you may be better off with a single enterprise system than a multi-vendor MACH solution.  
  3. ROI Needs: If it’s time to replace your system anyway, or you’re struggling with internal costs and the diminishing value of your current setup, it may be time to consider MACH. 
  4. Organizational Structure: If different teams are responsible for distinct business functions, MACH may be a good fit. 

How To Implement MACH Architecture

If any of the above scenarios apply to your organization, you’re probably anxious to give MACH a go. But a solid MACH architecture doesn’t happen overnight. We recommend starting with a technology audit: a systematic, data-driven review of your current system and its limitations.

We recently partnered with career platform Wingspans to modernize its website. Below is an example of the audit and the output: a seamless and responsive MACH architecture. 

The Audit

  1. Surveys/Questionnaires: We started with some simple questions about Wingspan’s website, including what was working, what wasn’t, and the team’s reasons for updating. They shared that they wanted to offer their users a more modern experience. 
  2. Stakeholder Interviews: We used insights from the surveys to spark more in-depth discussions with team members close to the website. Through conversation, we uncovered that website performance and speed were their users’ primary pain points. 
  3. Systems Access and Audit: Then, we took a peek under the hood. Wingspans had already shared its poor experiences with previous vendors and applications, so we wanted to uncover simpler ways to improve site speed and performance. 
  4. Organizational Structure: Understanding how the organization functions helps design a system to meet those needs. The Wingspans team was excited about modern technology and relatively savvy, but they also needed a system that could accommodate thousands of authenticated community members. 
  5. Marketing Plan Review: We also wanted to understand how Wingspans would talk about their website. They sought an “app-like” experience with super-fast search, which gave us insight into how their MACH system needed to function. 
  6. Roadmap: Wingspans had a rapid go-to-market timeline. We simplified our typical roadmap to meet that goal, knowing that MACH architecture would be easy to update down the road. 
  7. Delivery: We recommended Wingspans deploy as a headless site (a site we later developed for them), with documentation we could hand off to their design partner. 

The Output 

We later deployed Wingspans.com as a headless site using the following components of MACH architecture:

  1. Microservices: Wingspans leverages microservices like Algolia Search for site search, Amazon AWS for email sends and static site hosting, and Stripe for managing transactions.
  2. APIs: Wingspans.com communicates with the above microservices through simple APIs. 
  3. Cloud-Native: The new website uses cloud-computing services like Google Firebase, which supports user authentication and data storage. 
  4. Headless: Gatsby powers the front-end design, while Cosmic JS is the back-end content management system (CMS). 

Let’s Talk MACH

As MACH evolves, the conversation around it will, too. Wondering which components may revolutionize your site and which to skip (for now)? Get in touch to set up your own technology audit.

Digital customer experience (DCX) is fast becoming a key factor in how consumers choose whom to do business with. Every digital interaction contributes to an overall feeling about your brand — which means digital touchpoints like apps and chatbots can play a big part in what customers think of your company.

What story do you want those interactions to tell? What kind of experiences do you want people to share with others?

This article covers five ways to assess and improve your digital customer experience so you can attract, delight, and retain your target customers.

But First – What IS Digital Customer Experience?

Customer experience, or CX, is the perception that customers form based on all of their interactions, in-person or online, with your brand. If CX is about carefully and consistently meeting your customers’ needs, Digital Customer Experience is the online expression of those efforts.

Digital customer experience is the part of your CX journey that involves digital interactions via your website, mobile app, social media accounts, digital kiosks, etc. Wherever your customers are engaging with your people, products, or services through the internet, it’s a digital experience.

DCX is their perception of those moments.

Brands with a great DCX provide a personalized and consistent online experience throughout the customer journey. Whether someone is considering becoming a client, placing an order, or searching for information, every digital interaction has to be easy and enjoyable.

5 Ways to Improve Your Digital Customer Experience

Technology is a wonderful tool for improving the customer experience, whether mining data for customer insights or leveraging AI for personalization. But technology alone can’t deliver an exceptional digital customer experience. Your DCX strategy must include a human component — one that focuses on customer care through empathy and authenticity. Here’s how to ensure your digital customer experience lives up to your users’ expectations.

Know your target audience

To deliver the kind of digital experience your customers will love, you have to know what they want. Who’s buying your product, and why? When they visit your website or app, what are they hoping to accomplish?

Delighting your customers requires knowing their goals, understanding their pain points, and providing interactions that meet their specific needs. The upshot? 68% of customers will spend more money with a brand that understands and treats them like an individual.

Here are three crucial steps:

  1. Use qualitative and quantitative analyses to learn about your audience. The more you understand their preferences and behaviors, the better you can create an experience that meets their needs.
  2. Apply a user-centered design process, which relies on deeply understanding your audience to craft usable, accessible digital interfaces.
  3. Incorporate personalization techniques to adapt the digital experience for individual users. More than anything else, this will help make the customer journey smooth and enjoyable.

Adopt an omnichannel mindset

Customers expect seamless interactions from brands throughout their journey, whether through digital or non-digital channels. In fact, brands with the strongest omnichannel customer engagement strategies retain an average of 89% of their customers, in comparison to 33% of companies with weak strategies.

Knowing that today’s consumers often jump from channel to channel as they browse, buy, or get in touch, DCX leaders embrace an omnichannel strategy. Note that this is different from a multichannel approach, where customers access multiple channels in separate interactions. An omnichannel approach integrates all digital touchpoints to create a seamless, personalized experience.

Multichannel: Some or all channels available but no data syncing between chgannels causing a disconnected customer experience. Omnichannel: All channels available with data syncing between channels providing a seamless customer experience.
Image sourced from Zingle.com

Here are a few key ways to create personalized experiences that resonate across all your digital channels:

Get help from experts

Expert assessments can remove the guesswork around optimizing your digital customer experience. A digital CX audit, for instance, will show you what’s working and what could be better, as well as providing actionable insights and a prioritized roadmap.

CX specialists will look beyond the basic digital experience (clunky design, system bugs, etc…) to assess whether your digital channels are effectively serving your customers’ needs. A professional audit can help determine things like:

Make customer feedback easy

Most companies know that customer feedback is crucial for improving the customer experience. But many fall short in providing easy, effective options for people to reach them.

Offering multiple, easy-to-use communication options across your digital channels is one more way to delight your customers. Help people engage with you via the medium of their choice, so they can communicate through the interface they’re most comfortable with.

That could be a chat function or contact form on your website, or the commenting and messaging features on your social profiles. Or, maybe it’s good old-fashioned phone calls and emails. Whatever the avenue, make it easy to find and intuitive to use.

One more thing: when someone does reach out, respond quickly. The faster a problem is resolved, the better the experience.

Plan for the post-launch reality

You might design and launch an amazing new website, app, or service that delights your customers and sends revenue through the roof. But, without a long-term plan to keep it effective and relevant, your digital CX will likely diminish over time.

To maintain the quality of customer experience across all your digital touchpoints, apply a measurement framework based on the principles above:

Remember, too, that new technological trends are going to keep emerging and influencing consumer expectations. Be prepared to evolve what digital CX looks like for your business, especially if it means extending your digital services to new platforms or devices.

Putting the “C” in Digital CX

Technology has made so many things possible for today’s consumers that, ultimately, the power is in their hands. As digital capabilities continue to evolve, people may become increasingly selective about which brands earn their trust and business — and companies will need to make the digital customer experience more beneficial for both sides.

As you can see from the steps above, the key is putting your customers’ needs above all else.

If you’re not sure where to start, you’re not alone! We’ve helped dozens of clients dive into customer research, omnichannel strategies, and strategic planning for digital platforms. Reaching out to a digital CX expert (like Oomph) can help you do things right the first time, saving you time and money and, most importantly, building a foundation to get results.

Excited about crafting an exceptional DCX? So are we. Check out our DCX audit service to learn how we can help set you up for success.

If you’ve been tossing around these two terms interchangeably, it’s okay. We won’t hold it against you. With some overlapping features and functionality, websites and digital platforms are easy to confuse at first glance.

In reality, they provide very different user experiences — and knowing the difference can be crucial to meeting your business needs.

How are Websites and Platforms Different?

The fundamental difference between a website and a digital platform lies in how you approach user engagement. Websites provide one-way engagement, with users ingesting whatever content the website delivers. Platforms offer reciprocal engagement, with interactions between a platform and its users generating personalized experiences.

Websites rely on implied audience data capture, meaning that users are grouped into broad buckets. If, say, lots of people click on a particular article, the site will assume that most visitors are interested in that topic and will feature it prominently. Essentially, websites are always working with the majority, not the individual.

By contrast, platforms use expressed data capture, where users provide identifying information by registering and logging in. Once someone becomes an authenticated user, you can learn about them directly through multiple touchpoints. That might include filling out forms, participating in discussions, adding comments, completing quizzes or surveys, or bookmarking content. By supplying a platform with real data, users get experiences tailored specifically for them.

Personalized data also allows platforms to streamline business workflows. Take HR processes, for example. When someone logs into a company intranet, they could receive a reminder to complete any unfinished HR forms — a tool that’s convenient and efficient for both the employee and the HR department.

Website Examples

Users generally can’t personalize anything on websites; they visit them for information. Here a few kinds of traditional websites:

Platform Examples

Platforms encourage users to actively contribute to the digital experience. Here are some examples of what you can do with a platform:

The Impact of Engagement

Owners of both websites and platforms are generally aiming to increase engagement as a measure of success. But what does that look like?

For a website, increased engagement is indicated by metrics like increased page views, longer “time on page” stats, lower bounce rates, and higher conversions (such as contact form completions or button clicks). Note that all of those metrics point to things that benefit website owners, not users.

News sites want more page views and longer page sessions so they can sell more advertising. Business sites get people to download whitepapers or fill out contact forms, generating sales leads. These are marketing websites designed to capture users’ interest. When a user clicks on a call to action, it shows they want to know more about what the site is advertising.

Platforms are more likely than websites to turn users into loyal brand ambassadors because they get something of value in return.

Once someone engages with a digital platform’s content, however, a two-way conversation begins. The goal is not to just push out content, but to ensure the audience interacts with it. That’s why platforms measure engagement in terms of personalization, community building, and loyalty metrics — things that indicate whether the platform is meeting the needs of both owner and users.

Platforms are also more likely than websites to turn users into loyal customers and brand ambassadors. To get someone to be an advocate for your company, they need to get something of value in return. Websites provide information that’s convenient, but users aren’t getting anything personal from the experience. A platform, by contrast, provides a highly personal connection between a business and its audience.

Which One is Right For You?

The answer, as with many things business-related, is that it depends on your goals.

The purpose of a website is to get users to consume content and return to the site to consume more. If you mainly need an informational site that serves as marketing for your business, a website is likely a good fit.

But what if you need more than that? Maybe community-building is important for your business, whether you need the network effects of a large user base (like social media) or you’re looking to increase employee engagement (as with an intranet). If your business goals require truly understanding your users and building meaningful two-way relationships, you need a digital platform.

In the end, it comes down to how much you need to personalize the user experience to support your business goals, and whether the extra engagement will provide a real return on investment. If you’re pushing out content for marketing purposes, go with a website. If personalization and loyalty are core factors in your business success, build a digital platform.

Looking for a partner to build the right platform for your business? Contact us today to learn how we can help.

In the age of hyper-personalization by the likes of Amazon and Netflix, customized user experiences are now table stakes for digital platforms. Businesses that invest in personalization are rewarded with loyalty and revenue. Those that don’t, get left behind.

But making that investment isn’t a straightforward affair. Many services that pitch themselves as personalization tools don’t even come close to creating a truly customized experience. And today’s savvy web users aren’t fooled:

Where we’ve seen businesses stumble is in substituting personification for true personalization. While personalization involves tailoring content based on direct personal information, personification is based on categories of consumers, not individual people.

Here’s what you need to know about the difference.

Perils of Personification

Gartner defines personification as “the delivery of relevant digital experiences to individuals based on their inferred membership in a defined customer segment, rather than their personal identity.” It’s the digital equivalent of calling someone “buddy” or “champ” because you can’t remember their name. I know that I know you, but I don’t know who you are.

Personification tools can track user behavior and use AI to place users into, say, one of several marketing personas you’ve developed. But in terms of driving meaningful, personalized interactions with users, personification falls down.

Here are a few critical issues with commonly used personification tools:

User Session Data

Information about a user’s interactions with an application is stored temporarily on the application’s server, not the browser.

EXAMPLE: During this session, I see that you’ve visited a piece of content that falls in a specific category. For the rest of your session, I can serve up other content tagged with the same category (often in Featured, Related, or You May Also Like sections).

PROBLEM 1: As soon as the browser session is closed, the user data is lost.

PROBLEM 2: The moment you switch from one device (e.g. mobile) to another (e.g. tablet) you lose all session data.

Contextual Data

Marketing automation or location intelligence software can use AI to gather environmental data about a user to deliver customized content or services.

EXAMPLE: I see that you’re in Los Angeles, California. Knowing your local weather, time zone, and other regional attributes, I can tailor the content you see to be more specific to your area.

PROBLEM: I have to ask you first if I can track your location, and you might say no.

First Party Cookie Data

By storing information about a user’s behavior directly on a domain, site owners can collect analytics data and remember language settings, among other functions.

EXAMPLE: Last time you visited my website, you commented on a certain piece of content. I may even have asked, “Do you want to see more of this type of content?” Now that you’re back, I can serve up newly published content of the same type. I can even feature it right on the homepage.

PROBLEM 1: I need to ask you if I can use cookies with you, and you can say no.

PROBLEM 2: If you clear the cookies in your browser, I’ll lose that valuable data.

PROBLEM 3: Another family member is using the same application on the same device, and now I’m getting mixed signals. This is completely messing with my AI.

Bottom line: personification is not really personalization. Even worse, you may lose your data and have to start from square one. To deliver true personalization, you need first-party data from authenticated users. Instead of guessing who your customer is, get to know who they really are.

Next-Level Personalization

True personalization is difficult to achieve outside of a digital platform, where people register as users (versus just casually visiting a website). Once someone becomes an authenticated user, it’s easier to learn a number of things about them.

83% of consumers are willing to share their data to enable personalized experiences. Platform users in particular are more open to providing personal information, because they’re specifically looking for a customized experience. With that first-party data, you can track preferences and interactions to improve the user experience. And you’re not going to lose the historical data when a user closes a session or clears their cookies.

Here are some key benefits:

Looking for Middle Ground?

In the end, you’ll deliver the best personalization (and earn the most engagement) by building an interactive platform and leveraging first-party data. But what if you have a decent website, and you’re not ready to shift to a platform?

You could approach it as a testing ground for personalization instead. By creating a series of micro-interactions using personification tools, you can test whether your users actually want a personalized experience, and if so, what they want to personalize.

Let’s say you’re a news outlet. You could just let people come and read your content online. At the next level, you can try to guess who they are through personification (via cookie requests, location prompts, etc.). If users are interacting with your prompts, it’s likely they’re interested in having a personalized experience.

Finally, you could build a platform for registered users and offer true personalization. You’ll not only deliver a better user experience, you’ll increase engagement and return visits — not to mention sales and other revenue.

At whatever level you can, go the extra mile and give your users what they want. We’re happy to help! Contact us today to learn more.

Not long ago, company intranets were little more than a repository for shared files, general announcements, and the all-important list of holiday office closures. Today, the humble intranet has evolved as a way to enhance internal communication and employee engagement and to help workers do their jobs.

While organizations tend to have more content- and feature-rich intranets these days, many are missing one crucial element: a mobile-optimized version. As a result, they can exclude a large proportion of workers—including the 80% of people who make up today’s Deskless Workforce.

Top “deskless” industries include education, healthcare, retail, hospitality, and transportation, employing many of the frontline workers we all depend on.

One of our own clients, a large hospital system, told us that 70% of their workforce doesn’t sit at a desk, nor do they use a computer every day. And if 70% of their employees can’t easily access the company intranet, they’re not provided equitable access to the same resources as everyone else.

Why Mobile Matters Today

In addition to the challenges of communicating with deskless workers, the rise of remote work and the growing number of Millennials in the workforce are helping to drive an increased demand for mobile-optimized or employee-app versions of intranets.

Consider this: the average American spends more than 5 hours a day on their phone (and it’s almost always within reach). In addition, nearly half of smartphone users access the internet primarily on their phones versus a desktop computer, laptop, or tablet. Those numbers are even higher for Millennials, who currently make up 35% of the US workforce.

Mobile communication plays an essential role in our personal lives. To serve employees, company intranets must offer the same ease-of-use, convenience, and capability to our work lives. The intranet must go beyond the desktop box to where workers are.

The Benefits of an Inclusive Intranet

In addition to facilitating access, mobile technology offers a number of unique benefits that can significantly improve employee engagement and productivity and help reduce frustration.

Here are some of the key benefits of a mobile-optimized intranet:

Real-Time Push Notifications

Imagine there’s an emergency situation in your facility, or an important update that staff need to receive immediately. You can push the information straight to their phone, enabling real-time communication across your workforce. Unlike emails, most push notifications get read within the first 3 minutes after they’re received.

Broader Access for BYOD

As more and more organizations support remote work and flexible schedules—while fewer and fewer provide company smartphones—the “Bring Your Own Device” trend has become more prevalent. Many of today’s employees are using personal devices to access work-related resources and systems. And, as we noted earlier, most of the time that means they’re using a smartphone.

Freedom from Workstations

In some organizations, employees are still sharing desktop workstations that we might charitably describe as “clunky.” It’s inefficient and inconvenient, especially when multiple people have to go out of their way to get to a workspace. A mobile-optimized intranet gives everyone fast and easy access to the same resources, wherever they are.

Two-Way Communication

Intranets have traditionally been top-down communication platforms, focusing primarily on the needs of employers, not employees. Today, companies looking to increase engagement have shifted to a new mindset: communication tools are no longer for talking to employees, but talking with them.

Mobile-optimized platforms and mobile apps help facilitate two-way conversations, especially with features like built-in chatting or social forums where employees can like and comment on posts. This allows companies to have more personalized conversations with employees in addition to collecting valuable, on-the-spot feedback from the front lines.

Remote Doesn’t Feel So Remote

Without regular in-person interaction, remote workers often feel isolated and less engaged. By offering more of an app-like experience with ongoing communication, an intranet can help recreate an environment that fosters idea sharing and boosts morale. It also means that employees who work at home, or don’t have access to a computer, won’t feel uninformed and isolated from the rest of the team.

Better User Experience

If you’re looking to use your intranet as a tool for engagement, you’ll get the best results from an employee app. An app lets you take advantage of mobile-native tools, like location detection and offline access, which let you both customize content and make it more readily available. The improved user experience, speed, and features are the reasons why most people prefer apps to websites.

An Intranet for Everyone

Like many organizations, the purpose of your intranet might be to create a more engaged workforce or improve employee productivity. But if most of your workers either can’t or don’t access the content, you’re not going to achieve your goals.

As cultures, companies, and industries move towards creating more inclusiveness and equity, organizations across the world are looking for ways to meet the needs of their employees. One way to address your team’s needs and expectations is to start by ensuring your internal resources are truly benefiting everyone who relies on them.

In 2023, Oomph’s design for the Lifespan Intranet was selected by the Nielsen Norman Group as one of the Ten Best Intranets globally.

Why are microservices growing in popularity for enterprise-level platforms? For many organizations, a microservice architecture provides a faster and more flexible way to leverage technology to meet evolving business needs. For some leaders, microservices better reflect how they want to structure their teams and processes.

But are microservices the best fit for you?

We’re hearing this question more and more from platform owners across multiple industries as software monoliths become increasingly impractical in today’s fast-paced competitive landscape. However, while microservices offer the agility and flexibility that many organizations are looking for, they’re not right for everyone.

In this article, we’ll cover key factors in deciding whether microservices architecture is the right choice for your platform.

What’s the Difference Between Microservices and Monoliths?

Microservices architecture emerged roughly a decade ago to address the primary limitations of monolithic applications: scale, flexibility, and speed.

Microservices are small, separately deployable, software units that together form a single, larger application. Specific functions are carried out by individual services. For example, if your platform allows users to log in to an account, search for products, and pay online, those functions could be delivered as separate microservices and served up through one user interface (UI).

In monolithic architecture, all of the functions and UI are interconnected in a single, self-contained application. All code is traditionally written in one language and housed in a single codebase, and all functions rely on shared data libraries.

Essentially, with most off-the-shelf monoliths, you get what you get. It may do everything, but not be particularly great at anything. With microservices, by contrast, you can build or cherry-pick optimal applications from the best a given industry has to offer.

Because of their modular nature, microservices make it easier to deploy new functions, scale individual services, and isolate and fix problems. On the other hand, with less complexity and fewer moving parts, monoliths can be cheaper and easier to develop and manage.

So which one is better? As with most things technological, it depends on many factors. Let’s take a look at the benefits and drawbacks of microservices.

Advantages of Microservices Architecture

Companies that embrace microservices see it as a cleaner, faster, and more efficient approach to meeting business needs, such as managing a growing user base, expanding feature sets, and deploying solutions quickly. In fact, there are a number of ways in which microservices beat out monoliths for speed, scale, and agility.

Shorter time to market

Large monolithic applications can take a long time to develop and deploy, anywhere from months to years. That could leave you lagging behind your competitors’ product releases or struggling to respond quickly to user feedback.

By leveraging third-party microservices rather than building your own applications from scratch, you can drastically reduce time to market. And, because the services are compartmentalized, they can be built and deployed independently by smaller, dedicated teams working simultaneously. You also have greater flexibility in finding the right tools for the job: you can choose the best of breed for each service, regardless of technology stack.

Lastly, microservices facilitate the minimum viable product approach. Instead of deploying everything on your wishlist at once, you can roll out core services first and then release subsequent services later.

Faster feature releases

Any changes or updates to monoliths require redeploying the entire application. The bigger a monolith gets, the more time and effort is required for things like updates and new releases.

By contrast, because microservices are independently managed, dedicated teams can iterate at their own pace without disrupting others or taking down the entire system. This means you can deploy new features rapidly and continuously, with little to no risk of impacting other areas of the platform.

This added agility also lets you prioritize and manage feature requests from a business perspective, not a technology perspective. Technology shouldn’t prevent you from making changes that increase user engagement or drive revenue—it should enable those changes.

Affordable scalability

If you need to scale just one service in a monolithic architecture, you’ll have to scale and redeploy the entire application. This can get expensive, and you may not be able to scale in time to satisfy rising demand.

Microservices architecture offers not only greater speed and flexibility, but also potential savings in hosting costs, because you can independently scale any individual service that’s under load. You can also configure a single service to add capability automatically until load need is met, and then scale back to normal capacity.

More support for growth

With microservices architecture, you’re not limited to a UI that’s tethered to your back end. For growing organizations that are continually thinking ahead, this is one of the greatest benefits of microservices architecture.

In the past, websites and mobile apps had completely separate codebases, and launching a mobile app meant developing a whole new application. Today, you just need to develop a mobile UI and connect it to the same service as your website UI. Make updates to the service, and it works across everything.

You have complete control over the UI — what it looks like, how it functions for the customer, etc… You can also test and deploy upgrades without disrupting other services. And, as new forms of data access and usage emerge, you have readily available services that you can use for whatever application suits your needs. Digital signage, voice commands for Alexa… and whatever comes next.

Optimal programming options

Since monolithic applications are tightly coupled and developed with a single stack, all components typically share one programming language and framework. This means any future changes or additions are limited to the choices you make early on, which could cause delays or quality issues in future releases.

Because microservices are loosely coupled and independently deployed, it’s easier to manage diverse datasets and processing requirements. Developers can choose whatever language and storage solution is best suited for each service, without having to coordinate major development efforts with other teams.

Greater resilience

For complex platforms, fault tolerance and isolation are crucial advantages of microservices architecture. There’s less risk of system failure, and it’s easier and faster to fix problems.

In monolithic applications, even just one bug affecting one tiny part of a single feature can cause problems in an unrelated area—or crash the entire application. Any time you make a change to a monolithic application, it introduces risk. With microservices, if one service fails, it’s unlikely to bring others down with it. You’ll have reduced functionality in a specific capacity, not the whole system.

Microservices also make it easier to locate and isolate issues, because you can limit the search to a single software module. Whereas in monoliths, given the possible chain of faults, it’s hard to isolate the root cause of problems or predict the outcome of any changes to the codebase.

Monoliths thus make it difficult and time-consuming to recover from failures, especially since, once an issue has been isolated and resolved, you still have to rebuild and redeploy the entire application. Since microservices allow developers to fix problems or roll back buggy updates in just one service, you’ll see a shorter time to resolution.

Faster onboarding

With smaller, independent code bases, microservices make it faster and easier to onboard new team members. Unlike with monoliths, new developers don’t have to understand how every service works or all the interdependencies at play in the system.

This means you won’t have to scour the internet looking for candidates who can code in the only language you’re using, or spend time training them in all the details of your codebase. Chances are, you’ll find new hires more easily and put them to work faster.

Easier updates

As consumer expectations for digital experiences evolve over time, applications need to be updated or upgraded to meet them. Large monolithic applications are generally difficult, and expensive, to upgrade from one version to the next.

Because third-party app owners build and pay for their own updates, with microservices there’s no need to maintain or enhance every tool in your system. For instance, you get to let Stripe perfect its payment processing service while you leverage the new features. You don’t have to pay for future improvements, and you don’t need anyone on staff to be an expert in payment processing and security.

Disadvantages of Microservices Architecture

Do microservices win in every circumstance? Absolutely not. Monoliths can be a more cost-effective, less complicated, and less risky solution for many applications. Below are a few potential downsides of microservices.

Extra complexity

With more moving parts than monolithic applications, microservices may require additional effort, planning, and automation to ensure smooth deployment. Individual services must cooperate to create a working application, but the inherent separation between teams could make it difficult to create a cohesive end product.

Development teams may have to handle multiple programming languages and frameworks. And, with each service having its own database and data storage system, data consistency could be a challenge.

Also, when you choose to leverage numerous 3rd party services, this creates more network connections as well as more opportunities for latency and connectivity issues in your architecture.

Difficulty in monitoring

Given the complexity of microservices architecture and the interdependencies that may exist among applications, it’s more challenging to test and monitor the entire system. Each microservice requires individualized testing and monitoring.

You could build automated testing scripts to ensure individual applications are always up and running, but this adds time and complexity to system maintenance.

Added external risks

There are always risks when using third-party applications, in terms of both performance and security. The more microservices you employ, the more possible points of failure exist that you don’t directly control.

In addition, with multiple independent containers, you’re exposing more of your system to potential attackers. Those distributed services need to talk to one another, and a high number of inter-service network communications can create opportunities for outside entities to access your system.

On an upside, the containerized nature of microservices architecture prevents security threats in one service from compromising other system components. As we noted in the advantages section above, it’s also easier to track down the root cause of a security issue.

Potential culture changes

Microservices architecture usually works best in organizations that employ a DevOps-first approach, where independent clusters of development and operations teams work together across the lifecycle of an individual service. This structure can make teams more productive and agile in bringing solutions to market. But, at an organizational level, it requires a broader skill set for developing, deploying, and monitoring each individual application.

A DevOps-first culture also means decentralizing decision-making power, shifting it from project teams to a shared responsibility among teams and DevOps engineers. The goal is to ensure that a given microservice meets a solution’s technical requirements and can be supported in the architecture in terms of security, stability, auditing, etc…

3 Paths Toward Microservices Transformation

In general, there are three different approaches to developing a microservices architecture:

1. Deconstruct a monolith

This kind of approach is most common for large enterprise applications, and it can be a massive undertaking. Take Airbnb, for instance: several years ago, the company migrated from a monolith architecture to a service-oriented architecture incorporating microservices. Features such as search, reservations, messaging, and checkout were broken down into one or more individual services, enabling each service to be built, deployed, and scaled independently.

In most cases, it’s not just the monolith that becomes decentralized. Organizations will often break up their development group, creating smaller, independent teams that are responsible for developing, testing, and deploying individual applications.

2. Leverage PBCs

Packaged Business Capabilities, or PBCs, are essentially autonomous collections of microservices that deliver a specific business capability. This approach is often used to create best-of-breed solutions, where many services are third-party tools that talk to each other via APIs.

PBCs can stand alone or serve as the building blocks of larger app suites. Keep in mind, adding multiple microservices or packaged services can drive up costs as the complexity of integration increases.

3. Combine both types

Small monoliths can be a cost-effective solution for simple applications with limited feature sets. If that applies to your business, you may want to build a custom app with a monolithic architecture.

However, there are likely some services, such as payment processing, that you don’t want to have to build yourself. In that case, it often makes sense to build a monolith and incorporate a microservice for any features that would be too costly or complex to tackle in-house.

A Few Words of Caution

Even though they’re called “microservices”, be careful not to get too small. If you break services down into many tiny applications, you may end up creating an overly complex application with excessive overhead. Lots of micro-micro services can easily become too much to maintain over time, with too many teams and people managing different pieces of an application.

Given the added complexity and potential costs of microservices, for smaller platforms with only one UI it may be best to start with a monolithic application and slowly add microservices as you need them. Start at a high level and zoom in over time, looking for specific functions you can optimize to make you stand out.

Lastly, choose your third party services with care. It’s not just about the features; you also need to consider what the costs might look like if you need to scale a particular service.

Final Thoughts: Micro or Mono?

Still trying to decide which architecture is right for your platform? Here are some of the most common scenarios we encounter with clients:

  1. If time to market is the most important consideration, then leveraging 3rd party microservices is usually the fastest way to build out a platform or deliver new features.
  2. If some aspect of what you’re doing is custom, then consider starting with a monolith and either building custom services or using 3rd parties for areas that will help suit a particular need.
  3. If you don’t have a ton of money, and you need to get something up quick and dirty, then consider starting with a monolith and splitting it up later.

Here at Oomph, we understand that enterprise-level software is an enormous investment and a fundamental part of your business. Your choice of architecture can impact everything from overhead to operations. That’s why we take the time to understand your business goals, today and down the road, to help you choose the best fit for your needs.

We’d love to hear more about your vision for a digital platform. Contact us today to talk about how we can help.