Software maintenance services for critical Java applications
Ongoing maintenance, incident response and small improvements from engineers who understand your system. Agree the coverage, responsibilities and monthly budget before support begins.
Experience with systems built for sustained use
These projects demonstrate our platform engineering experience. Coverage and service levels for your application are agreed separately.
- Since 2013
- FastPost has run in production since then; we built and evolved it for Legerity for nearly ten years.FastPost case study
- 7%
- annual engineer attrition, so the people who learn your system stay on it.About Stratoflow
Stratoflow was instrumental in the completion of several projects of Tier 2. Other than developments, they also handled the technical support and maintenance of the applications. The team has been reliable, flexible and has displayed excellent technical capabilities in the workplace.
- Starting point
- Onboarding, scoped in the written ballpark after the scoping call.
- Coverage
- Business-hours or critical-system coverage, agreed in the support contract.
- Term
- Six-month minimum, then monthly with 60 days notice.
- Commercial model
- Monthly retainer based on the systems covered, the coverage hours and the change budget.
Keep maintenance connected to the way your system runs
Monitoring and incident response
Review logs, metrics and alerts, establish escalation paths and maintain runbooks. Investigate incidents within the agreed coverage and record follow-up actions.
Security and dependency maintenance
Triage vulnerability findings, assess exposure and plan patches or mitigations. Test available updates against the application before release.
Runtime and framework upgrades
Track support status across Java, frameworks and libraries. Plan routine updates and identify larger migrations that need their own implementation scope.
Small changes and operational reporting
Reserve an agreed engineering budget for fixes and minor improvements. Report incidents, maintenance and budget use every week, with a monthly summary and a quarterly review of risks and priorities.
Establish responsibility before taking over support
Discuss the systems
Identify the systems, business impact, current support arrangements and required coverage. A written ballpark for onboarding and support follows within a week.
Onboard the application
Usually allow two to three weeks to review architecture, dependencies, deployment and observability. You receive findings, risks and a proposed support scope.
Agree the support contract
Define systems covered, coverage hours, incident priorities, response and restoration targets, maintenance responsibilities and the change budget. Confirm the monthly fee after onboarding.
Handover and review
Prepare access, runbooks, monitoring and escalation contacts with the outgoing team where available. Start support when readiness is agreed, then review progress and remaining risks.
A support agreement built around your application
Onboarding is billed time and materials against the written ballpark. It establishes what can be supported, what needs remediation and the recurring fee. You keep its findings whether or not you continue with support.
The monthly retainer reflects the number of systems, their criticality, required coverage and the engineering days reserved for small changes. Business-hours coverage and a 24-hour on-call arrangement have different staffing requirements; availability and terms are confirmed in the proposal.
The contract distinguishes response from restoration and defines how incident priority, coverage hours and external dependencies affect targets. It also records escalation, reporting and any agreed service-credit terms. Changes beyond the included budget are discussed and priced before work proceeds.
Before we start
Can you support an application another vendor built?
Yes. We first establish access to code, environments and deployment tooling. Gaps in documentation or knowledge become onboarding findings and may affect the handover plan.
What if the system uses unsupported Java or libraries?
Onboarding identifies unsupported components and the risk they create. We agree interim measures and an upgrade plan; larger migrations may need a separate modernization project.
How quickly are security issues addressed?
Priorities and response targets are agreed in the contract. We assess exposure and available mitigations, then test and deploy patches when suitable releases are available. Findings that cannot yet be resolved remain visible in the maintenance plan.
What counts as a small change?
A change that fits the agreed engineering budget and support scope, such as a report adjustment or integration fix. Work involving substantial design changes is estimated and agreed separately.
How does the engagement end?
The initial term is six months, followed by monthly support with 60 days notice. Handover responsibilities, documentation and access changes are defined in the agreement so your next support team can take over.
What do your application support services cover?
Security patching and dependency upgrades, incident response in agreed hours, monitoring you can see, and a monthly budget for small changes. Our application support services and software maintenance run under one retainer with SLAs, so the engineers who fix an incident are the ones who know why the code is shaped the way it is.
When the application needs a larger change
Plan support for your Java application
Tell us which systems need support, who runs them today and the coverage your business needs.