Article
If you've never gone through a formal assessment before committing to modernization work, it can feel like an open-ended ask - "give us access to everything and trust the process." Here's exactly what happens, so there are no surprises.
What we're actually looking at
An assessment covers four things: the codebase itself (architecture, coupling, code quality, how much of it is actually understood versus inherited blind), the database (schema design, data volume, how tightly the business logic depends on specific database behavior), integrations (what other systems this one talks to, and what breaks if it changes), and the deployment and operations picture (how the system currently gets built, tested, and released).
What you need to provide
Access - to the codebase, to a representative copy of the data (not necessarily production data itself), and to whoever on your team has the most institutional knowledge of how the system actually behaves, even informally. That last part matters more than people expect. When we assessed a 10-year-old ASP.NET Forms point-of-sale system for a multi-restaurant client ahead of migration, the assessment's most important finding wasn't a specific bug - it was confirming that no meaningful documentation existed at all, and that the codebase was scattered with no defined architecture. That finding alone ruled out a big-bang rewrite and pointed toward a phased, database-first migration instead. You don't need documentation to go through an assessment. If you had it, you might not need the assessment in the first place.
What we're specifically trying to rule in or out
Whether a full rewrite is actually justified, or whether an incremental, phased approach preserves more value at lower risk. Which components are load-bearing enough that they need to move first and get the most validation, versus which are lower-risk and can move later. Whether the constraints are mostly technical (a tightly coupled architecture) or mostly informational (nobody currently at the company understands how a piece of it works) - because those two problems get solved differently.
What you walk away with
Not a sales pitch dressed up as an assessment - a specific, evidence-based picture of what's actually in your system, what the real risk concentrations are, and what a realistic phased approach would look like given what was found. For the retail POS project, that meant a clear sequencing decision: database migration first, then the service architecture, then the frontend, each stage validated against the live system in parallel before cutover. That sequencing wasn't a template - it was a direct consequence of what the assessment found about that specific system's constraints.
How long it actually takes
This depends on the size and documentation state of the system being assessed, and is one of the things we'll tell you honestly upfront rather than quoting a generic number - a system with reasonable documentation moves faster through assessment than one that's genuinely a black box to everyone currently on your team.
Why this step isn't skippable
Any timeline or cost estimate given before an assessment is a guess, not a commitment - because the actual cost and risk of a modernization project is driven by exactly the things an assessment uncovers: how coupled the architecture is, how much institutional knowledge is missing, and how much downtime tolerance you genuinely have. Skipping straight to a proposal skips the only step that makes the rest of the engagement honest.
If you're ready to see what an assessment would actually find in your system, that's the right next step.
Request a Legacy System Assessment