Posted by j.laird on 28 July 2022 - 10:00am Photo by Julia Craice on Unsplash

By Ed Mackenzie.

One issue in software sustainability is when a software application reaches its end-of-life but is deemed too important to retire. This situation emerged recently at my workplace where the Adobe ColdFusion license is due to expire shortly and there are several important internal and academic sites still utilising it.

The question then arises, particularly with high profile sites, whether to attempt a migration or an upgrade of each site. In my sample, the framework supporting the user interface will need replacing and the user interfaces rebuilt. But the underlying databases can seemingly be simply transferred from the proprietary relational database management system (RDBMS) to Open Source alternatives. This is deemed the migration option.

The upgrade option, for the purposes of this example, implies extensive rebuilding of the user interface and the database. For example, moving from a relational database underlying the web framework to a NoSQL alternative. It could also include redesign and development of the user interface to develop features not previously included in the original application.

Prior to deciding the fate of each individual site my approach has been to develop a staged process for identifying potential bottlenecks in migrating or upgrading these sites. These are represented by three core criteria: data structure, functional specification and externalities.

Data structure

In short, data structure focuses on the structure and representation of the data in each relational database. With the key criteria being: Can the structure and contents of the database be effortlessly transferred from one medium to another?

There are a number of potential problems and most of them relate to the encoding used to store the data. Binary Large Objects (BLOBS) may be encoded in a legacy format and require conversion. Text may be encoded in legacy or non-standard formats within the database records. Dates and times can have custom formats that may preclude easy export. But there may be other less tangible issues. For example, the database may have specialised libraries providing key server-side functions. Identifying these potential bottlenecks early can smooth the transition process.

Functional specification

The second criteria is intended to provide a description of the core functions of the pre-existing application that need to be transferred to the new user interface. Experience suggests there will be little or no documentation for any given application. So in the absence of that it is useful to list the requirements for the revised version. It may also be useful to review the list. In one example that I reviewed the mapping component of the application was no longer functioning and had in fact been replaced by a different, now external, application. It may also be useful to review the whole application in this light. Could the functionality be replicated more simply and easily in a different framework? For example custom code in the original application for performing quantitative or qualitative analytics might be better served from an external application.

Externalities

The third criteria, externalities, is intended as a review of external dependencies on the at-risk application. There can be a wide variety of potential external references to a live application. Externally held public links are a typical example. As an example, Wikidata and Wikipedia hold URI/URL links to data held in one of the sample sites. These links may need to be maintained despite legacy protocols and legacy parameter references. How far to extend this is a difficult question. For example, should links be sustained across an entire application on the grounds that bookmarks and other private sources should be maintained?

Measure thrice, cut once

To conclude, migration of applications from this period appears relatively straightforward and does not offer the challenges implicit in earlier decades of software development. In many ways it is a like-for-like substitution. Database for database, interface for interface. Nonetheless it is worth examining in some detail each application and its construction. The adage “measure twice, cut once” applies well in this context but perhaps “measure thrice” is more appropriate.

Finally, I’ve not mentioned the initial premise of migration and upgrade. The upgrade path is undoubtedly the more challenging. Representing a rework of both the underlying data and the frontend. It’s personal opinion but the three criteria still provide a useful mechanism for starting the process. It is likely the database contents, for example, will need to be retooled, possibly extensively. Grappling with the structure is a practical starting point.

This article has skirted over a panorama of topics such as user interface redevelopment, development frameworks and software engineering techniques, porting and redeveloping static content and assets. This is largely for the sake of brevity.