Counter-intuitively, critical production applications can often fall into disrepair. Teams get busy, budgets get reprioritized, and the less flashy applications can atrophy as a result, compromising performance, accessibility, security, and the ability to add new capabilities.
Sometimes the application was built using a language or framework that your in-house development team is not familiar with. You don’t want to dilute their present area of expertise, or force them onto a professional path that they may not have bought into.
Sometimes everyone is surprised at a pilot application’s success, and what began as a prototype has quickly and unexpectedly become a production application. These apps often lack critical infrastructure.
In many cases, the original authors of the application have moved on, leaving its new owners in a bind, and support in a vacuum.
Sometimes applications that have been stable for years with little maintenance begin to develop reliability or performance problems. Our application development and DevOps expertise allows us to get to the heart of performance issues so that we can surgically make the smallest possible change to alleviate the biggest possible issue.
We can also ensure that you’re receiving data and notifications on errors and exceptions that occur in production. These can help to provide insight into exactly how stable or unstable the application is for your users.
One of the primary drivers for modernization is compliance with university security and accessibility policies.
WCAG compliance and mobile compatibility often rank highly as concerns for legacy applications. We can incrementally bring these applications (back) into compliance.
The application’s authentication system may need to be gutted and changed from a locally-stored email/password combination to an integration with your university’s authentication system. If the scope of use is beyond your university’s faculty, staff and students, then you may want to leverage Shibboleth and the InCommon Federation.
Some legacy applications lack a sufficient level of automated tests. This creates a sense of fear around modifying or updating the application code and its dependencies.
Even if a critical application contains no substantial unit or component tests, we can still create “characterization tests” that help to ensure that incremental changes are not breaking critical functionality. This helps to break the cycle of fear associated with making changes to a critical system where no one is intimately familiar with the code.
Deployment also may be an issue. If the application is not already set up for one-step deployments, this creates another barrier to maintenance. Our DevOps expertise lets us get the application onto a more agile path.
If your application only runs in development and production environments, we can create a staging and/or beta environment that duplicates the production environment. This essential step allows for “smoke tests” and relieves some of the pressure of making new deployments to production.
Due in part to difficulties with updating or deploying the code, security updates may have fallen behind. Operating system updates are often straightforward or handled automatically. But libraries or plugins that are bundled with the application are often out of date. The application framework itself may be a couple major versions out of date.
If the application was originally written by a less experienced developer, there’s a chance that there exist common security vulnerabilities in the style of the application code itself. We can perform manual and automated audits of your application code to look for common (and not so common) mistakes that lead to easily exploited vulnerabilities.
By introducing automated tests, staged deployments, and continuous integration as described above, we can gradually and predictably bring the application back into compliance with security updates.
Legacy applications often don’t receive adequate backups. Perhaps the database is being backed up, but the other assets are not. Often the backups haven’t been fully verified in years. Or the backup interval is insufficient. We can evaluate whether all of the state for your application is being adequately backed up, and whether those backups are timely, accessible, and sufficiently distributed.
We believe that a rewrite should be the option of absolute last resort. But for some applications, all parties come to the conclusion that such a course is going to be necessary. This is often the case for tools or frameworks that are no longer in common industry use. Or for application code that is in heavy use, but is unfortunately completely unmaintainable.
One of the keys to a successful rewrite is figuring out how to do it incrementally. We can often devise a way to partition the application’s functionality into components, so that each component can be rewritten while leveraging shared state. Incremental rewrites drastically reduce the risk of the overall modernization effort because you begin to get pieces of legacy code out of commission earlier, and you get your modern application code into production earlier. And you can apply what you learn in earlier iterations to later iterations.
If the original developer is still present within your organization, or if you’re planning on having an in-house developer take over the maintenance of the application, you may consider coupling a modernization effort with mentoring, to boost your developers’ knowledge and put them in a good position to take over once our project is complete.
The same forces that caused the application to fall into some amount of disrepair may still be in play. After modernization is complete, consider delegating the maintenance, monitoring, support, and enhancements of the application to us via a service contract. That way we can permanently bolster your organization’s ability to continue to focus on the other applications that represent your team’s best and highest use.
The first step is often a zero-pressure phone call to answer questions and explore whether we both feel that there could be a fit.