How to fund application modernization initiatives

• Why phase-gate app modernization funding
• The primary phases of app modernization funding
• Common app modernization pricing models
• Reducing costs with provider, vendor, and partner plays
• Managing funding and costs while maintaining legacy systems

Phased funding lets you fund based on evidence, not ambition. You control costs based on outcomes, not just implementation milestones on your app modernization roadmap. Phased funding also helps keep stakeholders aligned, vendor-partners focused and accountable, and the right strategies and priorities moving forward when agility is important in the face of changing market conditions and the technology landscape.

If you’re asking your leaders (or your leaders are asking you) to “big bang” application modernization, you’re setting your organization up for a lot of potential pain. Enterprise leaders and their transformation partners need to fully understand application dependencies, business logic, technical debt, test coverage, and all the implications for delivery velocity before estimating costs.

While most leaders understand that, operating from that point of view can still feel uncomfortable. That’s why we recommend making investments based on three principles—and in phased, evidence-based gates.  

Structure your funding model for five phases: Discovery; Assessment; Proof of value; Scaling modernization; and Enhance, optimize, or transition.

Each application modernization phase should deliver two things: Measurable progress based on the business value agreements made up front, and a better-informed decision about what to do next.

• What you're funding: Early planning and a high-level review
• What the funding should produce: Shared goals, key priorities, and a clear scope for deeper analysis
• Decision that Discovery phase enables: Do we need a full assessment?

Start with a small commitment focused on stakeholder alignment. Clarify the business outcomes modernization needs to support, review the application environment at a high level, identify likely priorities, and determine what needs deeper investigation.

The goal is to discover and align on whether a more detailed assessment is warranted and what that assessment should cover, so you can fund with focus and confidence.

• What you're funding: A closer look at apps, data, code, risks, and dependencies
• What the funding should produce: Application inventory, priority list, approach, sequence, and business case
• Decision that Assessment phase enables: What should we modernize first, and what will it take?

The assessment creates the evidence your executive leadership team needs to make and stand behind defensible investment decisions. Evidence can include an application inventory, the recommended modernization approach for each application, dependency and complexity analysis, prioritized backlog, sequencing, and a business case.

The goal is to turn an early estimate into an action plan grounded in the actual application estate.

• What you're funding: A small but valuable modernization effort
• What the funding should produce: Evidence that the approach works (or doesn’t), plus a better view of speed, quality, and team readiness
• Decision that Proof of value phase enables: Should we scale this approach?

Test the approach defined by the assessment on a bounded piece of work. For example, a proof of value can validate code transformation, quality controls, cutover mechanics, team readiness, and delivery velocity before those assumptions are applied across a larger portfolio.

Proving value before scaling is business critical and economically responsible because faster individual engineering work does not automatically translate into faster program delivery. Velocity assumptions should be proven in a pilot before they are built into larger commitments.

• What you're funding: More delivery capacity across priority applications
• What the funding should produce: Modernized apps, fewer legacy dependencies, and stronger internal skills
• Decision that Scale phase enables: Do we keep going, adjust the plan, or start handing over ownership?

Once the proof of value shows a credible baseline, scale delivery capacity to match the prioritized scope, business goals, and the organization’s ability to review and absorb change. Keep in mind that capacity should reflect your organization’s ability to review, approve, integrate, and operate the work—not just how fast delivery teams can produce it. Remember, too, that scaling application modernization can involve different delivery mixes, including co-delivery with your engineers, which changes both cost and capability transfer.

• What you're funding: Ongoing support, improvements, and knowledge transfer
• What the funding should produce: Stable operations, continued improvements, and a path to internal ownership
• Decision that Enhance... phase enables: Do we keep outside support or transition fully to our teams?

This phase is not just “support after go-live.” This is a dynamic phase where organizations continue to build new muscles with ongoing enhancements, incident response, continuity, and a structured path that tapers to self-sufficiency.

It may also break into smaller funding phases where you create milestones and proof of value gates around decisions to continue support, keep optimizing, or hand off more ownership.

Application modernization can be funded through several commercial pricing models, and the right model often changes as the program moves from assessment to execution.

• Early phases with clear scope and outputs are easier to price as fixed commitments.
• Larger modernization efforts introduce more variability, making capacity-based or blended models more practical.
• Partner funding may also offset some costs when the work qualifies.

A fixed-fee model sets an agreed price for a defined scope and set of deliverables. Fixed fee models work well for bounded phases where the expected output is clear, such as an application assessment or proof of value.

For scaled modernization, funding can shift toward delivery capacity, with investment based on the number and mix of teams or pods working across the prioritized portfolio. Capacity can scale up or down as scope, priorities, and proven delivery velocity change. It’s not uncommon for capacity-based models to be renewed monthly or at other agreed upon milestones.

A blended model combines partner specialists with dedicated members from your internal teams. Blended funding is beneficial because it reduce the need for (and costs associated with) external capacity. It also fast-tracks knowledge transfer and internal capability building.  

It’s quite common for internal engineers or quality engineering team members to work directly within delivery pods, and in many cases, they can make up the bulk of the delivery pod. This model depends on whether those internal team members can be dedicated to the program vs. having to pull them back-and-forth from business-as-usual work.  

After the primary modernization work, a retainer model can fund continued enhancements, incident response, operational support, and further knowledge transfer. The investment can continue as needed or taper as internal teams become ready to take greater ownership.

Cloud and technology partners may offer funding, credits, or other program support that offsets part of a modernization investment. These programs can supplement another model, but they should support—not determine—your enterprise application modernization strategy.

Cloud and technology partners can help reduce the cost of application modernization through funding programs, credits, assessments, and co-sell support. AWS, Microsoft, Google Cloud, and other providers may offer these options when a modernization effort aligns with their platforms or partner programs. Availability depends on the workload, architecture and technology path, deal structure, and timing.

And timing is more important than you might think. Evaluate partner funding at the start of the engagement, not after the program is already structured. This early consideration gives teams time to understand eligibility, align the work to the right programs, and factor any available support into the funding plan.

A strong modernization partner can also help simplify that process. But partner funding should support the modernization strategy—not drive it. The right platform and architecture should still be chosen based on business value, application needs, risk, and operating requirements. Funding can make a good modernization path easier to pursue, but it should not be the reason an organization chooses that path.

Most organizations can’t stop operating, and by extension, funding legacy systems while they modernize them. Critical applications still need maintenance, support, security, and infrastructure until modernized capabilities are proven. It’s then, and only then, that legacy systems can be safely retired.

A phase-gated funding model can help manage that overlap. Instead of funding the entire modernization program upfront, organizations can start with assessment, fund a bounded proof of value, and increase delivery capacity as the approach is validated. This creates decision points where leaders can adjust scope and investment based on real evidence rather than long-range assumptions.  

The other side of the equation is decommissioning with discipline. Modernization doesn’t deliver its full economic value if the organization continues paying indefinitely for both the modern and legacy environments. The funding plan should account for when legacy applications, infrastructure, or dependencies can be retired—not just when new capabilities go live.

It’s also important to understand that, as you begin your modernization investments, there will be a short-term, net increase in technology costs. Once those modernization investments are live, you can expect to start seeing savings. But the estimates for upfront costs and time to value are context dependent. As you talk with potential vendors, be sure you explore these considerations.

Build the business case by connecting modernization to:

1. Specific business outcomes
2. The cost of maintaining the status quo

Once you identify your desired outcome, set baseline metrics for KPIs like engineering capacity spent on maintenance versus new capabilities, deployment velocity, system stability, technical debt, and progress toward priority AI use cases. These measures give leaders something concrete to track as modernization progresses. 

Then, conduct an assessment to uncover the blockers to achieving the outcome. The list will be longer than you think: assess the application dependencies, complexity, technical debt, risks, and ongoing maintenance burdens. Then, with an accurate assessment, your business case reflects your unique environment. You want to make sure the assessment isn’t based on generic industry benchmarks or internal guesstimates.  

The business case should also account for the cost of inaction. Maintenance burdens, siloed skill and talent risks, delayed AI opportunities, etc. all create risk and drag for your organization. Quantify the risk factors, so you can see which applications carry the biggest opportunity costs and align around those first. After all, when resources are limited, it’s fair and prudent to understand that not all legacy applications carry the same cost or urgency.  

Finally, don’t make the business case depend on getting a multiyear forecast right. That crystal ball doesn’t exist. Instead, a phase-gated approach empowers your leadership team to stay aligned by building evidence that shows how modernization is working. When you can measure value realization, and measure it incrementally, you can make new investments based on the value each phase-gate has demonstrated so far.