A website can work perfectly well today and still become increasingly difficult to maintain over the next several years. The change is usually gradual. New extensions are installed, settings are adjusted, templates are customized, content structures evolve, hosting environments change, and small workarounds accumulate.
None of those changes automatically makes a website fragile. Most are normal parts of operating and improving a site. The maintenance problem appears when enough decisions and dependencies accumulate that it becomes harder to understand how the website works, predict what a change might affect, or recover when something goes wrong.
This is why older CMS websites often require more maintenance effort even when they are still functioning correctly. They carry more history, more relationships between components, and more decisions that future changes must account for.
NOTE: Complexity is not the same as fragility. A complex website can remain reliable when its structure is understandable, its dependencies are known, and changes can be tested and reversed safely.
Understanding how maintainability changes over time helps explain why routine work that once felt simple can eventually require more planning, testing, documentation, and caution.
Websites Accumulate Decisions as They Grow
Most CMS websites begin with a relatively small number of moving parts. There is the CMS itself, a template, a few extensions or plugins, some configuration, and the site’s content.
Over time, the website changes to meet new needs. A contact form is added. Navigation is reorganized. A template override fixes a layout problem. An extension introduces a new feature. A server setting changes. A publishing workflow is adjusted. Each decision may be reasonable and useful on its own.
The difficulty appears when those decisions begin depending on one another.
| Source of complexity | Why it is added | What must be maintained later |
|---|---|---|
| Extensions or plugins | Add features or integrations | Compatibility, updates, configuration, and vendor support |
| Template customizations | Change presentation or layout | Overrides, custom CSS, modified layouts, and template compatibility |
| Configuration changes | Adapt the CMS to the site’s workflow | Defaults, overrides, inherited settings, and exceptions |
| Content structure | Organize a growing publication or website | Categories, navigation, modules, URLs, and internal relationships |
| Hosting and runtime changes | Keep the site supported and secure | PHP versions, databases, server settings, caching, and other infrastructure |
| Custom code and workarounds | Solve needs not handled cleanly elsewhere | Documentation, compatibility, testing, and future replacement |
This accumulation is normal. A website that has been actively used for several years should not be expected to resemble a fresh CMS installation.
The important question is not whether complexity exists. It is whether the site’s complexity remains manageable.
Complexity Does Not Automatically Mean Fragility
It is easy to describe every additional extension, customization, or configuration choice as a risk. That is too simplistic.
A large publishing website may have many components and still be straightforward to maintain because those components have clear purposes, known dependencies, consistent configuration, and reliable maintenance procedures. A much smaller website can be difficult to maintain if nobody knows why certain settings exist or what will happen when they are changed.
Complexity becomes a maintenance problem when the relationships inside the website become difficult to reason about.
For example, changing a navigation item should normally have a reasonably understandable effect. If the same change unexpectedly alters a module assignment, exposes an old URL, changes a layout, or affects an extension whose relationship was forgotten, the site has become harder to predict.
The problem is not simply the number of components. It is the number of important relationships that are poorly understood, difficult to test, or difficult to reverse.
Dependencies Increase Maintenance Work
CMS websites are built from components that evolve independently. The CMS core changes. Extensions and plugins release new versions. Templates are updated. PHP and database versions move forward. Hosting companies change infrastructure and supported software.
Each component may work correctly by itself while still depending on the behaviour of another component.
- An extension may require a particular CMS or PHP version.
- A template override may depend on markup produced by the CMS core.
- A third-party integration may depend on an external API.
- A caching feature may depend on specific server behaviour.
- A custom script may depend on an extension maintaining the same output or event structure.
These relationships form dependency chains. The more dependencies a website carries, the more compatibility relationships must be considered during maintenance.
This does not mean extensions or integrations should be avoided. They are one of the reasons modern CMS platforms are useful. It means each dependency becomes part of the site’s long-term maintenance responsibility.
An extension that solved a problem five years ago may eventually be discontinued. A template customization may need adjustment after a CMS change. An external service may alter its API. A hosting environment may stop supporting an older PHP version.
Maintenance becomes harder when those dependencies are discovered only after something changes.
Configuration Builds a History of Its Own
Some of the most important maintenance decisions are not visible as installed extensions or custom code. They are configuration choices.
A CMS website can contain hundreds of settings spread across global configuration, components, extensions, templates, modules, menu items, users, content, and server-level tools. Many of those settings inherit from defaults while others override them locally.
Over time, practical adjustments create a configuration history.
- A default is changed to support a common workflow.
- A local override is introduced for one section of the site.
- An extension setting is altered to resolve a compatibility issue.
- A module is assigned differently for a special menu item.
- A template option is changed to accommodate a new design.
None of these decisions is necessarily problematic. The maintenance burden increases when the reason for a decision is forgotten or when exceptions begin multiplying.
A future administrator may see that a setting differs from the default without knowing whether it is intentional. Changing it becomes risky because the effect is uncertain. Leaving it unchanged can be equally problematic if the original reason no longer exists.
This is one way websites become harder to maintain without becoming obviously broken. The site still works, but understanding why it works requires more historical knowledge.
Customizations and Workarounds Can Outlive Their Purpose
Customizations are often introduced because the standard behaviour of the CMS, template, or extension does not quite match what the site needs. Sometimes the right solution is custom code. Sometimes a small workaround is the fastest practical solution.
The difficulty comes later when the workaround remains after the original problem has changed or disappeared.
A CSS rule may compensate for markup produced by an old template version. A template override may duplicate functionality later added to Joomla core. A custom plugin may solve a problem that a maintained extension now handles better. A manual publishing process may continue long after the workflow that required it has changed.
These remnants can become hidden maintenance obligations.
The longer they remain, the easier it is for them to be treated as permanent parts of the website rather than historical solutions that should occasionally be reconsidered.
NOTE: A workaround becomes especially expensive when nobody remembers what problem it originally solved.
Content Structure Also Affects Maintainability
Technical components are only part of a CMS website. Content architecture also becomes more complex as a site grows.
Categories expand. Navigation changes. Articles are renamed. URLs are redirected. Modules are assigned to particular pages. Tags are introduced. Older content remains indexed. New sections are added beside structures created years earlier.
These relationships affect maintenance because structural changes can have consequences beyond the page being edited.
Changing a category may affect URLs or navigation. Retiring an article may require redirects and internal-link updates. Reorganizing menus can change how users and search engines discover content. A module assignment may depend on menu relationships that are not obvious from the article itself.
This is another reason two websites running the same CMS can be very different to maintain. Their content, navigation, URL, and module histories may have evolved in completely different ways.
A maintainable site does not need a perfectly simple content structure. It needs a structure whose important relationships can still be understood.
The Environment Around the Website Keeps Changing
Even if nobody changes the website directly, the environment around it does not remain fixed.
CMS versions advance. Security requirements change. PHP versions reach end of support. Browsers evolve. Hosting platforms update infrastructure. Search engines change how they crawl and interpret websites. Third-party services modify their APIs and authentication requirements.
This continuous movement means a working website cannot simply be frozen indefinitely.
Updates are therefore a normal part of maintaining the site, but they can also expose old assumptions and dependencies. A component that worked reliably for years may encounter a compatibility problem when another layer of the system changes.
The update itself may appear to be the cause, even when the underlying issue is that two components no longer agree about how the system should behave.
This relationship between updates and compatibility is important enough to treat separately in the article Why CMS Updates Sometimes Break Websites. The broader point here is that maintainability depends partly on how well a website can absorb necessary change.
People and Documentation Matter Too
Website complexity is not only technical. Knowledge can also disappear.
A developer who built a custom integration may no longer be available. A site owner may forget why a particular extension was installed. Staff members may change. Documentation may never have been written. An old support conversation may contain the only explanation for an unusual configuration choice.
When knowledge leaves the project, maintenance becomes harder even if the website itself has not changed.
This is especially noticeable when a new developer or administrator takes responsibility for an established site. Before making changes, they first have to reconstruct how the website is put together and which parts may depend on one another.
Good documentation cannot record every detail, and it does not need to. The most valuable documentation explains unusual decisions, important dependencies, customizations, recovery procedures, and anything that would otherwise be difficult to rediscover.
Obsolete Functionality Adds Hidden Weight
Websites also accumulate features that no longer provide enough value to justify their maintenance cost.
An extension may still be installed even though the feature is rarely used. An integration may remain active for a service the organization has largely abandoned. Old template overrides may survive several redesigns. Legacy content structures may continue simply because changing them seems inconvenient.
Every obsolete feature increases the amount of website that must still be understood, updated, tested, backed up, and considered during troubleshooting.
This does not mean older functionality should be removed aggressively. Removing something without understanding its relationships can create a different problem.
Instead, mature websites benefit from occasional review of what is still necessary. Simplification is most useful when it removes dependencies that no longer provide meaningful value.
Three Questions Help Describe Maintainability
There is no single measurement that tells you whether a website is maintainable. A practical way to think about it is to ask three related questions.
Can the website be understood?
Can someone responsible for the site identify the important components, configuration choices, customizations, content structures, and dependencies?
Perfect documentation is not required. What matters is whether the structure can be understood well enough to make informed decisions.
Can changes be predicted?
When an update, configuration change, or new feature is introduced, can you make a reasonable assessment of what it might affect?
No website is completely predictable, but routine changes should not feel like experiments conducted without any idea of the consequences.
Can the site be recovered?
If a change causes a problem, can the previous working state be restored?
Recoverability includes usable backups, known restoration procedures, access to required accounts and services, and enough knowledge to identify what changed.
These three ideas, understandability, predictability, and recoverability, are not a formal industry standard. They are simply useful ways to think about why one website can remain manageable despite considerable complexity while another becomes increasingly difficult to change safely.
Warning Signs Usually Appear Before Maintenance Becomes Difficult
Maintainability rarely disappears all at once. The change is usually gradual.
You may notice that routine updates require more testing. A simple layout change produces unexpected side effects. Nobody is certain why an extension is still installed. Developers avoid touching a particular configuration because its consequences are unclear. Small changes increasingly require workarounds.
These are not proof that a website is failing. They are signals that the cost of understanding and changing the site may be increasing.
The supporting article Early Warning Signs a Website Is Becoming Fragile looks more closely at these observable symptoms. The distinction is important: this article explains why maintainability deteriorates, while the warning-sign article focuses on how that deterioration begins to show itself in day-to-day work.
Routine Maintenance Helps Keep Complexity Manageable
A website cannot be kept maintainable by avoiding change. CMS platforms, extensions, hosting environments, and business requirements will continue evolving.
The better objective is to manage change deliberately.
Regular maintenance helps because it prevents too many unknown changes from accumulating at once. Extensions that are no longer needed can be reviewed. Updates can be applied while their context is still understood. Backups and recovery procedures can be verified. Configuration decisions can be reconsidered before they disappear into the site’s history.
This does not eliminate complexity, and it does not guarantee that updates will never cause problems. It reduces the amount of uncertainty surrounding the website.
The article Why Website Maintenance Should Be Routine develops that operational side in more detail.
A Maintainable Website Is One You Can Continue Changing
The long-term goal of website maintenance is not to preserve a site in the same state forever. A useful website needs to change.
New content will be published. Features will be added or retired. CMS versions will advance. Templates will evolve. Hosting environments will change. Business needs will shift.
A maintainable website can absorb those changes without every adjustment becoming a high-risk project.
That usually means keeping dependencies purposeful, reviewing obsolete functionality, understanding important configuration choices, documenting unusual decisions, maintaining reliable recovery options, and avoiding unnecessary layers when a simpler solution can meet the same need.
Complexity will still accumulate. The objective is to keep that complexity understandable enough that the website remains predictable to work on and recoverable when something goes wrong.
When those qualities begin declining, the answer is not necessarily a rebuild or a new CMS. Often the first step is simply to identify which parts of the website have become difficult to understand, which dependencies are creating uncertainty, and which historical decisions no longer provide enough value to justify their maintenance cost.
Article Comments
Comments are for discussion and clarification, not support requests.
Terms & Conditions
Subscribe