Should You Modernise Before Adopting AI? The Sequencing Debate

The sequencing debate inside enterprise IT organisations goes like this. The modernisation camp says: our applications are not ready for AI, so we must modernise first. The AI-first camp says: AI adoption creates the business case that funds modernisation, so adopt AI first. Both camps have organisations to point to as evidence. Both camps are also describing the minority of situations they understand best.

Where the modernise-first argument breaks down

Full application modernisation programmes at enterprise scale take three to five years and have a historical success rate that generously described ranges from 30 to 50 percent. Waiting for modernisation to complete before adopting AI means waiting until 2029 or 2030 for organisations that start today — in a technology cycle where meaningful capability shifts are happening annually.

More precisely, the modernise-first argument treats modernisation as a binary — either the application is modern or it is not. Application readiness for agentic AI is a gradient. The question should not be "is this application modern?" but "which dimensions of this application are ready today, and what is the minimum viable remediation to unlock an initial agentic capability?"

Where the AI-first argument breaks down

AI-first adoption without readiness assessment produces impressive pilots and failed production deployments. The pilot works because it is scoped carefully, runs against curated data, and is staffed by motivated engineers who know where the bodies are buried. The production deployment hits the structural issues — the API that does not exist, the data that is locked in a legacy schema, the deployment process that cannot support rapid iteration — and stalls.

The business case generated by the pilot funds a project that cannot deliver, which damages both the AI programme and the modernisation programme that should have been running alongside it.

The sequencing logic that works

The correct sequencing starts with a portfolio-level readiness assessment — not a single application, but all material applications in the portfolio scored simultaneously. The assessment produces a heatmap of readiness across the portfolio. From this heatmap, three categories emerge:

• Deploy now — applications in the Ready or Accelerate tier that can receive agentic capabilities within the current architecture. These generate early value and fund the programme.
• Remediate and deploy — applications in the Emerging tier where targeted investment in one or two dimensions unlocks agentic capability within 3 to 6 months. These are the second wave.
• Modernise in parallel — applications in the Not Ready tier that require fundamental structural change. These run on a longer track, typically 12 to 24 months, and are not blocked on AI adoption in the first two categories.

The key insight is that most enterprise portfolios contain applications in all three categories. The Accelerate-tier applications are almost always present and almost always underutilised from an AI perspective. Starting there generates the early value that funds remediation work in the Emerging tier, without waiting for the full modernisation of the Not Ready applications.

The portfolio heatmap as a planning instrument

The MRS heatmap produced by a NextAI Foundry assessment is not an end-state document. It is the starting point for a sequenced investment plan. Each application's position on the heatmap drives a different investment conversation: deploy, remediate, or modernise. The heatmap also surfaces cross-cutting patterns — if ten applications all score low on the Data dimension, that suggests a shared data governance issue that should be addressed once, not ten times application by application.

A practical starting point

If you have a portfolio of 20 or more material applications and are trying to decide where to start with agentic AI adoption, the single highest-leverage action is to run a structured assessment across the portfolio. Not a workshop, not a vendor briefing — a scored, evidence-based readiness evaluation that produces a prioritised list of applications by readiness tier.

That list is the sequencing plan. It answers the modernise-first versus AI-first debate with data rather than ideology.

When to break the rule and modernise first

There is one situation where modernise-first is genuinely the correct sequencing: when the application in question is a system of record for a regulated business process, has no API surface whatsoever, and sits in the critical path of a business function that cannot tolerate experimental failure. In this narrow case, attempting agentic augmentation before the architecture is stable creates regulatory and operational risk that exceeds the cost of the delay.

But this situation is rarer than the modernise-first camp acknowledges. Most "we must modernise first" arguments, on examination, apply to one or two applications in a portfolio of twenty or more. The correct response is to modernise those specific applications while deploying AI against the applications that do not share those constraints — not to hold the entire AI programme hostage to the remediation timeline of the most complex systems.

Cross-cutting patterns that appear in low-scoring portfolios

Portfolio assessments consistently surface the same cross-cutting gaps. The most common is data dimension weakness across applications that were built by different teams but draw from the same underlying enterprise data warehouse. Each application has its own downstream copy of the data, each copy is slightly stale, and none of the copies has authoritative write-back capability. Fixing this once — at the data governance layer — unlocks AI readiness across the entire affected portfolio, not just the specific application being remediated.

The second most common cross-cutting gap is team dimension weakness driven by deployment process constraints shared across an application estate. When a central release management team controls deployment windows for multiple applications, no individual application team can achieve the deployment frequency that agentic iteration requires. The fix is a DevOps transformation programme — which benefits every application in scope, not just the ones targeted for AI augmentation.

These cross-cutting patterns are visible only when you assess the portfolio together. They are invisible when you assess applications one at a time. The investment in a portfolio-level assessment pays for itself in avoided redundant remediation work.

How to identify your deploy-now applications in a single afternoon

Without a full formal assessment, there is a rapid triage that works. Gather the application owners for your ten most business-critical systems. Ask three questions about each: Does the application have a versioned REST or GraphQL API that external systems call today? Can a non-production engineer read and write to the application's data store directly, without going through a UI? Did the application's team ship to production more than once in the past month? Applications that answer yes to all three are almost always in the Emerging or Ready tier and can receive an initial agentic capability within three months.