Launch day is the halfway point: keeping custom software healthy for years

What maintenance really covers

After launch, custom software needs four kinds of ongoing work: fixing problems users find, adapting to changes in browsers, operating systems and connected services, applying security patches, and adding improvements as the business changes. It also needs hosting, monitoring and backups. Plan and budget for all of it from the start, because software that nobody maintains becomes the next legacy system, the one everyone is afraid to touch.

I raise this in the very first conversation with every client, before anyone talks about features. A system that launches beautifully and then drifts for two years is a worse outcome than a slightly smaller system with a clear plan to keep it healthy. At Aezion the final stage of our cycle is called Steward for exactly this reason.

The first weeks after go-live

The period right after launch is the most intense. Real users do things no test script anticipated, data from the old system turns up edge cases, and small usability issues surface once people use the software all day. This is normal and is not a sign that the project failed. What matters is how quickly problems are triaged and fixed.

A good launch plan includes a stabilization period with the development team on call, a clear way for users to report issues, a daily review of what has been reported and quick communication back to staff about what is fixed and what is coming. It also includes watching performance closely, because real usage patterns often differ from what load tests assumed.

On your side, name one project owner who can make decisions quickly and who users know to approach. Resist the temptation to pile new feature requests into the stabilization period. Capture them on a list, finish fixing what is broken first, and then plan the improvements properly once the system has settled. Mixing the two slows both down and makes it harder to tell whether the system is stable.

• One channel for reporting problems, so nothing is lost in email.
• A simple severity scale agreed in advance: down, broken, annoying, wish list.
• Daily triage between your project owner and the development team.
• Short updates to users so they see their reports acted on.
• Close monitoring of speed, errors and data accuracy.

Four kinds of work that never stop

Once the system settles, maintenance becomes steady and predictable. It falls into four categories, and a support plan should cover each one explicitly. If a proposal or agreement mentions only bug fixes, ask what happens with the other three.

The balance shifts over time. Early on, corrective work dominates. Later, adaptive and security work become the steady base load, and enhancement work depends on how fast the business is changing.

Adaptive work is the category companies most often forget to budget. A payment processor retires an old interface, a shipping carrier changes its data format, or a major browser update alters how a screen behaves. None of these are your team's fault, and none can be ignored, because the software simply stops doing its job until it is adjusted. A support plan that anticipates this kind of change keeps it routine instead of an emergency.

• Corrective: fixing defects users find in day-to-day use.
• Adaptive: keeping up with new browser and operating system versions and with changes to the outside services the software connects to.
• Security: applying patches to the application, its components and the platform beneath it, and responding to newly discovered weaknesses.
• Enhancement: new features, reports and workflows as the business grows or changes.

Why skipping security updates gets expensive

Every application is built on layers of other software: an operating system, a database, frameworks and libraries. Each layer receives security fixes, and each eventually reaches the end of its supported life. When maintenance lapses, those layers fall behind, and the application inherits every weakness discovered in them.

The Cybersecurity and Infrastructure Security Agency lists the use of unsupported or end-of-life software among its catalog of bad practices, calling it dangerous in the context of critical infrastructure. The principle applies well beyond that: software nobody patches becomes easier to attack every month. Our application security service covers identity and access management, vulnerability assessments, security patching and proactive monitoring for this reason. If your system holds customer data, falling behind on patches can also complicate your obligations under Texas privacy and breach rules, which I explain in my guide on Texas privacy law and customer data.

Signs your software is drifting toward legacy

Software rarely fails all at once. It drifts. Each skipped update and each workaround makes the next change a little harder, until the system is something everyone avoids touching. Watch for these warning signs, and treat two or more as a reason to act.

Catching drift early is far cheaper than rescuing a system that has fallen years behind. If you are already past that point, my guide on whether to modernize or rebuild a legacy application walks through the options.

• Small changes take weeks because people are afraid of breaking something.
• The platform, database or framework is near or past the end of vendor support.
• Only one person understands how a key part works.
• Users keep spreadsheets on the side to work around missing features.
• Nobody can say when the last backup restore was tested.
• Integrations break whenever a connected service updates.

Hosting and monitoring: decide who watches the system

Every live application runs somewhere, and someone has to watch it. You can host it yourself, run it in your own Azure or AWS account and manage it in-house, or hand hosting to a managed provider. Each works; what does not work is assuming someone else is watching when nobody is.

Our managed hosting provides application infrastructure with 24/7 monitoring, scalability and disaster recovery, with service levels set out in an agreement. Whoever hosts your system, insist on monitoring that alerts a person when something fails, regular backups that are actually test-restored, and a written plan for recovering from an outage. If your application runs in the cloud, cost monitoring belongs on the same list; my guide on whether the cloud really saves money covers the bill side of that responsibility.

What to put in a support agreement

A support agreement turns good intentions into commitments. Whether you sign with the firm that built the system, a different provider or plan to support it in-house with outside backup, these are the points to settle in writing. Have your attorney review anything that touches liability, data handling or ownership.

Make sure the agreement reflects how important the system is to your business. A tool used by one team can live with next-day responses; a system that takes customer orders cannot. Review the agreement once a year alongside the system itself, because what was a minor internal tool at launch may have become central to operations since.

• Response and resolution targets for each severity level.
• Which kinds of work are included, and how enhancements are quoted.
• Who holds administrator access, source code, cloud accounts and credentials.
• How security patches and platform updates are scheduled and tested.
• Backup frequency, restore testing and the disaster recovery plan.
• Documentation the provider must keep current.
• How the relationship ends and how the system is handed over if it does.

Planning improvements without starting over

A healthy system evolves with the business. Keep a running list of requested improvements, review it with the provider on a regular rhythm, and decide what to build next based on value rather than on who asked loudest. Small, regular releases keep the system current and keep users engaged, because they see their feedback turn into changes. Each release should go through the same testing discipline as the original build, including the connections to other systems, so improvements do not quietly break something that used to work. Keeping documentation current with each release matters just as much, because the next person to change the system depends on it.

Revisit the bigger picture once a year: has the business changed in ways the system does not reflect, are new spreadsheets appearing around it, and are any of its building blocks approaching end of support? This annual review is how you avoid the situation I describe in my guide on replacing the spreadsheet that runs your company, where tools quietly fall behind until the business is working around them.

How we stay with clients after launch

Our Steward stage covers application support, application security, managed hosting, infrastructure support and support for third-party products in your environment. Some clients hand us all of it; others keep day-to-day support in-house and use us for security, hosting or larger enhancements. When a system was built by someone else, we start with an assessment of its code, platform and hosting before proposing any plan. The promise behind our A-Z Performance Guarantee applies here too: We Get It Right, We Make It Right, Period.

If you have a system that launched recently, or one that has been running for years without a clear plan, bring what you know to a first conversation: what it does, where it is hosted, who supports it now and what has gone wrong lately. Companies in Dallas–Fort Worth can meet us at our Frisco headquarters, and many clients work with us remotely. You will leave with a clear view of what your system needs to stay healthy.

Questions people ask me