Will you tell us to replace it?

Only if it genuinely warrants it. We take no commission or referral fee from any platform, so a replacement earns us nothing a stabilisation doesn't. Keeping the system is the recommendation more often than you'd expect.

Can you support software you didn't build?

That's most of what we do. Custom products, legacy platforms, open source and software abandoned by its vendor — reading unfamiliar code is the core skill, not an exception.

How do we avoid a big-bang cutover?

Where the architecture allows, we move function by function with both systems running. Where it doesn't, we say so early rather than discovering it during the cutover weekend.

What if we just want to know where we stand?

Then buy the assessment and nothing else. Two to four weeks, a fixed price, and a written picture of what you have and what the options cost. Plenty of clients stop there for a year.

AliveCommerce / Capabilities / Replace a legacy system

Replace a legacy system

It still works. That's what makes it difficult. Nobody left knows how it was built, the vendor is gone or disinterested, and every year it becomes slightly more load-bearing and slightly less understood. The risk isn't that it fails. It's that it fails at the worst possible moment.

Does this sound like you?

Tick what applies. The count changes what we'd recommend, and sometimes the recommendation is to do nothing yet.

What's actually causing it.

Almost never carelessness. Usually the predictable result of a decision that made sense at the time.

It was built for the business you were

Fifteen years ago it fitted precisely. The business changed; the software was customised to keep up; and the customisations are now the reason it can't be upgraded.

The knowledge left with people

Documentation was thin, the developers moved on, and what remains is institutional memory about which parts not to touch.

Replacement always looked too risky

Every year, replacing it is a bigger project than last year and the business case never quite clears. So it gets deferred, which is a decision even when it doesn't feel like one.

What we do about it.

In this order, because doing them out of order is how these projects fail.

Understand it before judging it

We read code we didn't write for a living. Before recommending anything we establish what it actually does, including the parts nobody remembers requesting.

Consider keeping it

Often the right answer. Stabilised, documented, wrapped in integrations and maintained properly, a legacy system can serve for years more at a fraction of replacement cost. We have no commission riding on the alternative.

Migrate in pieces where possible

Big-bang replacements are how these go wrong. Where the architecture allows, we move function by function so there's never a single day the business bets on.

Document as we go

Whatever the outcome, you end up with something written down. That alone removes most of the risk that made this hard to approach.

Assessment phase

2 to 4 weeks

What it does, what it's worth, what the options cost

Common outcome

Keep and stabilise

More often than the industry would suggest

Most common trigger

An EOL notice

Or a developer leaving, or a failed change

Which way in.

Same team either way. The difference is whether this has an ending.

A defined project

AliveCommerce

Assessment, modernization or migration with a fixed budget and controlled scope. Including the assessment on its own, if that's all you need right now.

Legacy modernization

Continuous ownership

Champion1

When the answer is to keep it running properly. We take on custom and unsupported software that nobody else will touch, and maintain it under a fixed monthly fee.

See Champion1

What it looks like in practice.

Distribution · 80 staff · 14 months

A twelve-year-old ERP nobody could safely touch

The recommendation was to keep it. We mapped the real process, replaced the fragile seams with integrations, and left the ERP where it was.

Nothing

spent replacing the ERP

Straight answers.

Related.

These tend to travel together.

Connect systems that don't talk“An export, an import, and a spreadsheet in between.”Take software off my plate“Nobody owns the stack. Everyone owns a piece of it.”Recover a failing project“Past deadline, past budget, no end in sight.”

Tell us what's breaking.

We'll tell you which part of this we'd put on it, roughly what it costs, and whether it's worth doing at all — including when the honest answer is that you don't need us.

Start the Conversation

Knowledge and process

Applications and data

Customer and web

Browse by symptom instead

The structure

Continuous ownership

Before you commit

Start with one problem

Priority sectors

Also

Or by situation

Not sure you fit?

Reading

Most read

Proof

Nobody owns the application layer