Should we rewrite or modernise?

Start by assuming modernise. A rewrite stops everything else for a year and often reproduces the original problems in newer syntax. Sometimes it is still the right answer, but it should be a conclusion rather than an opening position.

We inherited a platform and nobody knows how it works. Can you help?

Yes, that is a common starting point. The first piece of work is usually understanding and documenting what is actually there, before anything is changed.

Do you stay on after launch?

Where it makes sense. Long-term maintenance, dependency updates and the slow accumulation of small fixes are what keep a platform usable, and they are easier when the people who built it are still reachable.

Software delivery

Full-stack delivery and modernisation

Discovery through to long-term care

Most software that matters to a business is already running. The question is rarely whether to build something new, it is what to stabilise, what to replace and what to leave alone.

Modernisation without a rewrite

A full rewrite is the most expensive way to answer a question you have not asked properly yet. It also stops everything else for a year and tends to reproduce the original problems in newer syntax.

We start by stabilising what is fragile, simplifying where the architecture fights the team, and planning a route that delivers value in stages. Sometimes the answer is a rewrite. It should be a conclusion, not an opening position.

The whole life of the thing

Discovery and specification at the start, so the build is aimed at the right problem. Then the build itself: web systems, applications, CMS-driven platforms and the integrations around them.

Then the part that gets left out of proposals. Long-term maintenance, dependency updates, the slow accumulation of small fixes, and the documentation that means a new developer can be useful in a week rather than a quarter.

Where this comes from

Discovery, specification, CMS-driven platforms, legacy modernisation and long-term maintenance across a technical consultancy practice, including systems inherited from teams who had moved on.

Questions you may have

Should we rewrite or modernise?: Start by assuming modernise. A rewrite stops everything else for a year and often reproduces the original problems in newer syntax. Sometimes it is still the right answer, but it should be a conclusion rather than an opening position.
We inherited a platform and nobody knows how it works. Can you help?: Yes, that is a common starting point. The first piece of work is usually understanding and documenting what is actually there, before anything is changed.
Do you stay on after launch?: Where it makes sense. Long-term maintenance, dependency updates and the slow accumulation of small fixes are what keep a platform usable, and they are easier when the people who built it are still reachable.

More capabilities

Get in touch

Talk to us about this kind of work.

Tell us what you are building and what makes it hard. A short note is plenty, and it comes straight to Juan and Andrew.

Start a conversation