On this page
What application maintenance means
Every custom application is built on layers it does not control: a language runtime such as Node.js, PHP or Python, a framework such as Laravel, Django or Next.js, dozens or hundreds of third-party packages, a database, and external APIs. Each of those has its own release cycle and end-of-support dates. Application maintenance is the ongoing work of keeping your software current with those layers.
The goal is simple: at any point, you should be able to add a feature or fix a bug without first spending weeks untangling outdated dependencies.
Who needs it
Any business running software built specifically for it. A clinic with a custom booking and records system, a manufacturer with an internal order-tracking tool connected to its ERP, a real estate company with a listings portal, or a SaaS startup whose product is the application itself — all face the same slow drift if nobody keeps the foundations current.
Signs the drift has already started:
- Developers say a small feature is hard because “the framework is too old”.
- The runtime or framework version is past its end of support.
- Package installs show many deprecation or vulnerability warnings.
- A hosting provider or API vendor has announced it will drop support for something you rely on.
- Nobody wants to touch certain parts of the code because they might break.
What’s included
- Dependency updates on a regular cycle, with minor and patch versions kept current.
- Major upgrades of frameworks and runtimes, planned in steps rather than rushed at end of support.
- Deprecation tracking for the libraries, APIs and platform services the application uses.
- Automated tests added or extended around the areas upgrades touch, so regressions are caught before release.
- Build and deployment checks, so the application can still be built and deployed from a clean environment.
- Technical notes recording what was changed and what is planned next.
Our process
- Assessment. We review the codebase, dependencies, versions, test coverage and deployment process, and produce a short report on the current state.
- Upgrade roadmap. Upgrades are ordered by risk and deadline, with end-of-support dates driving priority.
- Safety net. Where tests are missing, we add them around critical paths before changing dependencies.
- Incremental upgrades. Changes are made in small, reviewable steps, tested in staging and released separately.
- Ongoing cycle. Once current, the application stays current through regular small updates.
Tools and standards
We work in your version control repository, with changes going through pull requests and review. Dependency audit tools for the relevant ecosystem, such as npm audit, Composer audit or pip-audit, help identify known vulnerabilities. Continuous integration runs tests on every change, and staging environments mirror production closely enough that an upgrade behaves the same way in both.
What affects timeline and effort
The biggest factors are how far behind the application is, how much automated test coverage exists, the number of third-party integrations, and whether there is a working staging environment. A codebase that has been kept current needs only light, regular attention. One that has been left for several years may need a dedicated upgrade project first, which we scope separately and honestly.
External deadlines also shape the plan. When a framework version, payment API or hosting platform announces an end-of-support date, the work affected by that date moves to the front of the queue. Planning around those dates months ahead is far calmer than reacting in the final week, and it lets upgrades be spread across normal maintenance cycles instead of stopping feature work.
Common mistakes
- Waiting until a runtime reaches end of support, then attempting several major upgrades at once.
- Pinning every dependency forever to avoid change, which only postpones a harder upgrade.
- Upgrading without tests, so problems appear in production instead of staging.
- Letting the only developer who understands the build process leave without documentation.
- Ignoring vendor deprecation emails for payment, maps or messaging APIs until the old version stops responding.
Frequently asked questions
Can you maintain an application another team built?
Yes. We begin with an assessment so we understand the code, its dependencies and its deployment before making changes, and we tell you plainly what state it is in.
How often should dependencies be updated?
Small, regular updates are easier and safer than occasional large ones. We agree a cycle with you, and handle urgent security fixes sooner.
Will upgrades change how the application works?
The aim is for users to notice nothing. Changes are tested in staging first, and any behaviour change that cannot be avoided is discussed with you before release.
What if the application is too outdated to upgrade?
Sometimes a partial rebuild is the more sensible option. If so, we explain why and outline the choices, rather than forcing an upgrade that would cost more in the long run.
Do you need access to our production environment?
We work mainly in your repository and a staging environment. Production access is needed only for releases and investigation, and can be limited to what the agreed deployment process requires.
Talk to us about application maintenance
Keeping your custom software current as libraries and platforms move underneath it.