How to compare application modernization vendors and make a final decision 

• Principles for evaluating estimates
• 10 questions to ask a potential partner
• App modernization vendor scorecard

A strong application modernization partner should be able to provide three high-level explanations: an estimate based on the elements in their contract model, incremental progress checks where you decide go/no-go, and an outcome commitment to solving legacy modernization priorities.

Rather than accepting a single end-date estimate, evaluate whether the partner can:

• Break the program into stages and modernization waves to commit incrementally. Look for a model built for funding clear phases such as assessment, mobilization, proof of value, modernization, transition, and decommissioning. Phase gates are better than one large, “big bang” transformation timeline. Ask whether the partner can establish shorter proof points—such as an assessment, workshop, proof of value, or first modernization wave—before you commit to the full program.
• Tie dates to specific deliverables and acceptance criteria. A commitment to “finish in nine months” is less useful than commitments to complete dependency discovery, target architecture, a production workload, testing, or a migration wave by defined milestones.
• Show the assumptions behind the estimate. Assumptions promote transparency and help identify any gaps. For example, timelines may depend on code quality, documentation, application dependencies, SME availability, regulatory requirements, target architecture, test coverage, data complexity, and access to environments.
• Differentiate timelines by modernization pattern. Replatforming, refactoring, repurchasing, rehosting, relocating, retaining, and retiring applications have very different levels of complexity. A credible partner should not apply one timeline assumption across the portfolio.
• Explain how the timeline will be recalibrated. Discovery should reduce uncertainty. Ask when estimates will be refined, what evidence triggers a reforecast, and who approves changes.
• Show how accelerators affect the schedule. AI, automated dependency analysis, code comprehension, testing, CI/CD, and other accelerators may reduce effort, but the partner should identify where acceleration is realistic, not make promises about blanket productivity gains.
• Define shared responsibilities. A timeline is only credible if it identifies client dependencies such as SME access, approvals, environments, security reviews, data availability, and business acceptance.
• Explain what happens if milestones are missed. Understand escalation mechanisms, remediation expectations, commercial consequences where applicable, and whether the provider shares meaningful delivery risk.
• Include decommissioning in the schedule. Modernization is not complete when a new application is live. The roadmap should account for transition, business acceptance, operational handoff, legacy shutdown, and realization of the associated cost savings.

1. What delivery milestones are you prepared to commit to, not just estimate?
2. What assumptions does your timeline depend on?
3. Which dependencies are controlled by you, by our organization, and by third-party partners?
4. How will you determine the appropriate timeline for different modernization patterns and workloads?
5. When will you have enough discovery evidence to give us a higher-confidence forecast?
6. Can we prove the approach on a representative workload before committing to the full program?
7. How frequently will you reforecast schedule, cost, and value?
8. How do AI and automation change the timeline, and what evidence supports those assumptions?
9. What happens commercially and operationally if agreed milestones are missed?
10. Does your timeline extend through adoption, production transition, and legacy decommissioning?

Avoid making a final decision by comparing proposals line by line or allowing price, certifications, or company size to become proxies for modernization capability. Instead, build a consistent evaluation framework around the outcomes and risks that matter to your organization, then require each finalist to demonstrate how its proposed approach would work in your environment.

You want to be in a position where you can answer this question:

Which partner has given us the most credible evidence that their proposed approach can work here—and given us the clearest, lowest-risk way to prove the remaining assumptions before we make a larger commitment?

Don't score the written proposal alone. Use finalist sessions to stress-test the assumptions behind it. Give vendors a representative application or scenario and ask them to explain what they would investigate first, which modernization paths they would consider, what they cannot know yet, where the major risks lie, and what evidence they would obtain before asking you to authorize the next phase.

Finally, compare risk-adjusted value, not simply implementation price. Again, a proposal that appears to be better priced can become more expensive if, up front, it fails to anticipate everything that needs to be uncovered in discovery. It can also be inaccurately priced for factors after implementation, creating higher operating costs, delaying legacy decommissioning, carrying technical debt forward, or leaving your organization dependent on the provider.