Monolithic App Migration

Background

In 2020, my Senior Business Application Engineer of 26 years was unexpectedly laid off by senior leadership and the parent company. His role had been to build and maintain many of the Business’s Accounting, Human Resources, and Media departments’ internal utility tools, applications, and data feeds. Because of the sensitive nature of the data he had access to, and against my advice, the business leaders had chosen not to have any redundancies or fallback plans if he were to ever leave the company, so when he was laid off all of his institutional knowledge about these applications went with him.

Within 24 hours of his dismissal, applications that required payroll data began to throw errors. The payroll system did not allow generic logins, so the system was tied specifically to his [now inactive] account. Within a week, many of his applications were proverbially on fire and the business leaders assigned remediation tasks to me.

I gained access to his source code, servers, and databases only to discover that there was very little documentation and it had been built in legacy .NET and VB architectures that did not compile on current versions of Visual Studio. Additionally even though he supported multiple departments individually, the code itself was monolithic in nature, and complicated by 26 years of unmerged and orphaned branches in source control. I became a detective, putting all the pieces of this code story together to gain an understanding of the system.

Remediation Plan

The first thing I had to do was analyze every issue that had been reported and prioritize those issues by severity to the business’s continued operations. I met with stakeholders on each of the internal operations teams to determine viable fallback plans, gain an understanding of the services each of these custom utility applications performed, and determine a path forward. These interviews also contributed to my requirements-gathering task as I began to plan for a long-term parent company-approved solution.

The desire of leadership and the parent company was to find automated cloud-based solutions and eliminate the need for an FTE business applications developer. Ultimately, the applications I migrated were categorized into three buckets:

1. Microservices connecting parent company cloud-based data to third-party providers with automation through Jenkins.
2. Manual fallback plans discovered during the interview process that sufficed as end solutions.
3. Off-the-shelf solutions to be migrated by the stakeholders of the individual departments.

I personally wrote the NodeJS microservices that connected the parent company data to the third party providers, and set up the Jenkins server and automation processes. I supplied requirements gathered from my stakeholder interviews to project management and the parent company to determine the appropriate off-the-shelf solutions. I disabled databases and worked with IT to decommission servers that were no longer necessary. Finally, I wrote extensive documentation to make sure that the knowledge was shared across the organization.

Summary

After months of detective work, meetings with leadership, stakeholders, third-party vendors, and the parent company data providers, and plan execution, the final outcome was a successful solution that everyone was happy with. Additionally we were able to eliminate a significant amount of sensitive data that was being duplicated in databases as well as cut significant infrastructure and overhead costs.