A decade-old platform didn’t need a rewrite

Situation

After more than ten years of development, SmartFrame obviously had legacy technology.

There were old APIs, old workflows, services from different stages of the company and assumptions that had been made years earlier for perfectly good reasons.

Some of them were annoying.

Some genuinely needed replacing.

Others just happened to be old.

That distinction came up very clearly when the company started moving towards a much larger image-library model.

The expected ingestion volumes changed dramatically and somebody quite reasonably asked whether we now needed a large-scale rethink of the infrastructure.

We looked at it.

The answer was no.

We had specific bottlenecks to fix, but no evidence that rebuilding the entire platform would make sense.

What I did

There wasn't one dramatic "rewrite versus no rewrite" decision.

We made that decision in smaller pieces for years.

Authentication changed.

Front-end delivery changed.

APIs evolved.

New connectors were added.

Parts of the image-processing path changed.

Infrastructure changed.

Some old customer workflows, including things like JPEG and FTP delivery, stayed around because customers still used them and they still worked.

In one integration model, information could travel through an existing workflow with a normal JPEG and later allow the publishing side to recognise the image and replace it with the richer SmartFrame experience.

That was much easier for some customers than asking them to redesign their content pipeline first.

If keeping an older interface was cheap and commercially useful, I was happy to keep it.

If it started contaminating every new feature with special cases, that was a different conversation.

The later ingestion work is a good example.

Rather than deciding from the age of the system that the architecture must be the problem, we traced the actual processing path, progressively load-tested it and found where the bottlenecks were.

We made targeted improvements.

That path subsequently demonstrated roughly one million images per day of ingestion capacity.

At that point the rewrite argument became fairly weak.

The business had asked whether the existing platform could support the new direction.

We had measured it and shown that, with specific changes, it could.

Outcome

SmartFrame ran for more than a decade without a complete platform rewrite.

During that time plenty of individual things were rewritten, replaced or retired.

The company kept the useful parts of what it had already paid to build while modernising the areas that were actually causing problems.

The ingestion example is useful because it gave us a measurable result: around a million images per day on the relevant path after targeted work, without waiting for an entirely new platform.

I can't credibly tell you how much a hypothetical rewrite would have cost because we never commissioned one.

But I do know what it would have involved: rebuilding mature behaviour, migrating integrations, running old and new systems in parallel and rediscovering a decade's worth of edge cases.

Sometimes that is still the right thing to do.

In this case we didn't have evidence that it was.

What I took from it

When somebody tells me an old platform needs rewriting, my next question is usually "which part is stopping the business from doing what?"

If the answer turns into a short list of bottlenecks, I'd rather investigate those first.

If the answer is that every meaningful product change now cuts through a pile of assumptions that can't be separated, then a bigger replacement may well be justified.

I've seen both.

What I wouldn't do is approve a rewrite because the technology feels old.

That's a very expensive way of making an engineering team feel better.