Software engineering · A practical guide

What should you review before modernising a software system?

Before replacing or rewriting a system, understand what it does, what it depends on and the risks of changing it.

Explore the guide
CURRENT SYSTEM STAGED CHANGE T2G VALIDATE · ADAPT
A general guide: diagnosis, scope and risk controls are defined for each system.

Modernise with context

Modernising does not always mean starting from scratch.

Modernisation can improve security, maintenance, integration or ability to change. The path might involve fixing one part, mapping dependencies, replacing a component or redesigning the whole system when evidence supports it.

At T2G: we first assess the software’s current state and the problem to solve. That review helps define a staged scope, quality criteria and a path that accounts for the team’s day-to-day operations.

Before choosing a path

Review the system in use, not only its code.

A sound decision combines business needs with the current technical and operational state.

  1. 01

    Use and critical functions

    Identify who uses it, which tasks it supports, what happens if it fails and which parts cannot stop.

    WHAT THE SYSTEM SUPPORTS TEAM 1TEAM 2 SYSTEM PEOPLE · TASKS · CONTINUITY
    Conceptual schematic01 / 04
  2. 02

    Architecture and dependencies

    Map components, integrations, data, suppliers and knowledge held by only a few key people.

    MAP BEFORE CHANGING COMPONENTS · INTEGRATIONS · DATA
    Conceptual schematic02 / 04
  3. 03

    Risks and evidence

    Review incidents, security, maintenance, performance, available tests and budget or schedule constraints.

    REVIEW WITH EVIDENCE SECURITY PERFORMANCE MAINTENANCE ILLUSTRATIVE REVIEW · NOT A REAL SCORE
    Conceptual schematic03 / 04
  4. 04

    A change path

    Compare options and plan small, verifiable steps with a way to roll back if operations are affected.

    CHANGE · VALIDATE · CONTINUE ISOLATE CHANGE VALIDATE CONTINUE EACH STAGE HAS A VERIFICATION
    Conceptual schematic04 / 04

Decisions that clarify scope

Different parts may need different changes.

MAINTAIN AND FIX FIX ONE PART
01

Maintain and fix

Useful when a system does its job and problems can be addressed locally.

EVOLVE IN STAGES 01 02 03 04 EVOLVE IN STAGES
02

Evolve in stages

Can reduce risk when components are tightly coupled but the service must keep running.

REPLACE PREPARE IN PARALLEL · VALIDATE · TRANSFER PLAN THE TRANSITION
03

Replace

Consider when proven limitations outweigh the cost and risk of a well-planned transition.

Judgement before automation

Do not decide based on a trend or one metric.

  • 01

    A broad rewrite can carry old problems forward and add risk before delivering value.

  • 02

    Architecture changes need testing, monitoring and clear ownership.

  • 03

    The right option depends on priorities, people, the system and how it operates.

Next step

Explore the service and keep learning.

Talk about your challenge

Does your system need a change, but the path is unclear?

We can help assess the current state and organise options before committing to modernisation.

Book a diagnostic session directly with the partners