At a glance
Scope: One existing application: source, database, configuration, logs, and the architecture around it
Method: Static, remote, read-only. The application is not run; nothing in production is touched
Effort: Fixed, not-to-exceed hour budget stated in the quote; hours reported weekly
Duration: Typically two to four weeks, part-time, gated by how fast intake materials arrive
Fee: Quoted after the free 1-hour consultation and creditable toward a subsequent modernization project
U.S. delivery: 100% U.S. citizen workforce, U.S.-soil delivery
What to know before you modernize
Who it is for, and who it is not for
The assessment is a decision instrument: it exists so that a rewrite, a migration, or a decision to leave the system alone rests on verified facts rather than on recollection. It fits some situations well and is the wrong purchase in others.
- An application the business depends on and cannot fully describe
An existing application that is still in production, still changing, or about to change hands, and whose behavior is known mostly through use rather than through documentation. The output is a written description of what the system actually is, tied to the code and the schema, so that the next decision starts from facts. - A decision about to be made on assumptions, or a proposal that needs a second opinion
When a budget, a vendor, or a target architecture is about to be committed, the assessment tests the assumptions behind it against the source, the database, and the logs first. The report is vendor-neutral: it can check a proposal from another firm or confirm an internal plan, and its reasoning is written so that a third party can audit it. - Not a fix, a feature, or a substitute for the consultation
The assessment is read-only. It does not repair a defect, add a feature, run the application, or change anything in production. It is not a substitute for the free consultation either: if one call answers the question, we say so and stop there.
Four blocks of work
The engagement runs in four blocks, in order. Each block produces written output that feeds the next, and the hour budget is allocated across them in the statement of work.
- Discovery
A structural inventory of the application as it exists: modules and dependencies, concurrency points, embedded data access, third-party components with license and source status, resource lifecycles, build configuration and compiler version, and a schema review. Known problems are traced by reading the code, not by running it, and every fact is recorded with where it was found. - Root-cause analysis
Each reported problem becomes a hypothesis, and each hypothesis is tested against the code and the logs until it is confirmed, refuted, or marked unresolved. Findings are written with a severity and the evidence that supports them, and each one passes a bias check before it is written up. - Architecture sketch
A target architecture at the level of detail a decision needs: where CQRS and event sourcing apply and where they do not, the integration layer, the database path, hosting, and a cutover approach with a parallel run and a rollback. Knowledge transfer is planned inside the sketch, not added at the end. - Synthesis and report
An executive summary, the findings with severity and evidence, a roadmap, the risk register, and a recommended next step, delivered as a written report and walked through on a call. A separate proposal for that next step follows, and it can be declined.
How we work
These conduct rules apply to every assessment and are written down so that they can be held against us.
- Remote, read-only, static first
The work is done from source, schema, configuration, and logs, with the application not running. Nothing in a production environment is executed, changed, or connected to. A written access record lists what was requested, received, and returned or destroyed, and it ships with the report. - A fixed hour budget and a weekly status
The statement of work states a not-to-exceed hour budget. Hours used are reported every Friday with what was done, what comes next, and what is blocked, so the budget is never a surprise at the end. If a block needs more than planned, the trade-off is raised in writing before the hours are spent. - No manufactured urgency, no invented ROI, and a bias check on every finding
The report contains no return-on-investment figure the evidence cannot support and no deadline the facts do not justify. Before a finding is written up it is tested against the opposite conclusion: what evidence would make it wrong, and whether that evidence was looked for. Findings that fail the check are downgraded or dropped. - Provenance marks and a corrections log
Every fact in the inventory carries a mark: [V] verified in code or data, [R] reported to us and not yet verified, [I] inferred from surrounding evidence, or [?] unknown. Anything reclassified during the engagement is entered in a corrections log that ships with the report, so the reader can see what changed and why.
What we need from you
Most of the intake is confirmation rather than authorship: we send a written list, you confirm what you can, and everything else is marked reported or unknown until the evidence settles it.
- Facts to confirm, not to write
The intake list asks only for what already exists and can be confirmed in a sentence: language and compiler version, database engine and version, where the application runs, who depends on it, and what is known to be wrong. Anything unknown is marked unknown until the review resolves it. - The artifacts
The full project tree as it builds today; the database DDL including keys, indexes, constraints, stored procedures, views, and triggers; a sanitized data sample; crash and event logs; failure examples with timestamps; and the current bug list. Each artifact is entered in the access record when it arrives. - Nice to have
Architecture diagrams, design documents, runbooks, and deployment notes, at whatever age and accuracy they exist. Out-of-date documents are still useful: the gap between what they describe and what the code does is itself a finding, and it is recorded as one. - Logistics settled in writing first
Before any artifact moves, the statement of work fixes the transfer method, where the material is held, who may see it, and when it is returned or destroyed. The controls on the Compliance page apply. No third-party AI tooling trained on client code without written consent.
Where it fits
The engagement ladder has three steps, and any step can be the last one.
- Step 1: the free 1-hour consultation
One call, no form. We listen, ask what the system does and what is being decided, and give a preliminary view in writing. If the call answers the question, the ladder stops there. If the system warrants a review, the assessment is scoped and quoted on that call. - Step 2: the assessment
A fixed-scope, read-only review that ends in a written report and a recommendation. The report is yours whether or not anything follows. Sometimes the recommendation is to leave the system alone, or to contain it and look again later, and the report says so in those words. - Step 3: the modernization project
If the recommendation is to upgrade, bridge, or migrate, a separate proposal follows with a fixed price and a phasing plan. The assessment fee is creditable toward that project. The proposal can be declined, and the report keeps its value with any vendor you choose.
Deliverables
- Findings with severity and evidence
- Verified system-facts inventory with provenance marks
- Risk register and corrections log
- Architecture sketch
- Written recommendation: upgrade, bridge, migrate, or leave it alone
- Walkthrough call and a separate proposal, yours to accept or decline
Common questions
What does a Legacy Software Assessment cost?
A fixed fee, quoted after the free 1-hour consultation once the scope is known. The statement of work states the scope and a not-to-exceed hour budget, and the fee is creditable toward a subsequent modernization project.
How long does a legacy system assessment take?
Typically two to four weeks of elapsed time, part-time, gated by how fast the intake materials arrive. The hour budget is fixed in the statement of work, and hours used are reported weekly.
Do you run our application or touch production?
No. The review is static and read-only: source, schema, configuration, and logs are read, nothing is executed against a production environment, and nothing is changed. A written access record delivered with the report lists everything that was received and returned.
What happens if you find nothing serious?
The report says so. You keep the verified system-facts inventory, the risk register, and the written recommendation, which in that case is to leave the system alone or to contain it. A report that ends in no project is a legitimate outcome, and we do not manufacture one.
Is the assessment fee really creditable toward a project?
Yes, toward a modernization project signed within 12 months of the report date. The terms are stated in the statement of work, which governs, and the credit is restated in the project proposal so it can be checked.
Can our engineers be involved?
Expected. You name a technical contact who receives the weekly status, answers confirmation questions, and reviews the draft before the final report. The report includes a knowledge-transfer section written for that person, so the findings can be acted on without us.
What happens to our source code?
How it is transferred, where it is held, who may see it, and when it is returned or destroyed are agreed in writing before anything moves, and the controls on the Compliance page apply. No third-party AI tooling trained on client code without written consent. Material is returned or destroyed on request.
Should the firm that assesses the system also modernize it?
Not necessarily, and the report is written so that it does not have to be. It is vendor-neutral and yours to use with anyone. The credit removes the incentive to pad the assessment to sell a project, and if the right answer is another vendor, or no project at all, the report says so.
Related
When not to modernize: The test applied before any project, and the case for leaving a system alone.
Rewrite vs strangler fig: How the sequencing decision is made once the assessment says move.
How we run Event Storming: Where the domain model and the seams come from.