Software support and maintenance

Application support and maintenance covers more than a codebase. We look after the code, the cloud it runs on, the pipelines that release it and the apps or devices that depend on it.

• Custom web applications and portalsCustomer portals, registers and internal tools, with their integrations
• Cloud platforms and APIsBuilt on .NET, Node.js and other modern frameworks, running in Azure or AWS
• Salesforce Experience CloudPortals and Lightning Web Runtime sites built on Salesforce
• Mobile appsNative iOS apps in Swift and Android apps in Kotlin, or cross-platform apps in React Native, with App Store and Google Play releases
• Edge and IoT device fleetsLinux devices across many sites, with remote updates and monitoring
• Cloud infrastructure and pipelinesInfrastructure as code in Terraform or Bicep, GitHub Actions or Azure DevOps pipelines, and monitoring on Azure and AWS

Need support for a content-managed website instead? Our website support and maintenance service covers that.

When you hand an Azure or AWS estate to us, we look after all of it, from the subscription or account and who can sign in to it, to the applications, data stores, pipelines and alerts. For each new workload we weigh the compute options, such as Azure Functions or App Service on Azure and Lambda, Amazon ECS on Fargate or EC2 on AWS, against its traffic and the team that will run it.

On Azure we look after subscriptions and Entra ID, applications on App Service and Azure Functions, Azure SQL databases, Azure Monitor alerts, infrastructure in Bicep or Terraform and pipelines in Azure DevOps or GitHub Actions. On AWS we run and tune a serverless platform built on AppSync, Lambda, DynamoDB, EventBridge, Step Functions and Cognito, along with the pipelines, backups and alarms around it.

• Architecture and security reviewEach subscription or account checked against the Azure or AWS Well-Architected Security Pillar, the CIS Foundations Benchmark for that cloud and the Australian Government ISM, with a ranked fix list
• Subscriptions, accounts and identityProduction in its own Azure subscription or AWS account, sign-in with MFA through Entra ID or AWS IAM, and long-lived keys retired
• GitHub Actions and Azure DevOps pipelinesShort-lived OIDC credentials and one deploy identity per environment, narrowed to what CloudTrail or the Azure activity log shows it uses
• Infrastructure in Terraform or BicepLive resources brought into code, with Terraform state per environment and locking, and destroy protection on business data
• Data and backupsPoint-in-time restore for Azure SQL and DynamoDB, Azure Backup and AWS Backup vaults locked against deletion, and a backup before every release
• Monitoring and alertingAzure Monitor and Application Insights alerts, or CloudWatch alarms through SNS, with health checks and latency compared before and after each release
• Security and incident responseEntra ID sign-in logs and CloudTrail used to trace and contain unexpected access, with secrets kept out of logs and repositories
• Costed changesEach change costed before it is built, and compute such as Lambda memory or an App Service plan sized from a month of monitoring data

When support for an Azure subscription or AWS account moves to us, the first job is proving a restore. We confirm the backups have finished, export what the backup service does not cover, such as a Cognito user directory on AWS, and run a restore before we change anything. Then we compare what is deployed with what is in git, and what is running in the cloud with what is in Terraform or Bicep. A resource that was applied from code nobody committed can be removed by the next routine Terraform apply, along with its data, so it comes into the committed code with destroy protection first.

Releases run through GitHub Actions or Azure DevOps, with the Terraform plan or Bicep what-if read before every change, a rollback rehearsed on staging, and the deployed commit read back from Azure or AWS afterwards. Our DevOps consulting for AWS and Azure covers pipelines, release strategies and infrastructure as code in more depth.

Some of the platforms we look after reach past the cloud to Linux devices installed across many sites. We support edge and IoT platforms like these for several organisations, from the software on each device to the cloud platform the fleet reports to.

• Staged software updatesOperating system and application updates proven on test devices first, then rolled out to the fleet in stages
• Security patchingA monthly patch cycle across the fleet, with a faster path for actively exploited vulnerabilities
• Fleet health and alertsEach device monitored, with an alert to the right person when one stops reporting or faults
• Secure remote accessAuthorised, logged sessions, so most faults are diagnosed and fixed without a site visit
• Telemetry into the cloudDevice data and logs shipped to the cloud without holding up the device, so incidents can be read remotely
• The platform behind the fleetThe cloud APIs, data stores and dashboards the devices report to, under the same agreement

The platforms we support include a connected-door IoT platform with device telemetry, a cloud data lake, fleet health and remote lock. Our IoT integration services page covers device software and fleet management in more depth.

Incidents on a platform rarely affect everything at once, so we triage each one by severity. The level decides who is called in, how quickly we respond and when your team hears from us, and your service level agreement fixes the targets for each.

After a major incident, your agreement can include a post-incident review covering the timeline, the root cause and the change that stops it recurring. If you have no agreement with us yet and a platform is down or breached, start at our emergency help page.

Waypoint is the delivery platform we built to run our client projects, and every support agreement is managed in it.

• Tickets with a severityEach request and incident is logged, prioritised and tracked to resolution
• Time against the agreementHours are logged against your agreement on each ticket
• Monthly support reportsWhat was fixed, what changed and the hours used
• Documentation in one placeYour system’s documentation, kept alongside its tickets

Frameworks reach end of life, dependencies stop receiving security fixes, and a system that was current at launch needs planned software maintenance to stay supportable. Runtimes such as .NET follow a published support calendar, and once a version leaves support its applications stop receiving security patches. AWS publishes deprecation dates for its Lambda runtimes in the same way. We track those dates for the platforms we look after and plan each upgrade well before the deadline. Our guide to .NET 8 end of life walks through one of these upgrades.

We run legacy system modernisation as a sequence of releases, upgrading the runtime, replacing ageing dependencies and moving one module at a time, so the platform keeps running throughout. Application modernisation like this can sit inside a support agreement or run as a defined project for a system someone else built. Our article on application modernisation without a big-bang rewrite sets out the approach.

When a penetration test has found issues in a legacy product, or a customer, tender or regulator asks for a security standard, we pair the upgrade with a secure by design uplift that fixes the findings, and roll both out together.

Support that suited a platform at launch can fall behind as the product grows. Often the team has done good work for years and the tools have moved on, with automated testing, infrastructure as code and modern monitoring changing what a support team can deliver. Whether that team is internal or external, the need for a refresh shows up as a pattern your people start to plan around.

• Slow or unclear communicationRequests wait without a clear date for a fix
• No agreed response timesUrgent issues wait, with no target to measure against
• Bugs that arrive with every releaseChanges reach production without automated tests, and new faults follow
• No confidence in what breaks nextNobody wants to touch the system before a busy period
• No regular reportingNothing shows what was changed, fixed or found each month, and problems surface after users notice them

Each of these has a fix. We agree response and resolution targets for each severity level, and a monthly report in Waypoint shows what was changed, fixed and found, measured against those targets. We set up a staging environment and automated tests so releases are checked before they reach production, and every change goes into a release log you can read. You also get a named point of contact who knows the system. If the pattern sounds familiar, the steps below move support to our team without a gap in cover.

We run SLA and BAU support for more than ten organisations today, across government, waste, automotive, research and community services. These platforms are among them, each linked to its case study.