Modernize the software your business already depends on.

Starting with an honest assessment

Before recommending an approach we look at the system as it is, not as it is described. That means reading the code, running it, checking how it is deployed and backed up, and talking to the people who use and support it. The output is a map of the application's parts, each with its condition, how often it changes, what depends on it and a recommended approach: keep, improve, replace or retire.

The assessment usually changes the plan. Parts everyone assumed were fragile turn out to be stable and rarely touched. A small module nobody mentioned turns out to be the reason every release takes a week.

Recovering the business rules

Older systems hold rules that were never written down: how a discount is applied, when an order is allowed to ship, which customers are exempt from a check. Losing them is the biggest risk in any modernization. We capture them before changing the code, through characterisation tests that record what the system does today, through reading the code and through short sessions with the people who handle the exceptions. Those tests then guard every later change.

Keeping the business running

Modernization should not need a big switch-over weekend. The safety measures we rely on are ordinary engineering practice:

• A stable interface in front of the old system, so new parts can replace old ones behind it one capability at a time, the approach Martin Fowler calls the strangler fig.
• Running old and new side by side for a period, comparing results before the old path is switched off.
• Feature flags, so a new path can be switched on for a few users and off again without a release.
• Data reconciliation, with automated checks that records match between old and new stores during migration.
• Rehearsed rollbacks, practised before they are needed.

Measuring progress

Modernization is easy to fund at the start and hard to defend in the middle. We report progress in terms the business recognises: how long a typical change takes to reach production, how often releases cause incidents, how much of the old system has been retired, what it costs to run, and which new capabilities are now possible. Each stage should move at least one of those measures.

When not to modernize

Sometimes the right advice is to leave a system alone. If it works, rarely changes, is supported and does not block anything else, the best investment may be tests, monitoring and documentation, not a new architecture. And if a packaged product now does the job well, replacing the system may be cheaper than improving it. We will say so.

An example

Imagine a distributor whose order system is fifteen years old. The assessment shows the pricing logic changes monthly and causes most release pain, while the stock and invoicing modules are stable. The first stage puts an API in front of the system, moves pricing into a separate service behind it with characterisation tests proving the same results, and runs both in parallel for a month. Stock and invoicing are left alone for now, with monitoring added. Releases of pricing changes go from a planned weekend to an ordinary weekday deployment.