The Most Important Decision in Modernization Isn’t What You Build but What You Build First

Most executives signing off on a modernization program are being asked to commit to a number before anyone has touched the system. Scope, budget, timeline, a multi-year statement of work—all of it built from documentation, estimates, and assumptions about a legacy codebase that hasn't moved in years. That's not a plan; it's a guess with a contract attached.

The programs that go sideways usually don’t fail because the technology was wrong. They fail because the commitment was made before the system had a chance to reveal what it actually contained.

What Early Work is Really For

Sequencing early modules based on business value sounds right. Highest-priority capabilities first. Demonstrate value quickly. The problem is that early modules do something more important than deliver features: they produce the inputs every subsequent estimate depends on. 

Before you've migrated a single batch job, you don't know what your pipeline costs to run at real scale. You don't know how fast the team moves once the initial friction is resolved. You don't know whether the security model holds up under actual conditions or where the complexity is concentrated versus where the documentation says it is. Those aren't technical details; they are the numbers your budget and timeline are built on. 

A simple UI component does the same thing on the front end. Framework selection, component design patterns, and the mapping of legacy screens to the new system: every subsequent UI module inherits those decisions. Work them out on something low-stakes, and they're behind you before the high-stakes work starts. Discover them mid-program on a customer-critical workflow, and they become a scope conversation nobody wants to have.

The Case for a PoC Before the Commitment

We recommend structuring the start of any modernization engagement around a proof of concept before locking scope and budget for the full program. A well-designed PoC is a targeted exercise against a real slice of the system, specifically designed to answer the questions a multi-year commitment depends on: What does this pipeline actually cost at scale? What does team velocity look like with the real codebase? Where are the complexity concentrations that no diagram captured? 

A PoC that answers those questions doesn't delay the program; it creates the conditions for a commitment that holds. Signing a large SOW based on projections means discovery happens mid-program, when it is most expensive to respond.

When the Pressure Is to Start With the Hardest Work

The pushback we hear most often: why not begin with the most complex components to prove the approach works? Clients have seen programs build momentum on simpler work and then stall when they hit the complex core. Starting at the edges can look like deferring the real problem. 

The evidence consistently supports the opposite. 

On a recent e-commerce modernization for a global QSR brand, we pushed for a 4-week PoC before any larger commitment. The goal was the simplest possible real transaction on the platform: built, deployed to production, and executable by client stakeholders against real infrastructure within four weeks. 

It wasn't a deferral of complexity; it was a measurement instrument. We got actual team velocity against the real codebase. The proposed architecture held up under production conditions. Integration dependencies and organizational bottlenecks surfaced that no planning exercise would have caught. And the business had something to see and evaluate, so confidence in the program started building from week four, not month eighteen. 

By the time the team scaled into more complex areas of the platform, the pipeline was proven, and velocity was a known quantity. That engagement became one of CI&T's largest client relationships, expanding scope as the client's confidence in the approach grew.

How We Make Sequencing Decisions

The criteria we use to prioritize early work: Does this module introduce a problem type we haven't solved in this program yet? Will what we learn here apply across multiple modules that follow? What's the cost of not learning this now? 

High novelty and high transferability at manageable effort: that's the profile we look for in early candidates. When a module also carries real business value, the sequencing decision is easy to defend internally and to leadership. Complex modules that only answer questions about themselves belong later, once the process is validated and real data exists to support the estimates. 

The reason this matters for clients isn't the framework. It's that programs structured this way arrive at the hard work with evidence rather than assumptions, and the hard work goes faster for it.

---