Existing application support
Support for .NET and SQL Server applications your business still relies on.
When the original developer has moved on or an important application needs attention, the first job is to understand what the business already depends on. I take over existing .NET and SQL Server applications, including C#, VB.NET, WinForms and ASP.NET software written by other developers. The work can include investigating faults, maintaining the database and making carefully scoped changes across the application, its integrations and its deployment environment.
Discuss your existing applicationCommon starting points
The application still fits the business. Support has become uncertain.
The need is often not a new platform. It is someone who can establish technical ownership, solve the immediate problem and make considered changes to the system already in use.
Takeover
The original developer is no longer available
Staff understand how to use the application, but knowledge of the code, database, dependencies or release process has left with the person who built it.
Investigation
The fault does not stay in one layer
A screen fails, a report disagrees with operational data or a scheduled process stops. The cause may sit in application code, SQL Server, an integration or the environment around them.
Change
The workflow has moved on
New fields, rules, reports or connections are needed in an application that otherwise still supports the business. Those changes can be assessed without turning them into a replacement project.
What application support involves
Work across the application, the data and the environment around it.
Established systems often contain years of accumulated behaviour, integrations, deployment assumptions and business rules. A reported fault may appear in one place and originate somewhere else, so support cannot be limited to editing the first screen that shows an error.
Take over an unfamiliar codebase
Review the solution, framework version, build process, configuration, third-party components and known operational work. Speak with the people who use the application and establish a repeatable build where the available source and tools allow it.
Investigate faults before changing production
Trace the reported behaviour through screens, application code, stored procedures, data, Windows services, APIs and hosting. Determine whether the cause is in the application, database, permissions, configuration, infrastructure or an external dependency before deciding what needs to change.
Maintain SQL Server alongside the application
Investigate queries, stored procedures, reporting datasets, schema changes and data mismatches as part of the same system. Establish why a record is incorrect and what other workflows use it before making production corrections.
Extend established workflows
Add or revise screens, fields, business rules, reports and integrations in C#, VB.NET, WinForms and ASP.NET applications. Check the shared data and connected processes affected by the change rather than treating each request as an isolated screen edit.
Support the application over time
Use agreed priorities, support hours and response expectations for investigation, maintenance and smaller changes. Keep build instructions, deployment steps, dependencies and investigation findings current so each new issue does not begin from memory alone.
Before the first change
Establish a build, a test path and a release path.
Existing application support becomes dependable when source access, environments, business acceptance, deployment and recovery are understood before production changes are made.
01
Confirm access and supportability
Review the source repository, build tools, framework versions, component licences, database access, logs, environment configuration and deployment arrangements. Identify integrations and external services, who can authorise access and who understands the business rules the application applies.
02
Reproduce the issue and define the expected result
Establish a suitable test environment where possible and use appropriately handled sample or test data. Reproduce the fault or walk through the requested change, then agree representative cases and who will confirm that the affected workflow behaves correctly.
03
Make and release the change deliberately
Scope the application, database and dependency changes together. Agree release timing, deployment responsibility, backup or recovery arrangements and post-release checks around the work the application supports.
Ongoing support
Reserve time for maintenance, investigation and small changes.
An ongoing arrangement follows an initial review of the application, its access and its supportability. The agreed hours, priorities, response expectations and escalation contacts should be clear before the business relies on the arrangement for a live system.
Application support
from $1,125/month
Includes five hours each month at $225 per hour. Additional support hours use the same rate. Separately scoped development is quoted after review. Prices are in AUD and exclude GST.
Discuss support arrangementsQuestions
Before handing over an application
Taking over an existing application
What do you normally need before work can begin?
A useful starting point includes a clear description of the application, who uses it and the fault or change that needs attention. Technical access may include source code, build tools, database or schema access, logs, test data, hosting information, deployment instructions and documentation for connected systems. Not every application will have all of these. The initial review identifies what is available, what is missing and whether the system can be supported responsibly.
Can you help if the source code or documentation is missing?
The first step is to establish what exists and who may hold it. Database, environment or integration investigation may still be possible, but application changes can be restricted without the source code, compatible build tools or required component licences. Missing documentation can be reconstructed to a point, but missing source code is a different constraint and may materially limit the available options.
What kinds of existing .NET applications can you take over?
My relevant experience includes C#, VB.NET, .NET Framework, WinForms, ASP.NET applications including Web Forms, and SQL Server-backed business systems. Some applications also depend on Windows services, APIs, scheduled processes, third-party components and IIS or Azure hosting. I review the actual codebase, database, dependencies and deployment access before accepting support responsibility rather than assuming that every .NET environment can be supported in the same way.
Ongoing support and change
What can ongoing application support include?
It can cover fault investigation, bug fixes, SQL Server work, reporting changes, small enhancements, integration issues, deployment assistance and keeping technical support information current. The exact responsibilities, available hours and response expectations are agreed in advance. Larger features, migrations and platform changes can be scoped separately.
Does a legacy .NET application need to be modernised or rewritten before you can support it?
No. If the application still fits the business and can be built, tested and released responsibly, maintaining and improving it may be the sensible option. Maintenance works within the current system to address faults and required changes. Modernisation changes part of its technical foundation, such as hosting, deployment or an ageing dependency. A rewrite is a separate project and needs a specific business or technical reason.
Can you provide urgent or after-hours support?
Availability and response windows need to be agreed before an urgent issue occurs. I do not operate a 24-hour help desk. A support arrangement should identify what counts as urgent, how contact is made, which access must already be available, who can authorise a production change and what the business does if I am unavailable.
Discuss the work
Tell me what the application does.
Describe who uses it, the work it supports and the fault or change that needs attention. If known, include the technologies involved, what happened to the previous support arrangement and whether source code, database, test and deployment access are available. I can review whether the application is a suitable support fit and what needs to be established before the first change.