A website that worked well three years ago may still open today and look fine. Inside, it is already in a different state. This article explains why a site must be moved to new versions regularly, what happens when it is not, and how we do it for the projects we maintain.
What a "version" is and why it changes
A modern website is built on a framework; Laravel is the most widely used one in PHP. The framework ships a new major version every year, and the old one stops receiving security updates after a while. For Laravel that is about two years. After that, every newly discovered vulnerability stays open on your site.
The same applies to PHP, the database and JavaScript libraries, and for mobile apps to the iOS and Android SDKs, where Apple and Google simply stop accepting apps built with old tools.
What happens to a site that is not upgraded
- Security. Most hacked sites are not the victims of a targeted attack: automated scanners find an old version with a public vulnerability and use it.
- Hosting incompatibility. Servers upgrade PHP. One day the host switches the old version off and the site stops opening.
- No way to add features. New libraries do not work with an old framework. A simple feature that takes a day on a current site takes a week on an old one, or cannot be done at all.
- Expensive "resurrection". Jumping four versions at once costs more than four single steps. At that point it is often cheaper to rebuild the site.
What an upgrade gives you
Beyond security, every new version brings speed and new capabilities. Recent Laravel versions, for example, handle requests faster and need less memory, which directly means faster pages and a cheaper server.
How we do it
At CodeOrigins, version upgrades are part of the maintenance contract, not a separate service. When Laravel 14 ships, every Laravel site we maintain will be moved to it, as we did with previous versions. The same applies to PHP, Vue and Nuxt, Flutter, and the iOS and Android SDKs.
The process is always the same:
- Take a full backup of the site.
- Run the upgrade on a staging copy, never on the live site.
- Pass automated and manual checks: every key page and action.
- Deploy to the live site at the hour with the fewest visitors.
- Watch the error stream for the first days.
Nothing is required from you: the site keeps working, only what it stands on changes.
If another company built your site
That is not a problem. We start with a 3–5 day technical audit, tell you what state the code is in and whether it can be upgraded without repair work, and only then quote a price. Details on the maintenance and support page.