Application maintenance and support services
Including software we did not build. Takeover is a defined process, not an act of faith.
Application maintenance and support means keeping working software working: fixing defects, applying security updates, making changes as the business moves, and responding fast when something breaks. AMT (Advanced Millennium Technologies) provides maintenance and support for systems we built and systems we inherited, under ISO 9001:2015 and ISO 27001:2022.
Trusted by
// new_support_partner
When companies look for a new support partner
- The current vendor has become slow to respond or too expensive.
- The one person who understood the system has resigned.
- A system inherited through an acquisition turns out to be nobody's job.
All three are recoverable. How painful and costly it is depends on how much of the system's knowledge exists outside someone's head.
// takeover_checklist
Software takeover checklist: what we need to support your system
| What we need | Why it matters | If it is missing |
|---|---|---|
| Source code with full history | The history explains why things are the way they are. | Code without history is archaeology. Add weeks to takeover. |
| An environment we can rebuild | If it only runs on one machine someone set up in 2019, that is the first thing to fix. | The most common gap and the biggest single cost in a takeover. |
| Production access with an audit trail | We cannot support what we cannot see. | Everything waits for security sign-off. |
| The deployment path | How a change actually reaches production today, including the manual step nobody wrote down. | Assume there is a manual step, and that it belongs to one person. |
| Known defects and workarounds | The things everyone has learned to live with. | You discover them one at a time, each as a surprise incident. |
| Existing monitoring | And whether anyone watches it. | The first month goes on building visibility instead of fixing things. |
| Two hours with the outgoing developer | Worth more than any document. | When impossible, discovery roughly doubles. |
Get the handover checklist
Seven things any incoming support partner needs, with what each gap costs you. Send it to whoever holds the system today, ideally before they leave.
// takeover_timeline
Takeover timeline
| Weeks | What happens |
|---|---|
| 1 to 2 | Access, code and environment review against the checklist. You get a written list of gaps and risks. |
| 3 to 4 | Rebuildable environments, monitoring and alerting, and the deployment path documented. |
| 5 to 8 | Shadow support alongside the current team, then full responsibility once incidents are handled cleanly. |
Four to eight weeks to a safe, steady state is typical. Missing checklist items and slow production access stretch it.
// support_levels
Support levels: L1, L2 and L3
| Level | What it covers |
|---|---|
| L1 | Taking requests, answering how-to questions, triage and routing. |
| L2 | Configuration, data fixes, log analysis and known-issue workarounds. |
| L3 | Code-level fixes, root cause analysis, hot fixes and patches. |
// severity_targets
Response and resolution targets by severity
| Severity | Example | Response target | Resolution target |
|---|---|---|---|
| P1 Critical | System down or data at risk | Agreed in the SLA | Agreed in the SLA |
| P2 High | A core feature broken for many users | Agreed in the SLA | Agreed in the SLA |
| P3 Medium | A feature broken with a workaround | Agreed in the SLA | Agreed in the SLA |
| P4 Low | Cosmetic issues and small requests | Agreed in the SLA | Next planned release |
Targets are set with you, not copied from a template. A realistic target is worth more than an impressive one nobody can hit.
// maintenance_types
The four types of software maintenance we cover
| Type | What it means |
|---|---|
| Corrective | Fixing defects found in use. |
| Adaptive | Keeping the system working as operating systems, browsers, APIs and regulations change. |
| Perfective | Small improvements and new features as the business moves. |
| Preventive | Security patching, dependency updates and refactoring before problems surface. |
// proof
Proof
Long-running support. AMT built a multi-tenant, multilingual legal aid platform for an international humanitarian NGO and has supported it under an SLA for more than six years, with the engagement still running. The work covers SLA-based issue resolution, production support, corrective maintenance, dependency updates and ongoing enhancements as the organisation's needs change.
// maintenance_cost
Application maintenance cost
A useful planning figure: budget 15 to 20% of the original build cost per year for a system in active use. Less for something stable, more for something evolving or carrying technical debt.
| Scope | Pricing model | What drives the effort |
|---|---|---|
| Takeover and stabilisation | One-off | How many items on the checklist are missing. |
| Ongoing support | Monthly | System size, how critical it is, and the response targets you need. |
| Typical budget range | Generally 20% of the implementation cost per year | System size, the response times you need and how much changes each year. |
// not_right_fit
When we are not the right fit
// faqs
FAQs: application maintenance and support
What is the difference between application support and maintenance?
What are the four types of software maintenance?
What do L1, L2 and L3 support mean?
Will you support software you did not build?
How long does a software takeover take?
How much does application maintenance cost?
Can you support and modernise the system at the same time?
Tell us what you have inherited
30 minutes with an engineer. Describe the system and who supports it now, and we will tell you what a safe takeover involves and roughly what it costs.
Not ready to talk? Read how we deliver. No form.