APPLICATION MAINTENANCE & SUPPORT

Your Applications.
A Whole Team
Behind Them.

No single hire covers everything a production system needs. AMS gives your applications a named team with every skill, work you can see every month, and a clear way out if you ever want one.

Request an Assessment
Talk to Us First

Fixed scope, fixed price. A detailed report on the environment we agree to cover, yours whether or not you continue. If you do, half of it is credited against the service.

What is Application Maintenance & Support?

A Named Team That Keeps Your Applications Working, and Moving.

AMS is OSQuay's ongoing service for enterprise applications already in production. We keep them stable, resolve incidents against a defined commitment, and deliver a steady flow of changes the business needs, without starting a new project every time.

It is not a helpdesk, and it is not a retainer for whoever is free. It is a team that knows your systems, a documented process from the first ticket to the monthly review, and service levels you can hold us to. Fixing, preventing, and evolving all three every month.

Built for IT leaders, application owners, and operations heads with more applications than capacity and no appetite for a vendor they cannot reach. And when the worst happens, a team that has handled it before.

Request an Assessment

Four Ways a Working Application Turns Into a Liability.

Why Systems Become a Risk

The application is rarely the problem. The problem is what happens around it once the build is over.

01

The people who built it are gone

The partner’s contract ended. The developer who understood the integration left. The system still runs, but nobody can confidently change it, so nobody does. Then something breaks and the only option is to guess.

Warning signsNo change in 14 monthsDocs last updated at go-live
02

The unglamorous work never gets done

Patching, upgrades, monitoring, the slow cleanup of technical debt. Nobody is assigned to it, so it does not happen, until it happens the expensive way. Most incidents are maintenance that was skipped.

Warning signs23 updates waitingFramework out of support
03

It all sits with one person

One engineer, one skill set, one calendar, one notice period. When the problem is outside what they know, it waits. When they leave, the knowledge leaves with them.

Warning signsOnly 1 person knows itFixes wait until they are back
04

Nobody is actually accountable

A support arrangement without service levels is a hope, not a commitment. When the question is “who is fixing this and by when”, the honest answer is often “we’re not sure”.

Warning signsNo service level agreedNobody knows who is on call

The Alternative

The Real Comparison Is a Team Against One Hire.

Most organizations consider two options: muddle through or hire someone to own it.
Hiring sounds responsible. It is also fragile.

One person in-house
  • One skill set. Every kind of problem waits for the same person
  • One point of failure. Holidays, sickness, and resignation stop the service
  • Out-of-hours coverage is a favor, not a commitment
  • One salary, plus the months to recruit, plus the cost of replacing them
A named OSQuay team
  • The right skill for the moment, from someone who has solved it before
  • Continuity built in. The knowledge is documented, not carried
  • Coverage is a service level, staffed properly
  • A comparable investment buys a whole team, with none of that risk

Your people should be on the roadmap. Running what is already live is a different job, and it is ours.

We will walk through the comparison for your situation, with figures for your market, in the first conversation.

Situations We Take On

Where Application Owners Usually Start.

Vendor exit

The partner who built it has moved on

The contract ended, the warranty expired, or the relationship did not survive. You have a working system and no one who owns it. We take it over with a structured handover and a service commitment behind it.

Knowledge walked out

The one person who understood it left

It was never written down, and now they are gone. We rebuild the knowledge from the code, the data, and whoever is left, and we write it down so it cannot happen again.

Post go-live

The project is finished and support was never planned

The build went well. Then the team dispersed and the application became somebody’s side responsibility. Go-live is a transition, not an exit. We put support in place before the first serious incident.

Change backlog

Too many small requests, no capacity to deliver them

Every change competes with everything else, so most never happen. We give evolution a defined capacity and a defined process, so the business stops waiting.

Aging system

It has to keep running, and it cannot be replaced yet

The replacement is years away and the current system has to hold. We keep it stable, secure, and honest about its risks, without pretending it is something it is not.

Under-served by a large vendor

You have a support contract, and you cannot reach anyone

The vendor is large, the account is small, and the seniors who sold the deal moved on the week after signing. We are a team you can name, reach, and hold to a commitment.

Not one of these? Describe your situation in one call. We will tell you whether AMS fits, and if it is not the right answer, what is.

Get a straight answer

The situations we see most often, and where the path is well understood. Every one of them starts with the assessment.

Taking It On

From Someone Else’s System to One We Can Stand Behind.

Every engagement starts with a handover, whether the application was built by a previous partner, your team, or us. It is the part most support arrangements skip.

1

Knowledge Transfer

We sit with whoever knows the system today and map what it does, what it touches, and where the risks are.

2

Technical Onboarding

Environments, access, code, pipelines, integrations. We validate that we can build, deploy, and recover it ourselves.

3

Risk Analysis and Documentation

We write down what we found: the fragile parts, the undocumented dependencies, the things nobody has touched in years. You keep that document either way.

4

Roles, Rules, and Go-Live

Who calls whom, how incidents are raised, how severity is decided, what happens out of hours. Agreed in writing before the service starts.

Typical duration: four to six weeks for a single application. Larger environments are planned during the assessment. If you have done the assessment, steps 1 to 3 are already complete, which is why half of it is credited.

Running the Service

Three Kinds of Work. One Team. And You See All of It.

Most support arrangements only show up when something is on fire. AMS covers fixing, preventing, and evolving, and every month you get a log of exactly what was done, so a quiet month reads as a month of prevention, not silence.

Three kinds of work. Select one to see how it runs.

Corrective: when something breaks

  1. Logged and acknowledged

    Raised through the agreed channel, acknowledged within your service level's response time, by a person who has seen it.

  2. Classified and assigned

    Severity set against definitions agreed at the start, with an escalation route if you disagree.

  3. Restored, then fixed

    A workaround first, so you are working again. The permanent fix follows, tested and deployed properly.

  4. Reviewed and closed

    Root cause analysis on every critical incident. A report and a review every month.

Preventive: keeping it healthy

Monitoring, patching, upgrades, performance checks, security updates, and the technical debt that builds up in any system in production. Repetitive work is where people cut corners, so we built our own tooling for it. It gets done on schedule, and you can see the record.

Evolutive: moving it forward

The changes the business asks for, scoped, approved with you, and shipped through the same pipeline as everything else. The team has built production systems, not just supported them, and design and UX are part of it, so a change that touches what users see gets designed properly rather than bolted on.

Service Levels

Three Levels. Same Team,
Same Process, Same Standard.

What changes is coverage and speed. What does not change is the people, the process, or the documentation. Preventive work is part of every level.

Service level
Essential
For stable systems that matter during the working day

Business-hours coverage, defined targets, corrective work first. The starting point for a system that is important but not critical.

Typically includes:
  • Business-hours support
  • Incident management
  • Monthly work log
  • Quarterly review
Start a Conversation
Most common
Extended
For systems the business depends on through a long working day

Extended hours, an on-call route for critical incidents outside the window, faster targets, evolution included. Where most clients land.

Typically includes:
  • Extended-hours support
  • On-call for critical incidents
  • Evolution capacity
  • Dashboard access
  • Monthly work log and review
Request an Assessment
Service level
Continuous
For systems where an outage stops the business

Round-the-clock coverage for critical and high-severity incidents, the fastest targets we offer, reserved evolution capacity, incident reviews.

Typically includes:
  • 24x7 for critical and high incidents
  • Fastest targets
  • Reserved evolution capacity
  • Incident reviews
  • Monthly review and steering committee
Start a Conversation
After a go-live
Hypercare
For the weeks when a system is newest and most exposed

A temporary step up to the next level for a fixed period, typically four to eight weeks. Returns to normal automatically. Available at any level.

Talk to Our Team

Levels are matched to how critical the environment is, not how large it is. You can move between them as the situation changes.

Why OSQuay

A Team You Can Name.
Work You Can See.
A Door You Can Leave Through.

Most support arrangements are built for the vendor’s convenience. AMS is built the other way around, and each of these is something you can check.

A dedicated team, not a person and not a rotating pool

A team whose job is running systems in production, not a project team fitting support in between builds. The seniors who sold it are the seniors who run it, and they stay.

You see the work every month

A work log, a dashboard, and published performance against the commitments we made. Judge us on the record, not the adjectives.

Prevention and evolution, not just repair

Our own tooling for the routine work most vendors skip, and a team that has built production systems for insurance, financial services, government, and energy and can improve yours, design included.

No lock-in. The architecture stays yours

Architectural decisions are yours, and we say so when we disagree. Every agreement includes a transition-out with the documentation we produced. The knowledge stays with the system.

Side by side

How AMS compares with a typical support contract

Seven things worth checking in any support proposal, ours included.

OSQuay AMS Typical approach
A dedicated team that knows your systems, and staysWhoever is available on the day, and the A‑team leaves after signing
A monthly work log you can read line by lineA summary on request, if at all
Preventive work on schedule, with our own toolingNothing happens until something breaks
Evolution included, with its own capacityEvery change becomes a change request
Design and UX inside the teamAnything visual is someone else’s problem
Your architecture, your decisions, documentedThe vendor becomes the only voice on architecture
Defined exit and transition-outLeaving means starting from zero

Start With the Assessment. Decide With the Report in Hand.

What’s Next

A detailed assessment of the environment we agree on together: one application, a group of them, or the whole estate. What it does, what it depends on, where the risks are, who holds the knowledge, and what supporting it would take. The report is yours either way.

Talk to Us First
Talk to Us First

Fixed scope and fixed price, agreed before we start. If you proceed to AMS within three months, half the assessment is credited against the service.

1

A 30-minute conversation

Which environment, what worries you about it, and what happens today if the person who knows it is unavailable. No deck, no pitch.

2

The assessment

Typically two to three weeks for a single application. Inventory, integrations, risk map, dependencies, documentation gaps, technical debt, security posture. A written report and a recommended service level.

3

You decide

Take it to your stakeholders. Proceed and the handover is already a third done. Or keep the report and use it with your own team. Either is a fine outcome.

Frequently Asked Questions

Common Questions, Direct Answers

  • A fixed-scope review of the environment we agree on before starting, at a fixed price agreed up front. Typically two to three weeks for one application, longer for a wider scope. You get a written report covering the systems, their dependencies, their risks, and what supporting them would involve, plus a recommended service level. If you proceed to AMS within three months, half of it is credited. The report is yours whether or not you continue.

  • For some systems it is the right answer. But one person is one skill set and one point of failure. The database problem, the security patch, the broken integration, and the screen that needs redesigning all wait for the same calendar. For a comparable investment, a team covers every skill and none of that risk. We will walk through the comparison for your situation.

  • Yes. Most engagements start with an application someone else built. The handover is designed for that: we rebuild the knowledge from the code, the environments, and whoever is available, and document it so the dependency on any one person ends.

  • Access to the code, environments, and pipelines. Someone who can answer questions for a few hours a week during handover. A clear view of what the application does for the business, so severity definitions reflect reality. We do not need existing documentation. Producing it is part of what we do.

  • Most enterprise estates are mixed, and so is our work. Our teams build and support applications on OutSystems, .NET, Java, and modern stacks such as TypeScript, React, Node.js, and Rust, along with the integrations and surrounding systems they depend on. We have particular depth in OutSystems, where we have worked since 2018, but the service is the same on any platform. If an application is outside what we can support properly, we say so.

  • Yes. AMS is run by a dedicated team, and the team you meet is the team you get. Nobody is swapped for a junior after signing, and nobody is pulled off your account because a project needs hands. If someone changes, you know before it happens.

  • It depends on the level. At the entry level, out-of-hours incidents are logged and picked up first thing next business day. At higher levels, critical incidents have an on-call route or round-the-clock coverage. We are explicit about this in the agreement.

  • Yes, and it is written into the agreement. Every contract includes a transition-out: we hand over to your team or whoever comes next, with the documentation we produced. We would rather earn the renewal than rely on the exit being painful.

  • In Team Augmentation, you get our people and you manage them. You own the outcome. In AMS, we manage our people, run the process, and carry the service commitment. The question is who you want accountable.

  • Yes. OSQuay has four delivery centers, in Lisbon, Viseu, Mexico City, and Chennai, and active clients in the United Kingdom. Remote-first is the default, with on-site presence for the handover and periodic reviews when it is genuinely useful.