Application Review & Modernisation Strategy
An honest assessment of software already in service, followed by modernisation options ordered by priority, effort and risk. The purpose is to replace "it probably needs replacing" with a defensible plan.
The situation this service is built for
An application built some years ago still runs the business, or an important part of it. It works, mostly. But changes take longer than they should, new staff find it confusing, and the people who understand its internals have either moved on or would rather not touch certain areas.
Two instincts compete. One says replace it: start again and do it properly. The other says leave it alone: it works, and rewriting is how organisations lose two years. Both instincts are reasonable, and neither is evidence.
This engagement produces the evidence. It examines the application as it actually is, identifies what genuinely constrains the organisation, and separates the problems that must be addressed from the ones that are merely untidy.
The most common outcome is neither replacement nor inaction — it is a sequence of targeted improvements that removes the real constraints at a fraction of the cost of a rewrite.
Problems this service may address
- Changes take disproportionately longA small adjustment requires days of work, and nobody can explain why in terms a manager can act on.
- Key-person dependencyOne person understands the application, and the organisation's exposure if they leave has never been quantified.
- Replace-or-repair is unresolvedThe debate recurs at every budget round and is settled by whoever argues most persuasively rather than by analysis.
- Ageing componentsThe application depends on versions no longer supported, and the practical consequences have not been established.
- Integration is blockedConnecting the application to anything new appears impossible, but whether that is truly the case has not been tested.
- Users have stopped complainingStaff have built workarounds and no longer report problems, so the real cost has become invisible.
- Undocumented behaviourThe application does things nobody can explain, and each unexplained behaviour makes change riskier.
Review areas
Possible review areas
- Usability
- Maintainability
- Architecture
- Performance observations
- Technical debt
- Integration limitations
- Operational risks
- Upgrade priorities
- Phased modernisation options
Typically included in scope
- Structured walkthrough with usersObserving real tasks, including the workarounds people no longer think to mention.
- Code and structure reviewWhere source access is available: organisation, dependencies, patterns and areas of concentrated risk.
- Dependency and version assessmentWhat the application relies on, what is still supported, and what that means in practice.
- Operational reviewHosting, backups, deployment method and what would happen if something failed today.
- Prioritised findingsIssues ranked by business effect and effort, not by how untidy they look to a developer.
- Phased modernisation optionsRealistic routes including targeted improvement, staged replacement and full replacement, each with its trade-offs.
What is not automatically included
- Penetration testing or security certificationObservable security concerns are reported where visible, but no formal test, audit or certification is provided unless separately agreed.
- Performance load testingPerformance observations are qualitative. Formal load testing under simulated volume is separate specialist work.
- Line-by-line code auditThe review assesses structure and risk concentration. Exhaustive inspection of every file is a much larger engagement.
- The modernisation work itselfThis service produces the strategy. Implementing it is a development engagement, scoped and priced separately.
- Compliance assessmentWhether the application satisfies sector regulation must be determined by the client's own compliance advisers.
- Any guarantee about undiscovered issuesA review examines what is accessible in the time agreed. It cannot guarantee that nothing else exists.
Engagement process
Scoping and access arrangement
Establishing which application is in scope, what access can be provided — running system, source code, hosting information — and which questions the review must answer.
User observation
Watching people use the application for real work. The gap between the intended workflow and the actual one is frequently where the cost is concentrated.
Technical examination
Structure, dependencies, data model, deployment and operational arrangements — looking for concentrated risk rather than cataloguing every imperfection.
Finding prioritisation
Each finding assessed on business effect, likelihood and effort to address. Issues that offend a developer but cost the business nothing are marked as such.
Option development
Modernisation routes constructed — targeted improvement, staged replacement, full replacement — with indicative effort, sequence and the risk each one carries.
Report and walkthrough
The written review delivered with a session covering findings, options and the recommended first step, in language usable at management level.
Expected deliverables
- Review reportFindings across the agreed areas, each with its business effect stated rather than only its technical description.
- Prioritised issue listRanked by effect and effort, so the first three actions are obvious.
- Risk assessmentOperational exposure, including key-person dependency and what failure would currently mean.
- Modernisation optionsRealistic routes with indicative effort, sequence and trade-offs — including doing nothing for now.
- Phase plan for the recommended routeWork sequenced so each phase reduces real risk rather than deferring benefit to the end.
- Limitations statementWhat could not be examined and why, so the report's boundaries are explicit.
Client responsibilities
- Access to the running application, ideally in a test environment with realistic data
- Source code access where it exists and can be shared, along with any repository history
- Information about hosting, backups, deployment and any support arrangement in place
- Time with the people who use the application daily, not only with managers
- Access to whoever maintains it, where such a person exists
- Honest context: known problems, previous attempts to fix them and any commercial constraints
Factors that affect scope and price
Increase scope
- A large application with many modules and user types
- No documentation and no available original developer
- Several integrations requiring individual assessment
- An unfamiliar or obsolete technology requiring extra research
- Formal reporting for a board, insurer or funder
Keep scope lean
- A specific question — such as repair or replace — rather than a general assessment
- Source access and a knowledgeable contact available
- Reviewing the most problematic module rather than the whole application
- Accepting a concise report over a formal document pack
Pricing notice. All prices are indicative starting points. Final pricing depends on project scope, complexity, integrations, documentation, timescale and agreed deliverables. Applicable taxes and third-party costs are confirmed in the written proposal where relevant.
Follow-up options
Targeted improvement
Addressing the highest-priority findings within the existing application — frequently the best value outcome, and often far cheaper than expected.
Staged replacement
Replacing the application module by module while the original continues to run, so the business is never dependent on a single switch-over.
Planned retirement
Where replacement is genuinely necessary, a phased plan with data migration and a defined decommissioning point.
Questions about this service
Yes, though the technical depth is reduced. Usability, operational risk, integration limitations and observable behaviour can all be assessed from the running application.
The absence of source code is itself a significant finding, because it constrains every modernisation option. The report states plainly what could not be examined and how that affects the conclusions.
Only if the evidence supports it. Replacement is expensive, slow, and carries the risk of losing behaviour that nobody documented but everyone relies on.
The most common recommendation is targeted improvement: address the three or four things that genuinely constrain the organisation and leave the rest alone. Where replacement is warranted, the reasoning is set out explicitly so it can be challenged.
Observable concerns are reported — unsupported components, weak separation of access, or data handling that appears inappropriate for its sensitivity.
That is not a penetration test and not a security certification. Where formal assurance is required, an independent specialist assessment should be commissioned, and the report will say so rather than implying coverage it does not provide.
Yes, and that is a common reason for commissioning this service. The review assesses the software as it stands rather than judging the people who wrote it.
Findings are written factually. Context matters and is recorded: software built quickly under a tight budget five years ago is assessed against what it was asked to be, not against an ideal.
Minimally. Most of the work is examination rather than intervention, and the running system is not modified.
The main demand on the organisation is time: a few short observation sessions with people who use the application, and a conversation with whoever maintains it. Total involvement is usually a matter of hours rather than days.
Continue
Services that often follow this one
Service enquiry
Repair or replace? Answer it with evidence.
Describe the application, roughly when it was built, what it runs on if known, and what is currently causing difficulty. That is enough to scope a review.
- Telephone
- +44 7853 151 992
- support@devnovasolutions.tech
- Registered office
- 66 Paul Street, London, England, EC2A 4NA, United Kingdom