Inherited a business-critical system? We can help.
Understand it. Stabilise it. Document it. Support it. Improve it.
The original developer has gone. The system still runs the business.
Plenty of organisations depend on software written years ago by an employee, a contractor or a software company that’s no longer around.
It still does its job. But nobody fully understands how. Documentation is missing, changes take longer than they should, problems are getting harder to fix, and every update feels like a risk somebody’s taking personally.
If that sounds familiar, you’re not unusual — it’s one of the most common situations we’re called into.
We work with existing applications, databases and business processes to take control of a system nobody owns any more. ☎
Don’t replace it until you understand it
When an inherited system starts causing trouble, the instinct is to replace it.
But most of these systems contain years of accumulated business knowledge, proven processes and irreplaceable data. Quite a lot of that knowledge exists only in the system — it was never written down anywhere else, and a replacement project discovers it the hard way, usually in month five.
Before anyone talks about replacing it, there are questions worth answering:
- How does the system actually work?
- Which parts are genuinely business-critical, and which does nobody use?
- What risks are you carrying right now?
- What documentation is missing?
- What could be improved without rebuilding?
- Is replacement really necessary?
In most cases a structured rescue delivers results faster, at lower cost, and with far less risk than a rewrite.
Does any of this sound familiar?
- The original developer has left
- The supplier no longer exists, or no longer answers
- Nobody understands how it works
- Changes are getting harder and more expensive
- Documentation is incomplete or missing entirely
- It’s become business-critical almost by accident
- Performance is deteriorating
- Support requests take too long to resolve
- The business depends on something that feels fragile
The earlier you act, the more options you have. The worst time to start understanding a system is the week it stops working.
How we rescue a legacy system
1. Understand what you’ve got
We analyse the application architecture, databases and data structures, business processes, reports and integrations, user workflows, and the code and customisations that have built up over the years.
That gives you a clear picture of the system — and removes the dependency on knowledge that currently exists in one person’s head, or in nobody’s.
2. Stabilise the platform
Most inherited systems carry problems that have never properly been resolved, just worked around. We identify and address performance problems, database issues, application errors, security weaknesses and reliability problems.
The goal is a platform the business can depend on while you decide what happens next.
3. Document it properly
Missing documentation is usually the biggest single risk.
We document system functionality, technical architecture, database structures, business rules, processes and workflows, and support procedures — so the knowledge belongs to your organisation rather than to whoever happens to be looking after it.
4. Support it
Once a system is understood, it still needs looking after. Telephone and remote support, issue resolution, bug fixing, enhancements, database support and long-term maintenance.
When something goes wrong you speak to someone who understands both the technology and why the business does it that way.
5. Improve and extend it
Rescue is the beginning, not the end. Once it’s stable we can add functionality, improve reporting, build web interfaces and mobile apps, integrate it with your other systems, upgrade the database underneath it, and bring modern technology to a system that already works.
web applications – mobile apps – reporting and business intelligence
What we take on
- Microsoft Access databases → Access support
- SQL Server applications → SQL Server support
- Bespoke business software, whoever wrote it
- Departmental systems that grew beyond their department
- Legacy desktop applications — VB6, VBA, Delphi, WinForms, classic ASP and older .NET
- Web applications on frameworks nobody supports any more
- Reporting solutions and operational workflow systems
- MySQL and other databases behind inherited applications
Whether it’s five years old or twenty-five, the approach is the same: understand what exists before recommending change.
One awkward question, early
Do you have the source code?
It’s worth finding out now rather than three months into a support relationship. Plenty of businesses discover that what they actually own is an installed application and a database — the source went with the developer who left, or sits with a company that’s been dissolved.
That’s not the end of the road. There’s usually a great deal we can do with the database, the interfaces and the data even where the application itself can’t be changed, and there are routes to rebuilding the parts that matter most. But it changes what’s possible and what it costs, so we’d rather establish it in the first conversation than the fifth.
Same for licences, server access, domain ownership and who holds the backups. Inherited systems tend to come with inherited paperwork gaps.
Where to start
You don’t need to commit to a programme of work to get somewhere useful.
Start by understanding it. We’ll go through the system and produce a written account of what’s there: how it’s built, where the data lives, what the business rules actually are, what’s at risk, and what your realistic options are.
That document is yours. It’s useful whether you carry on with us, take it in-house, or hand it to somebody else — and it’s what makes everything after it quotable instead of guesswork.
Most rescue work starts there, and for a lot of clients it’s the only thing they needed.
When replacement genuinely is the answer
Sometimes it is, and we’ll tell you.
If the platform is out of support and can’t be secured, if the data model can’t carry what the business now does, or if the cost of keeping it running honestly exceeds the cost of replacing it, then the right advice is to replace it — carefully, in stages, with the old system running until the new one has earned its place.
We’d rather say that at the start than take money to prop something up for another two years.
bespoke database and business software
Why CDE Systems
We specialise in supporting and improving software that already exists.
Rather than encouraging organisations to start from scratch, we protect the investment already made in systems, data and processes. Since 1999, across business, local government, central government and the NHS.
In practice that means reduced risk, control regained, better reliability, users properly supported, and a basis for planning improvements with some confidence.
Mostly it means removing the fear that surrounds a system nobody understands.
Database / Inherited System Support
Ongoing support for a system somebody else built.
Find out more...
Database / Inherited System Support
Ongoing support for a system somebody else built.
Find out more...Case studies
Aire Valley Catering: four mobile apps, an Access business system, and engineers with no signal
Engineers working on customer sites across the UK can't count on having a signal, and the job still has to be recorded. Four production apps across both app stores, an Access and SQL Server business system behind them, and a roadmap that keeps offline working rather than trading it away.
View case study →Recovering audit and customer data across multiple corrupt SQL databases
Several customer databases became damaged and wouldn't open, putting audit records, operational data and customer information at risk of permanent loss. A structured recovery programme rebuilt usable datasets from the corrupt files and returned multiple customer systems to service.
View case study →ACC Worldwide: a faster SQL Server platform, noticed on day one
A business-critical system was working but slow, and staff felt it every day. Work on the SQL Server environment behind it delivered an immediate speed increase, and left ACC's own IT team with the logging and monitoring tools to keep developing it.
View case study →Take control of your legacy system
If your business depends on software nobody fully understands, the first step is understanding it. Tell us what you've got and we'll tell you what's involved — including whether you need us at all.
Send us the details → How we work →