Key takeaways
Speed raised the stakes on assessment, it did not remove them. When delivery is 30 to 50% faster, a project built on wrong assumptions just reaches the wall faster.
Large IT projects run 45% over budget and deliver 56% less value than predicted, and 17% become "black swans" with overruns above 200% (McKinsey and Oxford).
You inherit what you did not measure. US technical debt alone is estimated at ~$1.52 trillion, part of a $2.41 trillion cost of poor software quality (CISQ). A modernization that skips assessment carries that debt unpriced.
~30% of generative AI projects are abandoned after proof of concept (Gartner), most often for gaps an AI-readiness assessment would have surfaced first.
The failure is rarely the technology. It is undocumented dependencies, unmodeled costs, and no one owning the outcome.
What is an assessment, and why does it matter more now?
An assessment is the current-state review you run before you commit: a discovery of your systems, a baseline of technical debt, a dependency map, an AI-readiness check, a cost baseline, and an honest look at who will own delivery. It is the pre-flight check for a high-stakes initiative.
For years, assessment was easy to defend because everything was slow, so nobody argued with two weeks of planning ahead of a two-year program. Today the pressure runs the other way. AI-accelerated delivery can stand up working code 30 to 50% faster than a traditional team, and that speed makes the assessment feel like the slow, optional part. So it gets cut.
Here is what that misses. When everyone can build fast, speed stops being the differentiator and becomes table stakes. What separates a project that lands from one that overruns is no longer how fast you move, it is whether you knew what you were building on before you started. Faster delivery on a wrong baseline does not save the project, it reaches the failure sooner. Assessment is how speed gets pointed in the right direction.
The mistakes: how companies skip the assessment
The pattern is consistent enough to name, and most teams recognize themselves in at least two of these.
Jumping straight to build. The mandate is "move 200 apps to the cloud" or "ship an AI assistant," so work starts before anyone decides which apps should move, be replaced, or be retired, or whether the data is ready.
Trusting the vendor estimate. The number in the proposal was built on an org chart, not a dependency map. It holds until month 6, when the real system shows up.
Underestimating legacy integration. The 20-year-old system "just needs re-platforming," until an undocumented dependency to three other systems surfaces.
No baseline of technical debt or cost. You cannot modernize what you have not measured, and you cannot hold a vendor to a number you never established.
Confusing a pilot with a plan. The demo worked on clean data with a friendly user. That is not evidence it will survive production volume, real data, and compliance.
Unclear ownership. Everyone is accountable for the initiative, which means no one is accountable for the outcome.
What does skipping the assessment actually cost?
This is the part that gets left out of the business case. The cost of the shortcut is documented, large, and specific.
Projects overrun because the plan was built on assumptions
The McKinsey and Oxford study of more than 5,400 IT projects remains the most cited number in this category. On average, large IT projects run 45% over budget, 7% over schedule, and deliver 56% less value than predicted, and 17% run so far over that they threaten the business itself, with overruns above 200%.
So what? A budget that reads $15 million on the slide is a $22 million project on the actuals, delivering a little over half of what was promised. That gap is not bad luck. It is the compounding cost of decisions made before anyone knew the real state of the systems.
You inherit the technical debt you never measured
The Consortium for Information and Software Quality put the cost of poor software quality in the US at at least $2.41 trillion, of which roughly $1.52 trillion is accumulated technical debt. That debt does not disappear when you modernize. Lift-and-shift moves it to the cloud, where you pay for modern infrastructure while still carrying the legacy design for years.
A technical-debt baseline exists to price that liability before you inherit it, so the plan accounts for it instead of discovering it in production.
Failed AI pilots are assessment failures with a different label
Gartner reported that at least 30% of generative AI projects would be abandoned after proof of concept, with the leading causes being poor data quality, inadequate risk controls, escalating costs, and unclear business value. Every one of those is a readiness question an assessment answers before the build, not after the write-off.
The demo works. Then the pilot meets real data, real integration, and real compliance, and quietly never reaches production. The organizations that convert pilots into production are the ones that did the readiness work first.
In migration, the overrun has hard numbers
For cloud migration specifically, roughly 75% of enterprise migrations run over budget and 37% finish behind schedule, and a large share of failures trace to dependency conflicts that were never documented. The overruns almost always come back to the same unassessed items: undocumented dependencies, double-run costs during overlap, and validation work that was never in the plan.
The contrast: skip-the-assessment vs. assessed delivery
Speed made the assessment feel optional. It is the opposite. The faster you can build, the more it matters that you are building the right thing, on a real baseline, with someone on the hook for the result.
Goal is "move to the cloud" or "add AI"
A defined business outcome, per application or use case
Vendor estimate taken on trust
A technical-debt and dependency baseline before a number is quoted
Legacy complexity discovered in month 6
Dependencies mapped in month 1
Lift-and-shift by default
Keep, replace, or retire decided per application
Data assumed ready
Data quality, access, and compliance verified first
Whoever is free runs it alongside their day job
A dedicated team that cannot be crowded out by operations
The vendor is on the hook for hours
The partner is on the hook for the outcome
The right-hand column is not slower. It is two weeks of discovery that removes the month-6 surprise. The difference is where the cost lands: a small, planned cost up front, or a large, unplanned one halfway through.
The pre-assessment checklist: what to gather before you commit
Most of a good assessment is deciding what to collect and being honest about what you find. Use this to gather the inputs before you sign a vendor or fund a build. If you cannot fill in a section, that gap is itself a finding.
Application and portfolio inventory
A list of the applications in scope, each with a business owner and a criticality rating.
For each one, the intended move: keep, re-platform, replace, or retire, and why.
Age, language, framework, and whether the original builders are still reachable.
Dependency and integration map
Every upstream and downstream system each application talks to, including the undocumented ones.
Data flows in and out, with formats, volumes, and timing.
Third-party and vendor integrations, licenses, and contract end dates.
Technical-debt baseline
Known defects, end-of-life components, and unsupported versions.
A code-quality and test-coverage read, so you know what carries risk.
Manual workarounds and "do not touch" areas nobody wants to own.
Data readiness
Where the data lives, who owns it, and who can grant access.
Quality, completeness, and how many conflicting versions of the truth exist.
Sensitivity, residency, and the compliance rules that constrain its use.
Cost and run-rate baseline
Current infrastructure, licensing, and support spend for each system.
The expected double-run cost during any migration overlap.
For AI in scope, an estimate of production run cost, not just pilot cost. See the companion guide on why AI inference bills keep growing.
AI and modernization readiness
The specific business outcome each initiative is meant to produce, stated as a number.
Whether the data, integration, and risk controls needed actually exist yet.
How a pilot would be validated against real data, real volume, and real compliance.
Security, compliance, and risk
Regulatory and audit requirements that touch the systems in scope.
Access controls, secrets, and audit trails that must be preserved.
The rollback and continuity plan if a cutover goes wrong.
Ownership and success criteria
One named owner accountable for the outcome, not just the activity.
The metrics that define success, agreed before work starts.
Who signs off at each stage, and what "done" means for each application.
What we see in the field
Across our migration and modernization pods, the estimate a client walks in with was almost always built on an org chart, not a dependency map. The first two weeks of discovery routinely surface a "simple" legacy application that feeds three downstream systems nobody had documented, and a "straightforward re-platform" that is actually a replace decision.
On one regional bank engagement, the assumption was a clean re-platform of a 20-year-old monolith. The assessment found the dependencies first, so the plan reflected them from day one. The result was a release cycle that went from 10 weeks to 2, production defects down 45%, and infrastructure cost down 30%. Across our migration work the pattern holds: 300+ applications migrated, infrastructure cost down 35%, unplanned downtime down 60%. None of that came from moving faster. It came from knowing what was being moved before it moved.
Executive takeaway
Run the decision through the three things you translate everything into.
Two weeks of assessment up front removes the month-6 rediscovery that resets the schedule. You spend days to save quarters.
The assessment is a small, known cost. The alternative is the 45% overrun and the technical debt you inherit blind. Spending more later does not fix a plan that was wrong at the start.
This is the one that matters most at your level. An assessment is how you know the initiative is safe to back before you put your name on it. It converts "we think this will work" into "we measured it, and here is the plan for what we found."
AI made delivery fast. It did not make it accountable. The assessment is where accountability starts, because it is where you establish the baseline someone can actually own.
Frequently asked questions
Why do companies need an assessment before a modernization or AI project?
Because the cost and risk drivers are set before the build, not during it. An assessment surfaces undocumented dependencies, unmeasured technical debt, data-readiness gaps, and unclear ownership while they are still cheap to fix. Large IT projects run 45% over budget on average (McKinsey and Oxford), and the overruns trace to exactly what an assessment would have found.
What does an assessment include?
A current-state review: an application and portfolio inventory, a dependency and integration map, a technical-debt baseline, a data-readiness check, a cost baseline, an AI and modernization readiness check, a security and compliance review, and a decision on who owns delivery.
How long does an assessment take?
For most enterprise modernization and migration efforts, a focused discovery runs in weeks, not months, and it is the input that makes the twelve-month delivery predictable.
Why do AI pilots fail to reach production?
Poor data quality, unclear business value, inadequate risk controls, and legacy-integration complexity. Around 30% of generative AI projects are abandoned after proof of concept (Gartner). An AI-readiness assessment answers those questions before the build.
Run the pre-flight check before you sign
If you are weighing a migration, modernization, or AI initiative, the fastest way to see where your plan is exposed is our Cloud Migration Readiness Scorecard: the checks to run before you sign a vendor, no form. The low scores are where the overruns come from.
If you want a second set of eyes on a specific initiative, a 20-minute readiness review gets you a whiteboard read on where the risk sits and what a plan that accounts for it looks like. No obligation.
The assessment decides what moves and how. The two companion guides cover what happens when it is skipped: The Lift-and-Shift Trap on rehosting everything by default, and Anatomy of a Stalled Migration on the month 6 wall.
AI made modernization fast. NorthStar makes it accountable.
A vetted, dedicated pod that owns the outcome inside your legacy systems, without the Big-4 bill or the offshore babysitting.
By NorthStar Group.