03 - Build & Modernize / Legacy Modernization

Legacy Modernization

AI-assisted refactoring and re-platforming for legacy systems blocking your roadmap - incremental strangler-fig modernization instead of a rewrite that takes several quarters.

Entry packageLegacy Assessment & Roadmapfrom EUR 6,1001 system · up to 4 weeks from scopingWhat is included
In short
01

Replace in slices, not in one bet

Strangler-fig boundaries let modernized components run beside the legacy until it can retire.

02

A budget per phase

The roadmap prices each phase, so the decision to continue is made with numbers.

03

Tests on both sides of the seam

Coverage and documentation for the modernized and the legacy boundary, so nothing breaks unseen.

23Minds modernizes legacy systems blocking product roadmaps.

Show the full summary

The engagement assesses the system, identifies strangler-fig boundaries, and replaces components incrementally using AI-assisted refactoring at a fraction of full-rewrite cost. Typical engagements: PHP/Perl/older .NET monoliths, legacy Java EE, jQuery-era frontends, untyped JavaScript / legacy Python codebases. Output is a modernized system that runs alongside the legacy until the legacy can be retired safely.

Why 23Minds

What makes this service defensible.

  • Assessment before any code

    Architecture, dependencies and risk hotspots mapped in the first package.

  • AI-assisted refactoring with human review

    Every migrated component passes the same gates as new code: checks, PR, review, verification.

  • Assessment and roadmap in four weeks

    One system; the price is fixed once the scope is agreed, sequenced phases with a budget each.

  • Knowledge transfer built in

    Pair sessions and written architecture docs, so your team owns the new shape.

How we work

The process, phase by phase.

  1. 1

    1. Assessment

    Read the codebase under NDA. Interview engineers who maintain it. Run static analysis. Map dependencies.

    Week 1-3
    One large solid block with thin cracks running across it and yellow markers at three points: the monolith after code analysis and dependency mapping, its weak spots marked.
  2. 2

    2. Roadmap design

    Identify strangler-fig boundaries. Sequence phases by risk and roadmap unlock. Budget per phase.

    Week 3-4
    An old block wrapped in a lattice that divides it into compartments, one compartment yellow: the boundaries along which components are carved out and replaced, phase by phase.
  3. 3

    3. Modernization sprints

    Replace components phase-by-phase. Each phase ships behind a routing layer running both old and new in parallel.

    Week 4-N
    A row of equal modules with one hollow and one yellow, repeated with the yellow one moving along: components swapped out one at a time behind a routing layer.
  4. 4

    4. Legacy retirement

    Once a component is fully replaced and stable, retire the legacy path. Repeat until the legacy is gone.

    After each phase
    The faint outline of the old block on the left and a cluster of six connected modules on the right, joined by one yellow line: the legacy path retired once the new one runs on its own.
How to start

Pick the way in that fits your budget and timing.

Every practice has a free first step, an entry package with a written deliverable and its price listed here, and a full project or retainer quoted after a first call. Once the scope is agreed, the price is fixed, with no hidden costs.

  1. 1
    Step 1 · Free

    Intro call or self-assessment

    60 minutes · 1 engineer · no obligation

    Free
    Show details
    • Intro call with an engineer, or the online self-assessment
    • A written next step within one business day
    • No obligation and no sales deck
    Talk to an engineer
  2. Recommended
    2
    Step 2 · Entry package

    Legacy Assessment & Roadmap

    1 system · up to 4 weeks from scoping

    from EUR 6,100 net

    The price is fixed once the scope is agreed on the intro call, no hidden costs; extras only from the Not included list.

    Show details
    • Assessment of one legacy system: architecture, dependencies, risk hotspots
    • Strangler-fig modernization roadmap
    • Budget per phase
    • Readout session with your team
    • Not included: Modernization work itself, data migration, filling test gaps, legacy retirement.
    Ask for this package
  3. 3
    Step 3 · Project or retainer

    Full scope, quoted after a first call

    Full scope · phased delivery · quoted per phase

    from EUR 28,000 net, quoted after a first call
    Show details
    • Phased modernization sprints
    • Components running in production alongside the legacy
    • Budget and scope confirmed per phase
    Start the conversation
Sounds familiar?

The situations that bring teams to this service.

  • The legacy system has no tests; every change risks production
  • Documentation is missing or outdated; institutional knowledge sits with one or two engineers
  • A full rewrite is too expensive to fund; living with the legacy costs more each quarter
Show the other problems (1)
  • Hiring is hard because new engineers do not want to maintain the old stack
Who it's for
  • CTOs whose roadmap is blocked by a system the team is afraid to touch
  • Engineering leaders facing a 'rewrite vs live with it' decision
  • Mid-stage companies whose first-product codebase no longer matches the team that maintains it
  • Acquirers integrating a target whose tech stack is materially older than theirs
Failure modes

Where this goes wrong, and what we do about it.

  1. 1. Generated tests freeze the bugs inWhat stays with you: a list of behaviours confirmed as intended and behaviours reported as defects, and a test suite carrying that split
    What happens

    An assistant writes tests for code that never had any, and does it quickly. The tests capture current behaviour, including the defects that have sat in it for years. The refactor passes green, and the defect is now protected by a test and has one more layer to remove.

    What we do about it

    Characterization tests are labelled as such. Before any refactor we go through the captured behaviours with the people who maintain the system: intended or accidental. Accidental ones get their own ticket, and the suite is split into what describes the specification and what only describes the current state.

  2. 2. The translation keeps the shape of the old codeWhat stays with you: an interface contract per replaced component, and coupling and duplication measured before and after
    What happens

    An assistant moving code from callbacks to async, or from PHP to TypeScript, translates idiom for idiom. The new component has a new language and the old coupling, so the modernization ends with the same monolith in a different syntax. A discussion about agents migrating COBOL put it in one line: a failure at a fifth of the price is still a failure.

    What we do about it

    Before we translate anything, we define the target interface of the component and translate towards it, not line by line. Coupling and duplication are measured before and after each phase, and we show the difference before a component counts as modernized.

  3. 3. The routing layer becomes the new legacyWhat stays with you: a cutover record per component with traffic share and the date the old path was deleted
    What happens

    The layer that sends traffic to the old or the new path is convenient, so it stays. Components get replaced, but the old path is never retired because retirement has no owner and no date, and the layer accumulates per-component exceptions. A year later the system has three versions of every function and nobody knows which one serves traffic.

    What we do about it

    Retirement is a phase of its own with an owner and a date per component. We track the traffic share on the old and the new path, and a component counts as done only when the old path is deleted from the repository, not merely switched off.

What you get

Deliverables, not deliverable-shaped slides.

  • Legacy system assessment (architecture, dependencies, risk hotspots, modernization options)
  • Strangler-fig modernization roadmap with sequenced phases and budget per phase
  • Modernized components running in production alongside the legacy
  • Test coverage and documentation for both modernized and legacy boundaries
  • Knowledge transfer to your team - pair sessions, written architecture docs
FAQ

Questions procurement teams ask.

Yes - strangler-fig is the standard pattern. We build the routing layer that runs old and new in parallel, replace one component at a time, and retire the old code only after the new path is stable in production. Big-bang rewrites are reserved for cases where strangler-fig is genuinely impossible.
AI tools accelerate the tedious parts: reading unfamiliar code, generating tests for code that has none, translating between idioms (e.g. callback-style to async/await), proposing refactors that humans review. The engineering judgment stays with our team; the volume work gets faster.
PHP (Symfony 1.x, custom legacy), older .NET (Framework 4.x ASP.NET WebForms / MVC), Java EE / Spring Boot pre-2.x, jQuery + server-rendered frontends, untyped Node.js codebases, legacy Python 2 / early 3.
Common starting state. Phase 1 of modernization typically includes building a test scaffold around the components we will replace - generated with AI assistance, reviewed by our engineers. Tests come before refactor, always.
Yes - that is the point of strangler-fig. The legacy keeps serving production traffic while new components come online behind a routing layer. Cutover per component is a configuration change, not a release.

Talk to an engineer.

Describe where you are with legacy modernization. A reply within one business day.

Talk to an engineer
Szczecin - ul. Wawrzyniaka 6WWarszawaZielona GóraKraków