Replace Your Legacy System? Maybe Not.

A manufacturing director rang me last month, absolutely convinced they needed to bin their entire ERP system. "It's ancient," he said. "Can't talk to anything. The vendor wants a fortune to upgrade it. We need something modern."

I asked what was actually broken.

Long pause.

"Well... it works fine for what it does. But we can't get data into our new CRM without someone manually copying it over. Takes hours every week."

Right. So the system wasn't broken. The connection was broken.

We built a simple integration that synced the data automatically. Took three weeks. Cost about 5% of what replacement would've run them. They're still using that "ancient" system two years later, and it's humming along just fine.

The Expensive Mistake I Keep Seeing

Here's what happens: Your business grows. You add new tools—maybe a modern CRM, an e-commerce platform, some inventory management software. Suddenly your old system that's been reliably doing its job for years looks like the problem.

Vendors smell blood in the water. They'll tell you that legacy system is holding you back. That you need a complete digital transformation. That modern businesses need modern systems.

And sometimes? They're right.

But I've watched too many small to mid-sized UK businesses spend 18 months and eye-watering amounts replacing systems that didn't actually need replacing. I've seen projects that promised to solve everything create more problems than they fixed. I've picked up the pieces when "enterprise-grade" solutions turned out to be enterprise-grade headaches.

The question isn't whether your system is old. It's whether it's actually the problem.

When Your Legacy System Is Actually Fine

I'll be blunt: if your system does its core job well, it's probably not your enemy.

I recently worked with a distribution company running a 15-year-old system built on an Access database. I know what you're thinking. Access databases are the punchline of IT jokes. But this one handled their entire order processing, knew their inventory inside out, and had business logic refined over a decade and a half.

The problem? They'd added WooCommerce for online orders, Xero for accounting, and a third-party logistics system. None of them talked to each other. Staff were manually re-keying orders. Inventory counts were always wrong. The finance team spent two days at month-end reconciling everything.

The CEO had quotes for replacing the whole lot. Big numbers. Long timelines. Massive disruption.

But that Access database wasn't the problem. It was the hub that everything else needed to connect to.

We built integrations using Python scripts and some middleware. Orders from WooCommerce flowed into the Access system automatically. Inventory updates pushed back out. Financial data synced to Xero nightly. The logistics system got real-time stock levels.

Delivered in six weeks. Cut manual data entry by 85%. Eliminated the month-end reconciliation nightmare entirely. That Access database? Still there, still working, still at the centre of everything.

They saved roughly 90% compared to full replacement and avoided 12-18 months of disruption.

When You Actually Do Need to Replace It

I'm not saying never replace legacy systems. I'm saying be honest about why.

You probably need replacement when:

The vendor's gone or abandoned it. If you can't get support and something breaks, you're stuffed. I've seen businesses running systems where the original developer retired in 2008 and nobody else understands the code. That's a ticking time bomb.

It genuinely can't scale. Not "the vendor says it won't scale"—actually can't. I mean it falls over when you add more users or data. Performance degrades to unusable. That's real.

The core functionality is wrong. Your business has fundamentally changed and the system can't do what you need it to do. Not "it's a bit clunky"—actually can't handle your business model anymore.

Security is a disaster. If it can't be secured properly and you're handling sensitive data, that's not negotiable. Though I'd argue you should try patching or isolating it first.

Compliance requires it. Sometimes regulations change and your system genuinely can't meet new requirements. That's legitimate.

But "it's old" isn't a reason. "It doesn't talk to our new systems" isn't a reason—that's an integration problem. "The interface is ugly" definitely isn't a reason, though I understand the frustration.

The Integration-First Approach

Here's what I've learned works for practical businesses:

Start by mapping what your legacy system actually does well. Not what you wish it did—what it genuinely handles better than anything else would.

For most small to mid-sized businesses, that's usually the core business logic. The rules about how your specific business operates. The quirks and exceptions that make your company different.

That stuff is valuable. It's been refined over years. It's in the system because someone learned a hard lesson and encoded it. Throwing it away means relearning those lessons or spending months specifying requirements that are already working.

Then identify the gaps. What does it not do? What connections are missing? Where are people doing manual work?

Nine times out of ten, you can bridge those gaps without replacing the core system.

How This Actually Works (Technical Bit)

Let me walk through a real example. A client was running Sage 50 for accounting and inventory. Solid system, does what it says on the tin. But they'd added an online booking system for their service business that lived in a completely separate world.

Every booking meant someone had to:

1. Check Sage for stock availability
2. Manually create an invoice in Sage
3. Update inventory in Sage after the job
4. Copy customer details between systems

Twenty bookings a day. Forty minutes of manual work. Errors everywhere.

We built a middleware layer using Python and the Sage 50 API:

# Simplified example - real code has error handling, logging, etc.
import requests
from sage50_api import SageClient

def sync_booking_to_sage(booking_data):
    sage = SageClient(api_key=SAGE_API_KEY)
    
    # Check stock availability
    stock_level = sage.get_stock_level(booking_data['product_code'])
    
    if stock_level < booking_data['quantity']:
        return {'status': 'insufficient_stock', 'available': stock_level}
    
    # Create invoice
    invoice = sage.create_invoice({
        'customer_id': booking_data['customer_id'],
        'line_items': [{
            'product_code': booking_data['product_code'],
            'quantity': booking_data['quantity'],
            'price': booking_data['price']
        }]
    })
    
    # Update inventory
    sage.adjust_stock(
        product_code=booking_data['product_code'],
        adjustment=-booking_data['quantity'],
        reference=f"Booking {booking_data['booking_id']}"
    )
    
    return {'status': 'success', 'invoice_number': invoice.number}

Nothing fancy. Just connecting two systems that needed to talk.

The booking system now checks Sage for availability in real-time. Creates invoices automatically. Updates inventory as bookings complete. Customer details sync both ways.

Cut that 40 minutes down to zero. Eliminated stock errors. Gave them real-time visibility they never had before.

Delivered in four weeks. Sage 50 is still there, still doing what it does best.

The Gotchas (Because There Always Are)

APIs that don't exist. Some older systems genuinely have no way to talk to them programmatically. But I've found most have something—ODBC connections, CSV exports, even screen scraping as a last resort. It's not always pretty, but it works.

Performance surprises. That system that handles 50 transactions a day fine? Might struggle when you suddenly ask it to process 500 via an API. Test under realistic load.

Data quality issues. Integration exposes problems you didn't know you had. When data was manually copied, someone was quietly fixing inconsistencies. Automate it and suddenly you're seeing all the places where product codes don't match or customer records are duplicated.

Scope creep. "While you're at it, can we also..." is the death of these projects. Stay focused. Solve the specific problem. You can always add more later.

The system that's actually worse than you thought. Sometimes you dig in and discover the legacy system really is held together with string and prayers. That's when you have an honest conversation about replacement.

When Integration Is the Wrong Answer

Be honest with yourself:

If your team actively hates the system and it's killing morale, integration might just prolong the pain. Sometimes a fresh start is worth it for the psychological boost alone.

If you're spending more time working around limitations than actually working, that's a sign. Integration can bridge gaps, but it can't fix fundamental dysfunction.

If the business is about to change dramatically—merger, new market, complete pivot—you might need systems that support where you're going, not where you've been.

And if you've already got six layers of integrations holding everything together with duct tape, adding another might not be wise. Sometimes the integration debt gets too high.

The Real Question

Here's what I ask clients: What problem are you actually trying to solve?

Not "the system is old." What specific business problem is costing you time, money, or sanity?

Once you're clear on that, the answer usually becomes obvious. Sometimes it's replacement. More often, it's targeted integration that solves the actual problem without the cost and risk of ripping everything out.

I'm tired of seeing small to mid-sized businesses oversold on solutions they don't need. You don't need what works for a Fortune 500. You need what works for your business, at your scale, with your budget.

Quick Questions I Get Asked

How long do these integrations typically take?

Depends entirely on complexity, but most of what I do is measured in weeks, not months. Simple data syncs might be a week or two. More complex integrations with business logic might be six to eight weeks. If someone's quoting you six months for basic integration, ask why.

What if the legacy system eventually does need replacing?

Then you replace it. But you've bought yourself time. You've solved immediate problems. And you've learned exactly what you need from a replacement by living with the integrations. That makes the eventual replacement project much more likely to succeed.

Can't we just use Zapier or similar tools?

Sometimes, yes. I love Zapier for simple stuff. But it gets expensive at scale, and it's not great for complex business logic or high-volume data. For simple triggers and actions between cloud apps? Absolutely try it first. For serious integration with legacy systems? Usually needs something more robust.

What about security?

Crucial question. Any integration needs to be secure—encrypted connections, proper authentication, audit logging. But this isn't harder than securing a new system. Often it's easier because you're not exposing everything, just specific data flows.

How do we maintain this long-term?

Good integration should be maintainable. Document it properly. Use standard tools and approaches. Don't build clever solutions that only one person understands. I aim for code that your next developer can pick up without wanting to rewrite it all.

Let's Talk About Your Situation

Every business is different. Your legacy system, your pain points, your constraints—they're specific to you.

If you're wrestling with whether to replace or integrate, I'm happy to have a conversation. No sales pitch, no commitment. Just a practical discussion about what might actually work for your situation.

Drop me a line at hello@stirlingjonessolutions.co.uk or use the contact form at stirlingjonessolutions.co.uk.

Sometimes 20 minutes of honest conversation can save you months of going down the wrong path. I've been doing this long enough to tell you when replacement makes sense and when it doesn't.

Your legacy system might be your biggest asset. Or it might be time to move on. But let's figure that out based on your actual business needs, not vendor promises or the fear of being left behind.

Because "old" and "broken" aren't the same thing. And sometimes the smartest move is keeping what works and fixing what doesn't.