Application Modernization Services: What to Expect

Part 8 defined the outcomes a modernization is supposed to produce. This part is about the engagement that produces them — what a serious application modernization service actually looks like from the inside, so that a team at the point of choosing a provider can tell a sound engagement from a risky one before signing rather than after. It is a BOFU article in the most literal sense: the reader is deciding whether and with whom to do this.

A note on what this article is and is not. It does not quote a price, because the only honest cost for a specific system comes from understanding that system first — the reasoning is in Part 4 and the legacy series’ cost article. What it describes is the shape of a credible engagement: the phases, the deliverables, what a provider will need from you, and the warning signs that separate a serious partner from a dangerous one.

Understanding before commitment

Everything good about a modernization engagement follows from one principle: understand the system before committing to transform it. Everything dangerous follows from violating it. A provider who proposes a firm plan and a firm price for a large modernization before reading the actual system is guessing — and the guess is either wrong or padded heavily to cover the risk of being wrong. The discipline is to make the understanding the first, bounded, deliverable thing, and only then commit to the larger program.

That is why a serious engagement does not begin with a statement of work for the whole transformation. It begins with a conversation and then a bounded assessment. The path is deliberately staged: a 30-minute discovery call to understand the situation, a technical assessment, a proposal grounded in what the assessment found, and then kickoff. No deck required for the first call. Each step de-risks the next, and you make the big commitment with evidence in hand rather than on faith.

The three phases

A credible engagement runs in three phases, each producing something real and each de-risking the decision to proceed to the next.

Phase 1 — Discovery

A fixed-scope, fixed-price phase, typically 3–4 weeks, whose job is to replace guesses with evidence. The AI-accelerated analysis reads the codebase, data, docs, and APIs, maps the dependencies and the domain rules nobody wrote down, and turns them into a concrete set of deliverables you own regardless of whether you proceed:

• Architecture Blueprint — what the system actually is.
• Domain Model — the business reality the code encodes, slices prioritized by value.
• Migration Roadmap — the sequenced plan for transforming it.
• Target Architecture — what it is being modernized toward.
• Test Harness and Traceability Framework — the validation machinery, in place before any code is changed.

Discovery is the bounded investment that produces the estimate for the unbounded-looking program. It is what lets the rest be priced and planned on real information. A provider unwilling to do this first — who wants to skip to building — is a provider asking you to fund a guess.

Phase 2 — Accelerator

Typically 6–10 weeks, fixed price per slice. This phase puts the first slice into production and stands up the machinery that makes all the later slices safe. By its end: one real piece of the system is modernized and carrying live traffic, the test harness is operating, and the strangler facade is live — legacy and modern running side by side, with traffic shiftable and rollback available. The accelerator is where the approach stops being a promise and becomes a demonstrated fact, on your system, with your first measurable before-and-after in hand.

Phase 3 — Transformation

The ongoing delivery phase, 4–18 months depending on system size, on a T&M or fixed model. Slices ship at steady velocity — working software in production every 4–8 weeks — each proven before it carries load, each retiring a piece of the legacy system, until the legacy system is decommissioned. The deferred queue from each slice feeds the next, so nothing is lost between increments. This is where the bulk of the value accrues, and because it is incremental, the return is accruing the whole way through rather than waiting for an end.

A duration note worth being precise about: the transformation phase scales with the system, so 4–18 months is the honest range. The often-quoted “two-to-three years of work in four-to-six months” is a marquee framing for what AI-accelerated, slice-by-slice delivery can compress — based on engineering modeling, with early engagements underway — not a guarantee that every program finishes in six months. A provider who promises the marquee figure as a contractual certainty for your specific system is overselling.

The full breakdown of the three phases lives on the engagement-model page.

What runs through every phase

Some things are not a phase but a constant — the practices that should be visible at every stage of a serious engagement:

• Parity proven before cutover. Every slice clears parity gates — functional parity, data integrity, non-functional parity, a traceability log — before it carries live traffic. Proof, not promises. This is the discipline the parity-validation series is devoted to, and its presence or absence is the clearest single tell of a serious provider.
• The business keeps running. There is no frozen roadmap and no downtime window the organization has to survive. Modernization happens around a working business, not instead of one.
• Knowledge captured as living specs. The undocumented rules come out of the old code and people’s heads and into documentation the team owns — so the engagement leaves you more capable, not dependent on the provider.
• A single point of accountability. A modernization lead owns the outcome, backed by a core team — enterprise architecture, full-stack engineering, AI engineering, QA automation, DevOps — and a specialist partner network for validation, data migration, and UI/UX.
• Stack-agnostic delivery. Any cloud, any modern language, any data platform, including regulated and air-gapped environments. The approach adapts to your constraints rather than forcing a destination.

On the toolchain specifically: a serious provider may use AI heavily, but it should be described and operated as how the work is delivered — a proprietary AI toolchain in expert hands, steered by senior engineers under human-in-the-loop review — not sold as a turnkey product that removes the need for judgment. The approach page describes how that toolchain is applied without ever becoming the protagonist of the work.

What the provider needs from you

A modernization is a partnership, and the engagements that go well are the ones where the client provides three things. A provider who does not ask for them is not set up to succeed:

• Read access to the codebase — discovery works from the real system, so the provider needs to see it.
• An executive sponsor — modernization touches budgets, roadmaps, and operations; it needs someone with the authority to clear the path.
• Workshop time with SMEs — the people who hold the undocumented knowledge are part of capturing it, and their time is a real input, not an optional extra.

The warning signs

The fastest way to evaluate a provider is to watch for the patterns that reliably precede failure:

• A firm price for the whole program before discovery. Either a guess or a pad. A serious provider prices the discovery, then the slices, on evidence.
• A big-bang plan. A program that delivers nothing until a distant cutover concentrates all the risk into one moment — the structure behind the field’s high failure rate. Boston Consulting Group found up to 70% of digital transformations fail to deliver on their objectives (2023), and big-bang structure is a large part of why.
• Validation as an afterthought. If “testing” is a phase near the end rather than a gate on every slice — proving each piece against actual legacy behavior before it ships — the provider is migrating on hope.
• No knowledge-capture plan. An engagement that does not leave you with documented, owned specs leaves you dependent and no more capable than before.
• A turnkey tool or rewrite pitch. Anyone selling a tool or a from-scratch rewrite as a hands-off answer, without naming the human judgment the work still requires, is selling the easy story rather than the real one.

Two things worth knowing before you sign

First, the three-phase shape is the right default, not a universal law: a small, well-understood system may not need a full discovery phase, and a genuine lift-and-shift case is a different, lighter engagement than a transformation — a good provider will tell you when your situation needs less than the full model, not more. Second, ModernLift is a new entrant in the US market, and the honest framing of its track record is that engagements are early — the methodology is proven in its design and in the disciplines it is built on, and the marquee speed figures are based on engineering modeling with early engagements underway. A provider who claims a decade of identical US case studies is making a claim worth checking; the right response to a new entrant is to weigh the methodology and the early evidence, which is exactly what the next part is about.

Where this leads

The natural last question before committing is “show me it worked” — the case studies. But modernization case studies are among the easiest marketing artifacts to dress up, and reading them well is a skill in itself. Part 10, Application Modernization Case Studies & Outcomes, is about how to read a case study critically, what outcomes this methodology is built to produce, and how to evaluate a provider’s evidence honestly — including a new entrant’s — rather than being swayed by a logo wall.