The AI Agent That Assumes: Why Automation Needs to Ask, Not Guess
AI agents are good at filling in gaps quietly, which is exactly the problem. Here's why business automation needs to be built to ask rather than assume, with real examples.
Legacy software modernisation
Modernise ageing software without the risk of a rebuild
Your system still works, but it's becoming slow, fragile or risky to run, and only one person really understands it. I help you work out the safest way forward, and then take you there in stages, without betting the business on a big rewrite.
01Overview
Plenty of businesses run on software that's a decade or more old. It does the job, but it's getting harder and more expensive to keep running, and the people who understood it have often moved on. Modernisation isn't about replacing everything for the sake of it. It's about reducing the risk and the friction, in the way that makes the most sense for you.
02When to look
Signs it's worth a look
If a couple of these sound familiar, it's usually cheaper to act before something forces your hand.
Only one person understands it
The system works because someone keeps it working. If they leave or are off, you're exposed.
Spreadsheets fill the gaps
The software does part of the job and your team props up the rest with spreadsheets and manual workarounds.
It's unsupported or ageing
Old bespoke apps, an Access database or a platform that's no longer maintained, quietly becoming a risk.
It's hard to change
Every small change is slow, expensive or nerve-wracking, so the system stops keeping up with the business.
03The honest answer
You don't always need a rebuild
There are five ways forward, and a rewrite is only one of them. The first job is working out which one you actually need.
- 01KeepIf it does the job and the risk is low, the right move might be to leave it alone. I won't tell you to rebuild something that's working fine.
- 02ImproveTargeted fixes to the specific weak points: performance, a fragile process, a security gap, without touching what already works.
- 03IntegrateOften the real problem isn't the system, it's that it's an island. Connecting it to your other tools solves the pain without replacing anything.
- 04ModerniseBring the system forward in stages: a modern interface, better reporting, updated foundations, module by module rather than all at once.
- 05ReplaceWhen a system genuinely can't be carried forward, replace it carefully, keeping the old one running until the new one has fully taken over.
04How it runs
How I approach it
- 01
Understand what you have
Before recommending anything, I learn what the system does, what depends on it and where the real risks and costs are. Old systems usually do more than anyone remembers.
- 02
Decide the right approach
We decide honestly between keeping, improving, integrating, modernising or replacing, based on what's best for the business, not on what's most work for me.
- 03
Move in safe stages
Where change is needed, I do it step by step, replacing or improving one part at a time so the business keeps running throughout. No risky big-bang switch-over.
- 04
Migrate and hand over
Data moves across in full, your team gets comfortable with the changes, and it's documented so it isn't a mystery again. I stay available afterwards.
05What it covers
What modernisation can involve
Depending on the path we choose, some or all of these come into play.
Data migration
Moving your data across safely and in full, so nothing is lost and history is preserved.
Modern interfaces
A clearer, faster interface your team will actually enjoy using, on top of the data you already have.
Integrations
Connecting the old system to the tools around it so it stops being an island.
Security & access
Bringing authentication, permissions and data handling up to a sensible modern standard.
Reporting
Turning locked-away data into reports and dashboards you can actually rely on.
Documentation & support
Writing down how it works so it no longer lives in one person's head, and being there to support it.
06FAQs
Modernisation questions
Do we have to replace everything?
No, and I'll usually advise against it. Replacing a whole system is expensive and risky, and it's often unnecessary. The right answer is frequently to improve or connect what you have. I only recommend replacement when a system genuinely can't be carried forward.
Our system still works. Why modernise it?
Working isn't the same as safe. If only one person understands it, if it's unsupported, if every change is painful or if your team fills the gaps with manual work, the cost and risk build up quietly. Modernising is about reducing that risk before it becomes a problem, not fixing something that's visibly broken.
What's a staged migration?
Instead of switching everything over in one high-risk go, we replace or improve the system one part at a time, keeping the existing one running until each new piece has fully taken over. It's slower on paper but far safer, and the business keeps operating throughout.
Can you work with an old Access database or spreadsheet system?
Yes. Access databases, spreadsheet-heavy processes and old bespoke applications are common starting points. I can connect them to modern tools, put a better interface on top, or migrate the data into something more robust, depending on what makes sense.
What if the original developer is long gone?
That's a very common situation and not a problem. Part of the job is understanding an unfamiliar system from the outside, working out what it really does, and documenting it so it's no longer a black box.
Will the business keep running during the work?
Yes. Maintaining business continuity is the whole point of working in stages. The existing system stays in place and in use until each replacement is proven, so there's no period where you're stuck.
Insights
Related reading
You Inherited a System Nobody Can Explain. Now What?
When you inherit software with no documentation and no developer to ask, the temptation is to rewrite it fast. Here's a safer way to work out what it actually does first.
Your AI Coding Assistant Doesn't Remember Last Week's Decisions
AI coding agents don't carry memory of past decisions between sessions the way a human developer does. That gap shows up as inconsistency in your codebase, and it matters more than most people realise.
Tell me about your current system
Describe what you're running and what's starting to hurt. I'll give you an honest view on whether to keep, improve, connect or replace it, and what that would take.
Or email me at josh@thackr.co.uk