Last autumn a company from Riga came to us with a site built on CodeIgniter 2, running since 2013, with a 1C integration, order processing and a customer portal. The developer who built it had moved abroad and stopped answering e-mail. The server ran PHP 5.6, and the hosting company planned to switch it off by the end of the year.
This is not rare. It is a familiar pattern in 20 years of web development.
What to do on day one
If the developer has just vanished and the site still runs, the first priority is to avoid becoming dependent on the hosting as well. Check these yourself or ask a technical colleague:
- Do you have access to the hosting control panel, and to SSH or FTP, not only to the site?
- Do you have a database backup, and what is the date of the last one?
- Is the domain registered in your company’s name or in the developer’s?
- Which PHP version is in use? The hosting panel shows it.
The domain is critical. Sometimes the developer registered it in their own name and you cannot manage it. In that case contact the registrar with proof that you own the company.
Why it still works, and why you are exposed
CodeIgniter is not dead; version 4 is actively maintained. The problem is that most abandoned projects were built on 2.x or 3.x, often with PHP 5.6 or 7.0, and nobody maintains them.
Hosting providers gradually drop old PHP versions. PHP 5.6 lost support in 2018 and PHP 7.4 in 2022. When your host stops supporting your version, the site can fail without warning, or run with security holes nobody patches. The second risk is integrations: if the site exchanges data with 1C, Jumis or Moneo, those links can break at any moment if nobody maintains them.
How to assess what matters
Before thinking about migration, find out what the system actually does:
- How actively is it used? A mostly informational site with 20 visitors a day is a different case from one with a steady order flow.
- What are the functional parts? Separate static content, dynamic logic and connections to external systems. That shows how hard the move will be.
- What is the code quality? Sometimes a CodeIgniter project is clean and commented, and you can work with it. Sometimes it is eight years of accumulated chaos that is better rebuilt.
Three options
Keep it stable. If the site works and nothing is urgent, maintain it as is: raise the PHP version as far as the CodeIgniter version allows, set up regular backups, monitor the server. Cheapest in the short term, not a long-term answer.
Gradual migration. For larger projects with complex integrations we sometimes build a new system next to the old one and move functionality over step by step. The business keeps running, and each month another part moves. This usually takes six to twelve months.
Full rebuild. If the code is very old, or the logic is complex and undocumented, building from scratch on a modern architecture can be faster and cheaper. For new projects we use Laravel as the main framework.
The choice depends on the project. There is no universal answer.
Why a team beats one freelancer
A common reason companies end up here is that the site was entrusted to a single freelancer. When he disappeared, so did all the knowledge about the system. We work as a team (FSM Studio, since 2006): the code lives in version control with documentation, it belongs to you, and if someone in our team moves on, the project does not go with them.
Practical steps today
- Download all site files and a database export now. Backups come first.
- Find out who controls the domain and the hosting, and make sure you can manage both yourself.
- Check the PHP version in the hosting panel and how long the host will still support it.
- If you need help assessing the situation, talk to a team with web development experience in legacy systems.
Most companies that contact us in this situation have waited too long. The sooner you start, the more options you keep. For the budget side, see what a website costs and which mistakes to avoid when choosing a developer.
