Our system is too risky to change

The last change broke something that had nothing to do with it. There's no test system, so every change is tried on live, usually on a Friday evening with everyone watching. One person is able to change it, and they'd rather not. The business has stopped asking for improvements because it knows the answer. And at least one supplier has said the only safe option is to rewrite the lot.

If two of those are true, the system isn't the problem. The lack of a safety net is.

Not because the system is old. Because nobody can see what depends on what.

A report reads a column that a screen repurposed in 2016. A scheduled job assumes a file will be in a folder that a change moved. Two processes share a table and only one of them was mentioned when the change was specified. None of that is unusual, and none of it is visible without a map. Add no tests and no staging environment, and every change is a guess tested on the business.

The fix is not a rewrite. A rewrite has all the same hidden dependencies, plus new ones. The fix is to make the dependencies visible and to give changes somewhere safe to fail.

1. Map it. The assessment writes down what the system does, what depends on it and what it depends on. That map is what makes the next steps safe.
2. Put a safety net under it. Source code into version control. A backup that has been restored and proven to work, rather than one that was only ever taken. A test environment that's a copy of live. Tests around the processes that matter most.
3. Change one process at a time. The new or repaired piece runs in staging alongside the live system, sharing the same data, until the tests and the people who use it say it's right. Then it goes live, and the old route stays open as a fallback.
4. Repeat, or stop. Each stage is priced before you commit to it. Each ends with working software you've already paid for. Stop after any stage and keep everything.

No big bang. No Friday-night switchover. No leap of faith.

Usually not. A system that's too risky to change is often sound underneath and simply unmapped. Once it's mapped and under test, most of what people wanted for years turns out to be a series of small, safe changes. If your system is fundamentally sound, we'll take it over, stabilise it and build what's missing. If it isn't, the assessment says so and prices a staged replacement instead.

It never meets a change until the change has proven itself somewhere else. We build and test against a copy in a test environment, then run the new piece in staging alongside the live system, migrating, checking and reconciling the data there first. Only when the tests have shown it's safe does anything connect to live, and the old system stays available as a fallback until you're confident.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. Each stage after that has its own fixed price, so an overrun is our risk rather than yours. Payment terms are on the pricing page: 40% on signature, 40% at the first working version, 20% on handover, per stage.

Each stage takes one process and gets it live. Something working within six weeks is the usual first milestone, and it's soon enough to find out whether we've understood how you work before you commit to anything bigger.

A system that can't be changed can't be patched either. Windows Server 2016 support ends in January 2027. SQL Server 2016 security updates ended in July 2026 for most licence holders. The analogue phone lines some systems still dial or alert over go in January 2027. "Too risky to change" holds right up until a date in the calendar makes not changing the riskier option.

One accountable lead, a safety net before any change, and open technology afterwards. The person you speak to on the consultation leads every stage. Anything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment.