Read what exists
We look at the source, documentation, data definitions and interfaces within the chosen boundary. We do not assume the documentation matches the implementation.
Application assessment
Understand one application before you change it.
Allow around three to four weeks. Harten examines the source, checks the important findings with your team and prepares an application account, a specification and a proposed plan where the evidence supports one.
Show us the application and what you need to decide. We’ll set out what we can cover, the timetable and the fee before work starts.
The first engagement
What happens when we start with one application.
The work has three parts. You can see what the source supports, where questions remain and what needs deciding before change begins.
Check the findings
We take the important behaviours and gaps to the people who know the application. Questions that the evidence cannot settle stay open.
Hand over usable work
You receive an account of the application, a specification for review, the open questions and a proposed modernisation plan where the evidence supports one.
The scope, outputs, fee and dates are set out before work starts. Three to four weeks is an estimate for a bounded application, not a promise that every system can be covered in that time. See a report sample.
When to engage
Start where uncertainty is costing you.
Three common reasons to begin with one application.
Understand the application
When behaviour, dependencies and operational knowledge are fragmented.
Evidence before investment
When architecture, supplier or funding decisions need a defensible basis.
Resolve programme uncertainty
When delivery has started but important assumptions remain unproven.
Before work begins
Scope is an engineering decision.
Language, data access, integration boundaries, evidence quality and review depth determine what can be established. Line count alone does not.
Agree the decision
What decision is blocked? Which application, capability and source version are in scope? What must the work explain, and what sits outside the boundary?
Agree the review
Name the technical and business reviewers. Establish the material behaviours to examine, the evidence needed to support acceptance and how unresolved questions will be handled.
Inputs
Agree the evidence available to the engagement.
Start with what already exists. Harten records what is missing and what those gaps prevent us from concluding.
- Identified source revision
- Database definitions
- Build and dependency information
- Available tests and documentation
- Interface contracts, configuration and operational records where relevant
- Target constraints and required outcomes for planning
Domain and operational reviewers provide context that source code cannot establish.
Engagement stages
Know what each stage delivers.
The written proposal identifies included outputs, review sessions, responsibilities, dependencies, timetable and fee. A later stage is not silently included in an earlier one.
Application understanding
An account of behaviour, business capabilities, data and interfaces within the agreed boundary, with source support and material evidence gaps.
Review outcome: a clearer application scope and the uncertainties that affect the proposed change.
Specification review
A current-system specification, source checks for agreed material findings, recorded corrections and a register of outstanding questions and decisions.
Review outcome: an agreed basis for what must be preserved or deliberately changed, with remaining limitations explicit.
Modernisation planning
A proposed target and change sequence, including dependencies, delivery slices, data transition, rollback, verification and responsibilities.
Review outcome: a plan that architects and delivery leads can assess before authorising implementation.
Selected report sample
Three findings from one application report.
This edited selection comes from Harten’s analysis of a public synthetic legacy example. The report records what the supplied material supports, what it leaves open and what must be checked before a replacement is designed.
Order release
Report finding: “Available stock weight is compared with order weight using a stated 2.50% tolerance.”
Still open: How the tolerance is calculated and rounded, how partial release differs from insufficient stock, and whether release changes stock.
Next decision: Confirm the rule and stock ownership before specifying replacement behaviour.
Report pp. 7–8 · [S0001] [S0003] [S0007]
Quality hold
Report finding: “an already-HELD order is rejected;” An eligible path changes the order to held and records hold information.
Still open: The full hold lifecycle, the transaction boundary and what happens if audit processing fails.
Next decision: Confirm the permitted states and audit contract before designing the new workflow.
Report p. 9 · [S0001] [S0003] [S0007]
Certificate enquiry
Report finding: “blank certificate input causes a re-prompt;” The supplied material also identifies a call to an external document generator.
Still open: Whether every successful lookup triggers generation, and the generator’s full request and response contract.
Next decision: Verify the interface and user action before replacing it.
Report pp. 10–11 · [S0001] [S0003] [S0018]
These are selected quotations and edited summaries from a 23-page report. The report is unapproved: source-derived observations do not prove runtime behaviour or approve a modernisation design. [S0001] refers to the supplied application overview, [S0003] to the supplied low-level design, [S0007] to open questions and [S0018] to an architecture review. The full source index and sensitive material are not part of this public sample. See other application examples.
Acceptance
Agree what makes the deliverable usable.
Acceptance criteria are recorded in the proposal before work begins. They cover the agreed application boundary, required outputs, material behaviours selected for source review and the decision the work must support.
Evidence integrity
The deliverable identifies its source baseline and coverage. Agreed material findings have inspectable support. Incorrect references, repetition that obscures meaning and conflicting interpretations are corrected before acceptance; they are not counted as application uncertainties.
Decisions and handover
Open application questions have an owner, consequence and next action. The named reviewers record acceptance, conditional acceptance or required rework. A plan also maps proposed changes to dependencies and verification requirements. Acceptance of these documents does not constitute acceptance of an implementation.
Responsibilities
A shared review with clear ownership.
- Harten: scopes the analysis, uses Wayfinder to assemble the outputs, checks agreed material findings, records limitations and leads the engineering review.
- Your organisation: provides authorised access to the agreed sources, identifies relevant domain and operational owners, and decides priorities and acceptable risk.
- Together: agree deliverable acceptance, the treatment of open questions and the next piece of work.
Commercial terms and handover
The work remains useful after the assessment.
Deliverables, rights, fees and delivery dates are set out before the work begins.
What you receive
The application account, relevant source references, reviewed findings and decision register. Where commissioned, this also includes the specification and modernisation plan in agreed handover formats.
What you can use
The proposal confirms your rights to use the deliverables. Harten retains its platform and method IP. Your team can use the agreed outputs in subsequent work, including with delivery partners.
What is separate
Fees and delivery dates follow the agreed scope. Production implementation, data migration, security certification and operational support are separately agreed where required.
Before analysis: source access and evidence handling are agreed privately. Start with an application description and the decision you face; do not send source code or credentials through the public contact address.