Understanding the Migration Readiness Score: How We Calculate MRS

The Migration Readiness Score (MRS) is the primary output of every NextAI Foundry assessment. It is a number between 0 and 100 that represents how ready a given application is to absorb agentic AI capabilities in its current state. This post explains what the score measures, how it is calculated, and how to read the tier thresholds correctly.

Why a composite score rather than a checklist

Early prototypes of the assessment produced a checklist: 47 yes/no questions mapped to a pass/fail outcome. Enterprise architects hated it. A single no on a critical dimension could block an otherwise strong application, while an application could game the checklist by satisfying every item without actually being deployable.

A weighted composite score reflects the reality that readiness is a gradient, that organisations can sequence remediation work across dimensions, and that strength in one area can partially offset weakness in another — within limits. The MRS was designed to be directional and actionable, not to be a binary gate.

The five dimensions

• Architecture (25%) — Service boundaries, API surface, modularity, and the degree to which business logic is separated from presentation and infrastructure concerns.
• Data (25%) — Data ownership clarity, schema quality, access latency, and the ability of the application to serve as a reliable data source for an AI agent operating at runtime.
• Integration (20%) — Existing API contracts, event streams, and the maturity of the application's integration patterns. Applications with published, versioned APIs score higher.
• Team (15%) — Deployment frequency, test coverage, observability maturity, and the team's prior exposure to AI or automation projects.
• Process (15%) — Business workflow documentation, human escalation paths, exception handling maturity, and the degree to which the application's decision logic is explicit rather than embedded in institutional knowledge.

Architecture and Data carry the highest weights because they are the hardest to change quickly and have the most direct impact on whether an agent can function at all. Team and Process carry lower weights because, while they matter, they can be developed in parallel with technical remediation on shorter timescales.

How Claude Sonnet scores each dimension

The 25-question assessment intake produces a rich text description of each application. Claude Sonnet analyses these answers against a structured rubric for each dimension, producing a score from 0 to 100 with a confidence level and a structured rationale. The rubric was developed from patterns observed across application portfolios and is versioned — we update it when expert review surfaces systematic calibration errors.

The AI does not simply keyword-match. It reasons about combinations. An application that describes a microservices architecture but also describes a single shared transactional database and no API versioning will score lower on Architecture than the microservices label alone would suggest. This is why the intake questions probe beyond technology choices into operational practice.

The four tiers

• Not Ready (0–39) — Fundamental blockers exist. Agentic augmentation requires significant preparatory investment before any agent deployment is advisable.
• Emerging (40–69) — Partial readiness. Narrow, well-scoped agent use cases are viable with mitigations. Full agentic capability requires targeted remediation across one or more dimensions.
• Ready (70–84) — Agentic augmentation is viable with standard risk management. Most agent patterns can be applied directly. Minor remediation may accelerate outcomes.
• Accelerate (85–100) — Strong readiness across all dimensions. The application is a strong candidate for advanced agentic patterns including multi-agent coordination and autonomous decision-making.

Limitations of the score

The MRS is based entirely on information provided in the intake form. It reflects the assessor's accurate description of the application. If the intake answers are aspirational rather than factual — describing the roadmap state rather than current state — the score will overstate readiness. We strongly recommend completing the assessment based on what exists today, using a separate section of the report to capture planned improvements.

The score also does not account for regulatory constraints, budget availability, or vendor lock-in — factors that may prevent technical remediation regardless of the score. These should be applied as a filter after reviewing the MRS output, not embedded in the score itself.

How dimension scores compound — and when a single low score is a veto

The weighted average means that a very low score on one dimension can be partially offset by strength elsewhere. In practice, however, certain dimension scores act as soft vetoes regardless of the composite. An Architecture score below 25 — indicating no meaningful API surface and monolithic business logic — makes the MRS composite unreliable as a deployment guide, because no amount of data quality or team capability allows an agent to interact with an application it cannot call.

The detailed report produced by NextAI Foundry flags these soft-veto conditions explicitly. When an Architecture or Data score falls below 30, the report includes a remediation prerequisite block that must be addressed before the composite MRS is used as a deployment decision input.

The most common intake mistake — and how to avoid it

The single most common source of score inflation is confusing planned state with current state. An architect who knows that a microservices migration is six months away will naturally describe the application in terms of where it is going, not where it is. The intake questions are designed to surface this: they ask about operational practice ("How many times did this team deploy to production last quarter?") rather than architectural intent ("What is your deployment target model?").

If you complete the assessment with a colleague who did not design the application, calibration improves significantly. The external perspective tends to describe current operational reality more accurately than the team that built the system and understands its intended architecture.

Using the MRS across a portfolio, not just per application

A single MRS is directional. A portfolio of MRS scores is a planning instrument. The heatmap view — showing dimension scores across all assessed applications — surfaces cross-cutting patterns that individual scores obscure. If twelve out of twenty applications score below 40 on the Data dimension, that is not twelve separate problems. That is one data governance problem manifesting in twelve places, and it should be addressed at the governance level rather than application by application.

This is why the assessment is designed to run across an entire portfolio in a single session, not as a one-application-at-a-time evaluation. The comparative view is where the strategic investment priorities become visible.