Uneditable Drupal website: how we avoided a costly rebuild and lifted conversion ~24%

Before committing to a costly website rebuild, it's worth asking one question: is the platform actually the problem - or was it never set up to do what it's capable of?

An uneditable Drupal website - a Drupal site where the marketing team can't change text, images, or layout without filing a developer ticket - is one of the most common reasons companies decide to rebuild from scratch. This is the story of a multinational benefits company that almost made that expensive mistake.

The company came to us with a clear message: "We want to rebuild our website from scratch. On a different platform."

Their reasoning was hard to argue with. The marketing team couldn't edit even basic text on the site. Every change - no matter how small - required a developer ticket. The team had resorted to uploading static images in place of editable content, because that was the only way to get anything updated without waiting days. The result? A site that wasn't responsive on mobile, performed poorly in search engines, and looked increasingly outdated.

They had already drafted an RFP for a brand new website. Drupal - the platform their site was built on - wasn't even mentioned as a candidate technology. As far as the client was concerned, Drupal was the problem.

We looked at the site and saw something different. The problem wasn't Drupal. It was how Drupal had been implemented. And fixing the implementation would cost a fraction of what a full rebuild would require.

This is the story of how we talked a frustrated corporate client out of an expensive mistake - and turned their existing CMS into a tool they now actively invest in.

In this article:

• Why your Drupal website feels uneditable
• Rebuild or modernize an uneditable Drupal site?
• How do you modernize a Drupal site instead of rebuilding it?
• What were the results?
• Is your Drupal website uneditable? How to tell
• The takeaway

Why your Drupal website feels uneditable

The client's website was built on Drupal, a technology mandated by their global headquarters. It technically had Drupal Paragraphs - one of the most powerful content management features available in the Drupal ecosystem - installed. But "installed" and "properly configured" are two very different things.

In practice, the Paragraphs module was present in the codebase but never wired up correctly. Content editors had no meaningful way to create or modify page content through the CMS. The admin interface didn't guide them. The paragraph types existed in the database but weren't connected to the editing workflow in a usable way. This is a textbook sign of an uneditable Drupal website: the tools exist, but editors cannot reach them.

So the marketing team did what any resourceful team would do: they found a workaround. Instead of fighting with the CMS, they started uploading images - screenshots of text, graphics with product information baked in, visual mockups saved as JPEGs and dropped into the site. It is a pattern we see often, and the SEO and accessibility costs add up quickly.

It worked, sort of. Content got updated. But the side effects were serious:

• No responsiveness. Images don't reflow for different screen sizes. The site looked broken on mobile and failed basic accessibility expectations.
• SEO damage. Search engines can't index text inside images, which is one reason structured, editable content matters for SEO. The site was becoming invisible.
• Poor loading performance. Heavy image files slowed everything down.
• Complete rigidity. Changing a single word meant re-creating the entire graphic.

From the client's perspective, they had a CMS that didn't let them manage content. The logical conclusion was that they needed a different CMS. They started exploring options for a completely new site on a completely new platform.

Read also: why your Drupal site feels broken even when the platform is fine and what legacy modernization looks like when the implementation is the problem.

Rebuild or modernize an uneditable Drupal site?

When we examined the situation, we saw two paths forward with very different costs, timelines, and risks.

The client's plan was Path A: a full rebuild on a new platform - 6-18 months of work, a significant budget, the risk of a new vendor and technology stack, and the near-certain loss of SEO equity and URL continuity, with no guarantee the new build would be configured any better than the old one.

We proposed Path B: fix what's already there. The Drupal installation was functional and the core technology was current and actively maintained. The problem lived entirely in the implementation layer - specifically, in how the Paragraphs system had been (not) configured. Keeping the existing install and properly implementing universal, reusable components would cost a fraction of the rebuild and still deliver a modern, editable, responsive site through Drupal modernization, not replatforming.

Our client was firmly a modernize case: the platform could do everything they needed; it had simply never been given the chance. We won't reproduce the full rebuild-versus-modernize decision logic here - for the cost breakdown, the narrow cases where rebuilding genuinely makes sense, and a phased framework you can apply to your own site, see our companion guide on phased CMS modernization.

How do you modernize a Drupal site instead of rebuilding it?

We didn't propose a multi-month project. We proposed a focused, phased approach that would deliver visible results quickly and build from there.

Step 1: understand the real needs

Before opening any design tool, we sat down with the marketing team for a series of discovery meetings. No designers, no wireframes - just conversations about what they actually needed to do on the site and what was blocking them.

The insight was clear: in our discovery sessions, editors said the vast majority of their frustration came from not being able to edit content. They didn't need new features. They didn't need a different architecture. They needed the ability to update text, swap images, rearrange sections, and create new landing pages - things that any properly configured CMS should handle out of the box.

Step 2: design universal components

Based on those conversations, our design team created a set of paragraph components - not page layouts, but reusable building blocks. Each component was designed in 3-4 color variants, so the marketing team could choose between a light background, dark background, branded colors, or neutral styling depending on context.

Every component received a dedicated mobile layout. Not a "shrunk-down desktop version" - a separately designed mobile experience that works natively on smaller screens.

The key design principle: universality. Each component needed to work across product pages, landing pages, event announcements, and contexts we hadn't thought of yet.

Step 3: build it properly

The development work was straightforward once the design was in place. We implemented Drupal Paragraphs correctly - each section of every page became an independent, editable component that content editors could add, remove, reorder, and configure. For a full breakdown of what separates a broken Paragraphs setup from an editor-friendly one, see our deep dive on implementing Drupal Paragraphs properly.

We replaced image-based content with real, editable text - complete with proper heading structure (H1, H2, H3) for SEO. We modernized the admin panel with the Gin theme to give editors a contemporary, intuitive interface instead of the dated default.

Read also: a quick way for editing and customizing a Drupal paragraph and the Geysir module for faster paragraph editing.

Step 4: hand over without a training session

Instead of scheduling formal training, we built a complete example page on the staging environment using every available paragraph type and variant. The marketing team explored it at their own pace, clicking through options and experimenting with content.

When they moved to production, they started creating pages on their own. No training manual. No workshop. The system was intuitive enough that they could figure it out by doing - which is exactly how a CMS should work. We break down the staging-first, zero-training handover in a separate guide.

What were the results?

The impact showed up on two levels: measurable business numbers in the short term, and a deeper shift in how the client worked with their own platform over time.

What was the immediate business impact?

The first page we rebuilt was a gift card landing page, launched just in time for the holiday season - a critical business period for the client. The result: approximately 24% increase in conversion rate compared to the old image-based version.

Content editors began creating new landing pages independently. They built pages for new products, webinar promotions, and event announcements - all without submitting a single developer ticket. They ordered 6-9 new paragraph types to expand their toolkit further.

What changed beyond the numbers?

Something more significant happened beyond the numbers. The client stopped asking for "pages" and started asking for "components." They evaluated new paragraph designs based on how universal and reusable they would be. They began thinking like system designers - not because we taught them to, but because the component-based approach made it natural. For what that shift looks like in practice, see our guide to teaching clients to think in components.

The marketing team discovered that paragraphs designed for product presentations worked beautifully for webinar announcements. Fields intended for product descriptions were repurposed for event dates and details. The system was being used creatively, in ways we hadn't planned for - a reliable sign that the architecture is working.

Why was recovering trust the real win?

The client went from planning to abandon Drupal entirely to actively investing in the platform. They believe in the technology now - not because of a sales pitch, but because it started delivering real business results. That shift in trust is worth more than any single conversion metric.

The approach was later replicated with another client of ours who was in a nearly identical situation - ready to leave Drupal, frustrated with a non-functional CMS, drafting an RFP for a new platform. Having a proven case study made the conversation much easier.

Is your Drupal website uneditable? How to tell

If any of the following sound familiar, your uneditable Drupal website might be a candidate for modernization rather than a rebuild:

Red flags that suggest implementation failure, not platform failure:

• Your CMS has features that your team can't actually use
• Content editors avoid the CMS and use workarounds instead (uploading images, emailing developers with change requests)
• The site looks outdated, but the underlying technology is current
• Someone has said "it can't be done in our CMS" without offering a detailed technical explanation
• There's an RFP draft for a new website that doesn't mention your current platform

Five questions to ask before deciding to rebuild:

1. Has anyone with platform expertise audited whether the current CMS features are properly configured?
2. Can a specialist demonstrate what the CMS is actually capable of when set up correctly?
3. What would it cost to fix the implementation compared to starting from scratch?
4. How much content, SEO equity, and institutional knowledge would be lost in a platform migration?
5. Is the team frustrated with the platform itself, or with the experience of using it?

If even two of those questions give you pause, it's worth getting a second opinion before committing to a rebuild.

The takeaway

Rebuilding a website from scratch is sometimes the right call. But it's the right call far less often than most people assume. In many cases - especially with mature platforms like Drupal - the technology is fully capable of delivering what the business needs. If you have an uneditable Drupal website, the gap is almost always in the implementation, not the platform.

The cheapest, fastest, and lowest-risk website project is the one you don't have to start from zero. Before you sign a rebuild contract, invest in understanding what your current platform can actually do. You might be one proper implementation away from the site your team has been asking for.

Thinking about a rebuild? Get a second opinion first

This case study is based on a real production project for a multinational benefits company, where we modernized an existing Drupal site instead of rebuilding it from scratch. The result was an editable, responsive, component-based platform, an approximately 24% conversion increase on the first rebuilt page, and a client who now actively invests in expanding the system. The site has been running in production for months.

Wondering whether your own site needs a full rebuild or just a smarter implementation? Our team specializes in getting the most out of existing Drupal platforms, from properly configured Paragraphs to editor-friendly admin experiences. Visit our Drupal development services to find out what your current platform is really capable of.