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 behavior someone depends on, so every change after that can be checked against them.

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.

  • 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 toward.

Read: The strangler fig pattern: modernize without a rewrite Front ends moved to React: React & Next.js Development AngularJS apps rebuilt as Angular apps: Angular Development Vue 2 apps moved to Vue 3: Vue.js & Nuxt Development Older PHP moved to Laravel: PHP & Laravel Development Older .NET Framework apps moved to current .NET: .NET Development Umbraco 7 and 8 sites brought to Umbraco 17: Development for Umbraco sites Older JavaScript moved to TypeScript, a file at a time: Software development, in TypeScript Older services moved to Go, one at a time, where it helps: Software development, in Go Older Rails apps, improved a part at a time: Development for Ruby on Rails applications C and C++ components moved to Rust, one at a time: Software development, in Rust Java 8 systems moved to current Java: Java Development

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.

  • 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.

Run sheetSwitching the orders system
  1. The week beforeThe way back tested, end to endOwner: Our engineers
  2. Switch dayPlanned window, if one is neededOwner: Both teams
  3. Switch dayData moved to the new systemOwner: Our engineers
  4. Switch dayReconciledCounts and totals checked on both sidesOwner: Both teams
  5. Switch dayReversibleGo or no-goOwner: Your operations lead
  6. Point of no return
  7. Switch dayOld system set to read onlyOwner: Our engineers

So it doesn’t become legacy again

A modernized 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

How each is paid for: Pricing

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 }}