Explain it to me like I’m 5 (ELI5) is an article series where I apply the Feynman Technique to explain technical topics in web and web application development from first principles: clear, simple, and hype-free.

Today there’s a lot of talk about modern ways to build websites and apps, in contrast to legacy ways to build websites. What do we mean when we say a legacy website or legacy CMS?

Back up: what is a CMS?

A web content management system (CMS) is software that helps non-technical editors create, publish, and manage content for websites. This includes text and images, as well as the layouts and designs that present that content — from blog posts to home pages. It may also include media or music, or embedded pieces of content from other services, like YouTube or social media.

Classic examples of legacy CMSes are WordPress, Drupal, and Joomla, but there are literally thousands more. They are very popular. By some estimates, WordPress runs 40% or more of all websites on the internet.


All Legacy CMSes have a similar software architecture: the different systems that make it work. There is a database server, to store content; an application server, to run an operating system and a language; the CMS itself, which editors use to save content to the database; templates, created by web designers to make web pages, and a web server, which takes page requests from web browsers, sends them to the CMS, which makes the pages from data and templates, and hands back completed web pages to the web browser.


Legacy usually means “bad” in software circles. Why is this approach considered outdated today?

  • Expensive to maintain: each layer — the database, application server, CMS, and web server — has to be kept up to date. Ideally, this can be done by the web hosting provider, but it still takes work.
  • Hard to secure: each of these layers presents an opportunity for bad actors to attack: a “surface area” in security-speak. This is a real problem if they are allowed to get out of date, and keeping on top of updates takes work. This is made worse by…
  • Out of date plugins and templates: legacy CMSes extend their functionality through plugins and templates, often developed by third-party developers or “the community.” These bits of software, though, are often unsupported, conflict with each other, and go out of date. This is a primary source of security problems.
  • Slow performance: every web browser request goes through the same layers: the web server to the app server to the CMS to the database, through templates, and back to the web server to deliver the page browser. There are other technologies that can cache — store in fast-reacting memory — the generated web pages, but the basic architecture is slow and gets slower the more people visit the site.
  • Difficult to scale: everyone wants to have that “viral hit” until their site goes down because of a wave of traffic. It’s hard to scale legacy sites because it is expensive — bigger, faster databases cost more — and typically we don’t know ahead of time how much to scale.
  • All knotted up: This architecture is sometimes called “monolithic” or “tightly coupled,” because the same system that runs the CMS also makes the website. So if the database isn’t working, then there’s no data for templates or the CMS, and then the site goes down.
  • Hard to make changes quickly: because developers have to think about the entire architecture, from database through application to web pages, it’s difficult to make changes quickly, or to make changes safely so they don’t break something else.