Modernising the System Your Business Has Outgrown
The database was designed years ago, for a smaller version of this company. It still holds everything — it just takes longer to answer, is harder to change, and cannot talk to anything newer. That is a different problem from needing to be replaced.
Does this sound familiar?
A report that used to take seconds now takes minutes, or is run overnight.
The same customer exists three times, slightly differently.
The application only runs on one server, and nobody wants to reboot it.
Deployment is a manual process somebody does carefully on a Friday.
Newer systems cannot get at the data without somebody exporting it.
The operating system underneath stopped receiving updates some time ago.
Old does not mean obsolete
A mature database is often the most valuable thing a company owns. It holds years of history, and a structure that has survived contact with reality — which is more than can be said for most new schemas.
What ages is rarely the design. It is the volume it now holds, the indexes that were right for a tenth of the data, the queries written before anyone knew which ones would matter, and the platform underneath reaching end of support. The business outgrew the assumptions, not the model.
So modernisation here is not modernisation for fashion. The goal is a system that can be changed safely, answered quickly, and reached by other software.
Sometimes the database is fine
Frequently the database stays exactly where it is and the work happens around it. A new web interface, an API so other systems can reach the data properly, a reporting layer, a customer portal, a mobile app, or scheduled processes replacing manual ones — all built against a core that has already proved it works.
That is usually the cheapest useful outcome, and it is reversible in a way a migration is not. We will recommend it where the underlying structure is sound, even though it is the smaller piece of work.
Sometimes the honest answer is smaller still: the database does not need modernising, it needs three indexes and a query rewritten.
Understand it before changing it
Nothing gets altered before we know what depends on it. That means the schema, the stored procedures, every application connecting to it, the scheduled jobs, the imports and exports that run at odd hours, the reporting, the security model, and whether the backups have ever actually been restored.
That last one matters more than it sounds. A surprising number of systems have backups nobody has tested, and finding that out during a migration is the wrong time.
Improving the database, and moving it safely
Where the database itself needs attention, the work is usually indexing, query optimisation, schema improvement, archiving data that no longer needs to be live, version upgrades and putting monitoring in place so the next slowdown is noticed before a user reports it.
Where it needs to move — to managed hosting, or to AWS or Azure — it moves with a test migration, verified backups and a rollback plan, and usually in parallel with the existing system until the two agree.
How we approach it
Understand
Survey the schema, the dependencies, the jobs, the reporting and the recovery position.
Decide
Separate what needs fixing from what merely looks old. Often that shortens the job considerably.
Build
Index, optimise, restructure where needed, and put a modern interface or API around the core.
Move
Migrate with a tested restore and a rollback plan, in parallel wherever it is possible.
Stay
Monitor it, so performance is a trend you watch rather than an incident you discover.
We’ve solved this before
NET Services — electrotechnical assessment
NET manage electrotechnical assessments across England, Wales and Northern Ireland, including a live internal appeals management system that the organisation runs on. The requirement was not to replace it — it was to let candidates, training providers and employers reach what it holds.
We built the public platform around that core: a centre locator searchable by location, postcode, region or assessment type, real-time centre availability, and an appeals process that integrates directly with the live internal system so a candidate’s submission lands where the staff already work. The system underneath kept running throughout.
What this usually involves
Questions we get asked
Do we have to move off SQL Server?
Not usually. Version upgrades, indexing and schema work often solve the actual complaint. Changing database engine is a large piece of work and should have a reason beyond age.
Can the database stay where it is?
Frequently the best outcome is exactly that — the core stays and the application, reporting or API around it changes. It is cheaper and far easier to reverse.
Our reports are slow. Is that a modernisation project?
Often not. Slow reporting is commonly indexing, query design or reporting against a live transactional database. Those are days of work, not months, and we would rather establish that first.
Can you move it to the cloud?
Yes, to AWS or Azure and to managed database services where they suit. The migration matters more than the destination: test restore, rollback plan, parallel running.
Nobody here knows how it was built. Is that a problem?
It is normal, and it is the first thing we address. The survey produces documentation you keep, whichever direction you then go.
Before replacing it, find out what is worth keeping.
You don’t need to know the technical answer yet. Tell us what is causing the problem. We’ll start there.
Building and running business systems since 2000. The same team that builds it stays to run it.
Start a Conversation