You’re in good company

A few of the companies we’ve worked with.

When software gets hard to change

Most older systems still do their job. What changes is the cost of changing them. A small update takes weeks because nobody is sure what it will affect, the people who knew the code have moved on, and the framework underneath no longer receives security updates.

Because it still works, it stays on next year’s list. Until the day something has to change quickly.

First, learn what it really does

An older system is often the most complete record of how the business works. Rules added over the years live in the code, not in any document.

We start by mapping it: the code, the data, the connections to other systems and the people who use it every day. Then we write tests that record what it does today, including the unusual behaviour someone depends on, so every change after that can be checked against them. It works the same way whether you built the system, bought it or inherited it from another supplier.

Piece by piece, with the old system running

Replacing a whole system in one go usually means months of work that only pays off on the day you switch, with most of the risk arriving on that day. We replace it in pieces instead.

  • A layer in front

    Requests pass through a layer that decides which system handles each one, so work can move across without anyone changing how they use it.

  • Old and new, compared

    Where it helps, a new part runs alongside the old one and their results are compared before it takes over.

  • A way back

    While the old part is still there, each move can be reversed, so if a problem appears the work can move back while it’s fixed.

  • Switched off at the end

    When nothing depends on the old system any more, it’s switched off. That’s the milestone we plan towards.

Read: The strangler fig pattern: modernise without a rewrite

Ready for the day you switch

The data is usually the hardest part to move and the most important to get right. Years of records carry old formats, duplicates and rules nobody remembers.

  • Rehearsed

    We move the data in full rehearsals first, so the real move is one the team has already done.

  • Reconciled

    Counts and totals are checked on both sides, and anything that doesn’t match is explained before go-live.

  • Reversible

    The plan for the day names the point of no return, who makes the call and how to go back before it.

  • Supported

    The people who built it stay close in the first weeks after the switch, while everyone settles in.

Run sheetSwitching the orders system
  1. Two weeks beforeRehearsedFinal rehearsal of the data moveOwner: Our engineers
  2. The week beforeThe way back tested, end to endOwner: Our engineers
  3. Switch dayPlanned window, if one is neededOwner: Both teams
  4. Switch dayData moved to the new systemOwner: Our engineers
  5. Switch dayReconciledCounts and totals checked on both sidesOwner: Both teams
  6. Switch dayReversibleGo or no-goOwner: Your operations lead
  7. Point of no return
  8. Switch dayOld system set to read onlyOwner: Our engineers
  9. First weeksSupportedThe people who built it stay closeOwner: Our team

So it doesn’t become legacy again

A modernised system should stay easy to change. We leave it with tests, automated deployment, monitoring and documentation your team can follow.

Work with us as a dedicated team, on a fixed price project or a mix of both.

Compare engagement models

Let’s build it better

Tell us which system is holding you back, what it does for the business and what needs to change. We’ll give you an honest view of the options and a sensible first step.

Thanks, we’ll be in touch soon.

{{ ctaStatus }}