Skip to content
XSIS
Client AreaRequest a Proposal

Software Engineering

Application Management and Support

Applications kept available, secure and improving, with one team accountable for how they run.

Talk to Our Team

Why It Matters

An application that nobody owns fails slowly. Patching waits, monitoring is thin, and small faults become outages. Users report the problem before the team sees it.

Support often stops at the ticket. Fixes are made without a release plan, changes are not recorded, and knowledge stays with one supplier. The business carries the risk and cannot move.

What We Do

  • Support and Maintenance Under Service Levels

    A named team answers, fixes and reports against the levels you agreed.

  • Monitoring

    We watch the application and act before users notice a problem.

  • Fixes and Small Changes

    Small improvements land on a steady rhythm without a separate project.

  • Release Management

    Changes reach production safely, with a tested route back.

  • Knowledge Transfer

    Your team learns the system so dependence on us falls over time.

What Changes for You

  1. The Application Stays Up

    Monitoring, patching and planned changes keep it running, and you see availability and open risks against the service levels you chose.

  2. Security Work Continues

    Patches, access reviews and dependency checks run on a schedule, so a known weakness is fixed before it becomes an incident.

  3. Changes Arrive Safely

    Small fixes and improvements follow one release path with a way back, so you see what changed and why.

What We Run and Watch

The agreement names what we run and where our responsibility stops. You keep control of access, data and priorities.

  • The Software We Run

    We support the applications in the agreed list, including their configuration and scheduled jobs. The list is fixed in the agreement.

  • The Links Between Systems

    We watch the interfaces that carry data in and out. A failed link is detected and retried, and the owner is told.

  • Data and Recovery

    Backups, restores and data checks follow the agreed schedule. You decide who can approve a restore.

  • Users and Access

    We handle access requests and joiners, movers and leavers through your identity process. You keep control of who approves access.

Service Levels

Response

P1
under 15 minutes
P2
under 30 minutes
P3
under 4 business hours
P4
under 1 business day

Escalation

P1
immediate war-room mobilisation
P2
within 1 hour
P3
the next daily triage
P4
the next scheduled sprint

Resolution

P1
under 2 to 4 hours
P2
under 8 hours
P3
24 to 48 business hours
P4
the next scheduled release

Onboarding

A takeover starts with evidence, not a promise. We agree what we run, the levels we meet and how you can leave.

  1. Measure

    The first step is a measured review of the current service and its risks. You give us access to monitoring, logs and the support queue, and you tell us what must not change.

  2. Take Over

    We take on the service in a planned window and name the people who own it. You approve the handover checklist and the route back.

  3. Run It Steadily

    We run the service to the agreed levels and report what happened. You join the service review and decide what changes.

  4. Review and Improve

    We review the service each period and propose improvements. You decide which changes are worth doing and when.

Reporting

You see the service as it is, not only the tickets that closed. Each report names the owner and the next action.

  • Service Review

    Availability, incidents and open risks in one report. You see the trend, not only the latest figures.

  • Incidents

    Each incident has a timeline, a cause and the action that prevents a repeat. You see it before the next review.

  • Changes

    Every release and configuration change is recorded with its result. You can trace what changed and who approved it.

Platforms and Technologies

We run applications on the platforms they already use. AWS and Azure are cloud platforms, and Red Hat Enterprise Linux is an operating system. Kubernetes runs containers, Grafana and Prometheus show how the system behaves, OpenTelemetry collects traces across services, and Terraform manages infrastructure from code.

Cloud
  • Amazon Web Services
  • Microsoft Azure
  • Red Hat Enterprise Linux
DevOps and observability
  • Kubernetes
  • Grafana
  • Prometheus
  • OpenTelemetry
  • Terraform

Naming a product does not mean a partnership with its vendor.

Industries

Questions

What operations leaders ask before they hand over an application.

How does a takeover start?

We begin by measuring the service and recording its risks. You give us access to monitoring, logs and the support queue. Before we take responsibility, we agree the service, its levels and the exit route.

Link to this question

How do service levels work?

We agree a priority for each kind of incident and the response and restoration time that follows. The levels are written into the agreement. You see performance against them in every review.

Link to this question

What shapes the cost?

The number of applications, their state and the hours you need covered. Monitoring, security work and change volume add effort. We agree the service and its boundaries before you commit.

Link to this question

Do we keep control of the application?

Yes. You own the code, the data and the accounts. We work under access you grant and can remove at any time. The runbooks and records stay with you.

Link to this question

What is not included?

We name the applications and services in the agreement. New builds, major upgrades and work on systems outside the list are separate. The boundary is written down, so there are no surprises.

Link to this question

Visit the Knowledge Base

Tell Us What You Need to Run, Build or Secure.

Describe the service, the systems and the pressure you are under. The right team takes it from there.

Talk to Our Team