How to evaluate application modernization pricing and value

• Typical funding sources
• Commercial pricing models
• Hidden costs to watch out for
• What to prioritize when reviewing proposals

There are four primary funding models or funding sources for application modernization: enterprise-funded, business-unit-funded, cloud provider incentives and credits, and joint or co-investment structures.

Enterprise-funded means application modernization is financed through the organization's transformation or technology budget. It’s important for leaders to define clear success criteria, expected outcomes, ROI projections, risks, and an understanding of what’s being funded and what isn’t before moving into implementation.

Modernization can also be funded by the business unit receiving the benefit. That makes connecting technology investment to business outcomes particularly important. Slalom's application modernization approach begins by examining the application's business function, users, needs, modernization opportunity, potential value, and business case before determining whether—and how—to modernize.

Technology providers may offer eligible organizations funding for specific stages of modernization. Eligibility and mechanics vary by provider and program, but expect a modernization partner to identify applicable opportunities without treating potential funding as guaranteed.

Also, partner funding needs to be examined carefully. Sometimes the promise or expectation of partner funding can push organizations into picking hyperscalar, but the funding may not cover as much cost as you think (especially given anticipated consumption). Again, stay vendor-flexible and strategy-first before committing.

Funding may also come from more than one party, so an organization’s own modernization investment can be supplemented by eligible technology-provider funding or incentives that help offset specific stages of the work, such as assessment, proof of value, mobilization, or migration and modernization. The important consideration is to treat co-investment as a way to improve the economics or reduce the initial risk of a modernization path—not as a reason to choose a particular architecture, platform, or provider. Funding availability and eligibility can change, so validate the incentives before incorporating them into the business case or investment commitment.

The most common pricing models for application modernization are time and materials (T&M), fixed-fee (sometimes aligned to milestones), capacity- or team-based, and outcome- or value-based pricing.  

Bear in mind that early uncertainty may justify one structure. Once discovery has reduced uncertainty and outcomes can be measured credibly, it’s natural for leaders and modernization partners to update pricing models. No matter what commercial models are proposed, evaluate the commercial model alongside program scope certainty, delivery risk, measurable outcomes, and the amount of quality evidence available at each stage of the modernization journey.

In time and materials pricing, fees are based on the effort and resources used. T&M makes sense when there's a lot of uncertainty. Then, as more information is revealed over time, there may be opportunities to shift to fixed fee. It can be important to not negotiate the pricing model for an entire long-term contract in one go.

Fixed-fee pricing is especially common in bounded modernization efforts, including assessments, pilots, or other proof of value demonstrations. Fixed pricing can offer cost predictability when the scope, deliverables, assumptions, and acceptance criteria are sufficiently well defined. Fixed-fee models are most useful when the effort leads to a clear decision point before committing to broader implementation. Just beware that fixed-fee pricing can also trigger change orders (which can lead to delays, not just increased costs) if new information is uncovered.

In capacity-based pricing, also called team-based pricing, clients buy the continuous delivery capacity of a dedicated, cross-functional team rather than a fixed project scope or isolated hours of individual labor. Capacity-based pricing is good for fairly well-defined scope with an understanding there may be shifting priorities. Instead of traditional project funding (paying for a specific set of features) or staff augmentation (paying an hourly rate for individual developers):

• The client contracts a fixed, multidisciplinary team and sets the priorities, controls the product backlog, and manages to the strategic roadmap.
• The modernization consulting partner assumes responsibility for team composition, onboarding, continuous talent development, and maintaining the agreed delivery quality and velocity.
• The budget remains highly predictable (e.g., a flat monthly fee per team), but the scope can flexibly shift from sprint to sprint as modernization requirements evolve.  

The advantages of using capacity-based pricing are multi-fold, but there are two big ones: agility and speed.

Take agility: In the complex work of modernization, hidden architectural issues or client scope wishes change. In a fixed-price contract, this might trigger costly, bureaucratic change orders. In capacity-based funding, this friction doesn’t exist.

In terms of speed, capacity-based pricing contracts a durable team (there aren’t rotating consultants, which are a risk in time and materials pricing). An enduring team holds and deepens institutional knowledge, so the intelligence gained in, say, Week 7 accelerates into Week 12 into week 30 and so on.

As the marketplace shifts from effort-based pricing, outcome- or value-based pricing makes sense when an application modernization engagement can be tied to a specific business result that both parties can define, baseline, measure, and reasonably influence. This requires your organization to have an extremely well-defined problem and well-defined outcome before (or after) a vendor discovery. Outcomes need full agreement on demonstrated baselines, measurement methods, time horizons, and which variables the partner can influence versus what is influenced by the organization undergoing modernization.

As you evaluate vendor proposals and negotiate for modernization, be sure to ask discerning questions to help uncover assumptions and protect against hidden costs like these:

• Higher-than-expected operating costs
• Carrying unnecessary legacy logic forward
• Proprietary tooling dependency
• Poor documentation
• Insufficient knowledge transfer
• Delayed legacy decommissioning
• Running legacy and new environments at the same time

Application modernization pricing should support smart investment decisions: Consider the business outcomes modernization enables, the cost of operating the future environment, the risks retired, and the flexibility created for future change.

Look for proposals that clearly define assumptions, expose delivery and operating risks, connect spending to measurable outcomes, and preserve flexibility as new information emerges. The strongest commercial structure creates appropriate accountability without pretending uncertainty does not exist. When scope, value, risk, and decision points are transparent, leaders can compare modernization investments on legit economic impact instead of making decisions based primarily on upfront cost.