Please note: The English version of this success story was translated using AI to make it accessible to our international audience.
Imagine you’re taking on a new leadership position within a government IT department. Your predecessor has retired, and a handover couldn’t take place. You start your new job and get to know the new environment. Sooner or later, you stumble across a central IT application that manages all activities.
You’re in luck: The application Jira Service Management in combination with Confluence isn’t unfamiliar to you. You’ve also encountered this tooling at previous employers. So, initially, it’s not entirely new to you.
Imagine you’re taking on a new leadership role within a government IT department. After a short time, however, you realize that your Jira Service Management instance is configured differently: A large portion of the processes are automated. Incoming emails are processed, issues are created, and depending on where you are in the process, emails are sent or interfaces are called (based on automatically set parameters).
In theory, this is great! Except for the fact that there’s hardly any documentation. Neither the technical aspects nor the processes surrounding the platform’s operation are described. Much is solved using Groovy scripts and ScriptRunner, but it’s inconsistent and not everything is covered. The tooling is run on rented hardware at your central IT service provider. You’re unaware of the administration and responsibilities.
The challenge for you: The tool isn’t the only thing you’re responsible for. Your daily work is keeping you busy. You don’t have the time to delve deeply into the technology and environment yourself.
This is a common scenario for a software legacy. There are many reasons: retirement, internal or external changes, etc. Often, there are applications that started small but have become process-critical over time. Documentation has been neglected, deprioritized, or is outdated. There’s no one left to ask questions. You’re initially on your own.
And this is where metamorphant comes in. As experienced consultants in government agencies and large corporations, such scenarios are part of our daily work. The applications aren’t always critical to business operations in the same way. But what they all have in common is that “business as usual” would be irresponsible.
Our goal is to transform an orphaned software legacy into a stable state. In this case, the desire was to retain the applications and continue operating them stably and securely. The decisive factors here were the high level of acceptance and the degree of process criticality.
Together with the client, a target state was defined in workshop sessions, and technical expertise was developed on the client’s side. The following deliverables were produced:
The results were then applied in the further course of the project. The goal was to achieve a high level of maturity based on these blueprints and to return control of the system to the client. Future employees should be able to learn the system easily. The solution should be practical and fit the client’s organization—not just a token gesture to ease their conscience.