Engineering for your business

System modernisation

Improve existing applications in stages while preserving the functions your operations rely on. Identify risks, reduce fragile points and plan migration with acceptance and rollback criteria.

Problems I can address

  • An important system that has become difficult to change.
  • Old dependencies, limited documentation and fear of downtime.

What the scope can include

  • Technical audit of architecture, dependencies and risks.
  • Incremental migration plan with backups and rollback.
  • Module refactoring and tests for critical workflows.
  • Documentation and a more maintainable foundation.

When to consider it

For companies evolving systems in use without an immediate full replacement.

Possible applications

Potential scope, not completed-project claims:

  • Replace an old screen while preserving essential business rules.
  • Extract a fragile integration into a testable module.
  • Migrate a workflow gradually with planned coexistence and rollback.

What affects the estimate

Code access, documentation, dependencies, test coverage and undocumented rules limit initial estimates. Technical discovery can be commissioned first. The plan must consider parallel operation, data reconciliation and rollback points; a full rewrite is not the default.

Limits and decisions

Estimates are limited without code and business-rule access. Technical discovery comes before schedule or migration commitments.

The deliverables on this page guide the proposal. Integrations, migration, support, infrastructure and responsibilities are confirmed in the agreed scope.

Evolution with a boundary and a recovery path

Identify a critical workflow, blocked change and known dependencies. I can assess authorised code, record behaviour, test an isolated intervention and prepare migration and recovery. Front-end or performance issues may be addressed without replacing the application. Without access or documented rules, discovery precedes timing commitments. The plan states what changes, remaining legacy dependencies and operating checks.

How the work progresses

  1. Audit code, dependencies and workflows that must remain available.
  2. Establish existing behaviour and regression tests.
  3. Migrate one module at a time with planned coexistence.
  4. Reconcile data, document rollback and retire legacy components gradually.

FAQ

Before we begin.

Does the entire system need rewriting?

No. Refactoring, a new interface or module extraction may solve the issue. Assessment compares alternatives before recommending replacement.

Can migration avoid downtime?

Staged coexistence may make that possible, but it is not guaranteed. Maintenance windows and risks depend on architecture, volume and dependencies.

What if there are no tests?

First we record critical behaviour and create characterisation tests. Rules need confirmation from people who know the operation before changes begin.