Re-platforming websites into Jamstack

Rebuilding your existing website on Jamstack web architecture can be a great way to resolve technical issues on your current site and take advantage of modern web technology without investing in a complete redesign and rethink of your web presence.

Published:
Feb 28, 2024
Written by:
Tim Grubb

Replatform vs redesign

A redesign changes what your website looks like and how it's structured — new branding, new information architecture, new content. It's a large, expensive undertaking that touches every part of the site.

A replatform changes what your website runs on. The design stays the same. The content stays the same. The URLs and search rankings stay the same. What changes is the infrastructure underneath: how content is managed, how the site is hosted, how changes are deployed, and what it costs to keep everything running.

The two aren't mutually exclusive, but treating them as separate decisions means you don't have to wait for (or fund) a full redesign to address platform problems that are costing you money right now.

Key reasons clients are re-platforming their sites

There are a number of reasons that organisations are choosing to re-platform their site into Jamstack.

Your maintenance costs are disproportionate. If a large share of your annual web budget goes to keeping the lights on — security patches, framework updates, server maintenance, database upkeep — rather than making the site better, the platform is working against you. Monthly hosting and maintenance costs are significantly less for Jamstack sites than most common enterprise-grade web platforms.

Changes are slow and expensive. On older platforms, even straightforward changes can require developer involvement, custom code, and careful testing. If adding a new page type, updating a layout, or publishing content takes longer than it should, the platform architecture is the bottleneck.

Your team finds the CMS frustrating. Content management systems have improved dramatically in recent years. If your editors are working around the CMS rather than with it — creating workarounds, maintaining spreadsheets, or avoiding the system altogether — a modern CMS would make a significant difference.

You're facing growing technical debt. Over time some websites become bogged down with technical and performance issues. Aging platforms accumulate outdated dependencies, unsupported frameworks, and known vulnerabilities. The cost of addressing this debt on the existing platform is often comparable to the cost of moving to a new one — except the investment in the old platform doesn't carry forward.

You're about to invest in a major project. If you're planning significant work on your website, it's worth asking whether that investment should go into the current platform or a new one. Building on top of aging infrastructure means the new work inherits all the existing limitations and costs.

Read more about Jamstack web sites

Costs and business case of a re-platform

In addition to the reduction in ongoing costs, the following factors are important for clients considering the cost-benefit of a re-platform.

Dropping design from the web project. In some cases a website's design outlasts the platform that it is built on. By avoiding a rethink and redesign, it is possible to drastically reduce what is often a major part of the overall cost of a website rebuild.

Avoiding double-spending on planned enhancements. Once a site is approaching "end of life", enhancements can become hard to justify because they will be lost when the site is replaced. This adds to the case for a re-platform, especially if you are considering significant enhancements on your existing platform.

We've written a detailed breakdown of where the money goes in a replatform: What does a replatform actually cost? →

What happens during a replatform

The process is more structured and predictable than a redesign, because the scope is narrower. You're not making subjective decisions about branding and design — you're making practical decisions about technology and content structure.

  1. Audit. Review the existing site: what content exists, what templates and page types are in use, what integrations are present, and where the pain points are.
  2. Plan the content model. Design the content structure for the new CMS — reusable building blocks rather than rigid page templates.
  3. Build the front-end. Recreate the site's design using a modern framework. The goal is visual parity: the site looks the same to visitors.
  4. Migrate content. Move content from the old CMS to the new one. Depending on scale, this can be partially or fully automated.
  5. Test and launch. Ensure everything works, redirects are in place, search rankings are preserved, and the editorial team is comfortable with the new system.

What you get at the end

The site your audience sees looks the same on launch day. What changes is everything behind it:

  • Lower ongoing costs. Modern hosting costs a fraction of running a dedicated server. Maintenance overhead drops significantly.
  • Faster changes. Component-driven architecture means new pages and features are assembled from proven building blocks, not built from scratch each time.
  • A better CMS. Modern content management systems are designed for the people who actually use them. If you're on SilverStripe, we've written a detailed guide on what the alternatives look like.
  • Reduced risk. No more patching aging frameworks, managing server infrastructure, or worrying about unsupported dependencies.
  • A foundation for what comes next. Instead of working around platform limitations, your team can focus on making the site genuinely better.

Find out what a move would look like

Submit your URL, answer a few questions, and we'll give you a ballpark cost and payback estimate.

Get a ballpark estimate →

Further reading