Key takeaways
- Do not start with a fix. Write down what is happening and what it costs.
- In the first week, secure access, check the backups and name who understands the system.
- Symptoms point to likely causes but do not prove them. An independent review turns guesses into evidence.
- Decide between fixing, modernising and replacing only after you know the cause.
- Someone must own the system afterwards, or it will struggle again.
What does a struggling system look like?
Most owners do not describe it as a technical problem. They describe what they see:
- Pages are slow at busy times.
- The same bug comes back after every fix.
- A small change takes weeks.
- One person is the only one who knows how it works.
- Costs rise but nothing seems to improve.
- Staff keep spreadsheets on the side because they do not trust the system.
Any one of these is common. Several together usually mean the system is costing the business more than it appears to.
Why should you not start with a fix?
A fix made without a cause often moves the problem rather than removing it. A slow page can be sped up by paying for a bigger server. If the real cause is how the database is queried, the slowness returns as soon as traffic grows, and you have paid twice.
It also matters who you ask. A developer who builds new systems may suggest a rebuild. A developer who maintains the old one may suggest a patch. Both answers can be honest, and both can be wrong if nobody has looked at the evidence first.
What should you do in the first week?
You do not need technical skills for most of this.
- Write down what is actually happening. Note dates, times, screenshots, who is affected and what it costs in hours or lost orders. Facts are easier to act on than frustration.
- Check that you hold the keys. You should have the logins for hosting, the domain name, the code repository, the backups and any third-party services. If a former developer or agency holds them, getting them back comes first.
- Check the backups. Ask when the last one ran, where it is stored and whether anyone has ever restored from it. A backup nobody has tested is a hope, not a plan.
- Find out who understands the system. Name the people. If the answer is one person, write that down as a risk.
- Pause large changes. Keep urgent security fixes. Hold new features until you know what you are building on.
What usually causes the symptoms?
Symptoms point to likely areas. They are not proof, which is why someone needs to look.
- Slow at busy times. Often database queries, hosting that is too small, no caching, or one slow call to a third-party service.
- The same bugs return. Often no automated tests, fixes applied to the symptom rather than the cause, or changes released without a test environment.
- Small changes take weeks. Often tangled code that nobody dares touch, and little written down.
- Outages nobody notices until a customer calls. Often no monitoring or alerts.
- Rising costs. Often an old hosting plan, services nobody uses any more, or staff time lost to workarounds.
- Security worries. Often out-of-date software and libraries, or passwords shared between people.
When is an audit the right next step?
If the cause is still unclear after the first week, or if a large decision is coming, an independent review is worth considering. A technical audit is a written report on the state of the system, the risks and what to do first. It does not change the system.
A narrow audit of one worry, such as hosting cost or reliability, is often more useful than a broad one. Our guide to what a technical audit is and when you need one explains what to ask for and what a good report contains.
How do you decide between fixing, modernising and replacing?
Decide this after you know the cause, not before. There are usually more than two options: leave it alone, maintain it, modernise it in place, or rebuild. Rebuilding is rarely the right first answer, because it is the slowest and most expensive way to find out you misunderstood the problem. Our guide to legacy system modernisation sets out the four options and the questions to answer before committing.
If a project to fix the system is already under way and going badly, see software project risks and early warning signs.
What should you ask whoever looks at it?
Whether it is an in-house developer, a supplier or an outside reviewer, a few questions show how careful they are:
- What evidence did you use, and how can I check it?
- What could you not look at, and why?
- What would you do first, and what would you leave alone for now?
- What happens if we change nothing for the next three months?
A clear, honest answer to these is worth more than a confident plan with no evidence behind it.
Who should look after it afterwards?
A system that nobody is responsible for becomes a struggling system again. Decide who owns it, who fixes problems and how quickly. Maintenance and support are two different things, and a clear contract helps both sides. If you are choosing one, read what a fair maintenance contract includes.
When is it urgent?
Some problems should not wait a week. Act at once if:
- customers cannot pay or place orders,
- the system is down,
- you suspect someone has gained access who should not have it, or
- personal data may have been exposed.
In the last case, UK law can require you to report certain breaches to the Information Commissioner's Office within 72 hours of becoming aware of them. Get advice quickly rather than waiting for the full picture.
If you are not sure where to start, tell us what is happening and what it is costing you. We will tell you what we would check first.