The virtues of not transforming (sometimes)

Today’s world is all about transformations, digital or not, transformations that we must embark on, embrace, celebrate, promote and rejoice.?

However, when looking beyond the hype, virtues of deliberately doing the opposite can be found, consciously deciding not to transform.

The case at hand: mainframe migrations, and more specifically, Raincode’s IMSql solution to migrate software systems based on IMS/DB and IMS/DC.

Not transforming means?keeping the application source code intact, to minimize disruption and entropy, to ensure that the maintenance teams can proceed unincumbered – an often overlooked problem with far-reaching transformation projects, if you ask me.

The underlying infrastructure for transaction and database processing is fully modernized for scalability and cloud-nativeness, but IMSql is all about ensuring that this does not alter the application source code that represents business intelligence. One can even consider running the same application, based on the same unaltered source code, on both the mainframe and the target platform for some time.

This paradigm extends beyond code: IMSql allows for the?migration of IMS/DB data as is, without transformation of any kind, irrespective of its quality, compliance, idiosyncrasies, normalization status and more. Again, that does not mean that the application data is thrown in a dark pit and becomes useless in the process:?au contraire!?The migrated data is made available for read and for write using standard SQL for ad hoc queries and integrations in new developments using modern technologies. But IMSql does not put preconditions of any kind on the data. It does not require analysis, assessment, remediation, cleansing of large amounts of it, which can turn into a project and a significant risk factor in its own right. Instead, IMSql turns data migration into a strictly deterministic process, calibrated as a linear function of the size of the database.

IMSql’s non-transformational nature changes the game of mainframe migration, by avoiding two major kinds of uncertainties:

• What happens to my code after the migration? What will it look like? What skillset do I need to maintain it? What happens to the years of domain expertise that has been put into it?
• Is my data well-structured enough to be migrated? Does it require cleansing? Who has the functional expertise and authority to decide how to cleanse it? Will my application behavior change in some subtle way in the process? How is that going to impact testing, and the overall migration project?

?Not transforming has its virtues, sometimes