TL;DR
- Most modernization programs fail at sequencing, not execution.
- The right order is driven by business value, technical risk, dependency, and change absorption capacity.
- Parallel modernization programs produce less value than a serial one executed well.
- AI modernization is not a separate program — it is a capability layer that sits on top of the data and application layers. Sequence accordingly.
The pattern most enterprises get wrong
Enterprise modernization programs usually start with enthusiasm. The CIO announces cloud migration. The CDO announces data platform modernization. The Head of Platforms announces microservices rewrites. The CISO announces zero-trust. Separately, each announcement is reasonable. Collectively, they are a change-absorption disaster.
The organization has a finite capacity to absorb change at once. Engineering teams can only be in a state of active re-platforming on so much surface area. Business stakeholders can only adopt so many new tools, processes, and reporting surfaces in a quarter. Security teams can only run so many parallel assessments. Finance can only fund so many simultaneous transformations without losing budget discipline.
The programs that work pick a sequence and hold to it. The programs that fail try to do everything at once.
The four-axis framework
For a given workload (application, data platform, infrastructure layer, security program), the sequencing decision runs on four axes:
1. Business value of modernization
What does the organization gain when this workload is modernized? Cost savings (quantified), new capabilities enabled (listed specifically), risk reduced (measured), strategic option created. Workloads with weak business-value cases should not be modernized at all; they should be retired, or left alone.
2. Dependency position
What depends on this workload, and what does it depend on? Workloads that are dependencies for many downstream consumers (data platforms, identity systems, core financial systems) should modernize early — because every downstream modernization benefits from the upgraded base. Workloads with few downstream dependencies can modernize independently on their own timeline.
3. Technical risk
How confident is the organization that the modernization will execute cleanly? Workloads with high technical risk — legacy code with poor documentation, undocumented integrations, unusual custom logic — should modernize later, after the program has accumulated experience. Workloads with lower risk should go earlier to build confidence.
4. Change absorption
How much change can the business tolerate on this workload right now? A business domain in the middle of a regulatory change, an acquisition integration, or a leadership transition does not have the absorption capacity for a modernization on top. Even a technically straightforward modernization can fail if business absorption is low.
The sequencing that works
Combining the four axes:
Phase 1 — Foundation dependencies. Data platforms, identity and access management, core security posture. These are the dependencies everything else modernization relies on. Skipping this phase means every downstream modernization has to work around the same foundation gaps.
Phase 2 — High-value, low-risk workloads. Applications where the modernization payoff is clear and the technical risk is contained. Build the team's experience and executive confidence on these.
Phase 3 — High-value, high-risk workloads. The complex ones. Legacy monoliths. Regulated systems. Core financial systems. Do these once the team has experience and the foundation is in place.
Phase 4 — AI and agentic workloads. AI modernization runs on top of the data platform modernized in Phase 1 and the application modernization of Phases 2-3. Trying to build AI workflows before the underlying data and identity layers are modernized produces fragile AI that inherits the legacy system's problems.
Where AI fits (and where it does not)
A common mistake in 2026: treating AI as its own modernization program, parallel to the data and application programs. The result is AI workflows that struggle because the data is not AI-ready, the identity model is not AI-compatible, and the audit layer is not built for agent actions.
AI modernization is a capability layer. It sits on top of a modernized data platform (so retrieval works), a modernized identity system (so scoped tool access works), and a modernized audit infrastructure (so agent actions are traceable). The sequence matters: data and identity first, AI as a capability layer on top.
This does not mean delay AI until everything else is done. Scoped AI pilots can start immediately on the workloads where the dependencies are already modernized. But the broad AI-across-the-enterprise ambition should sequence after the foundation — or accept that the AI program will duplicate the foundation work on a per-workload basis, which is the expensive way.
The parallel-program trap
Most enterprises currently have 3-5 parallel modernization programs running. The math looks like this:
- Each program individually estimates 18-24 months to substantial completion.
- Running 5 in parallel does not finish in 18-24 months. It finishes in 30-48 months, because the parallel change load compounds.
- Running them sequentially in a 2-year-each cadence takes 10 years. Also wrong.
The pragmatic middle: 2-3 programs in active execution at a time, sequenced so the highest-dependency programs go earliest. Complete those before starting the next two. Accept that a workload might wait 18 months for its turn. That wait is cheaper than running the program now and executing badly.
The governance the sequencing needs
For this to work, the organization needs a portfolio governance function — an ERP-like view of what is modernizing when, what is waiting, and what the dependency chain looks like. Most enterprises do not have this function, which is why most enterprises have the parallel-program problem.
Standing up the governance is a week of work. The willingness to say "no" to well-funded stakeholders whose workloads are not in the current sequence is the hard part.
For the broader context on our modernization and data practices, see our Application Modernization service and the data platform decision insight.