Even the best-designed systems have to be replaced eventually.
Business environments change, technology changes, and there comes a time when it’s no longer economically viable to support a legacy system.
One of the ‘obvious’ things is to guarantee that no business features will be lost during migration; as if it was transport of some material goods and nothing can be lost. It’s called feature parity.
The promise of feature parity is not to lose anything from the previous application and to ensure all the existing features are there in the new system.
There are feature lists available to compare the new application with the old one to verify that all the features are in the new application.
We all know that, naturally, so what is this article for?
The old system represents the state of mind of decision-makers from 5 or more years ago. They also accumulated the thousands of changes required to be done over the years.
The system becomes bloated, used in a different way than it was planned and there are more and more features that are not used anymore . . . and there’s very little interest in removing them. Especially when new features are built on top of them, thus legacy unused code creates hard or impractical to remove dependencies.
Many are not aware of this fact except development teams trying hard not to break things while introducing new features and fixes. Old systems are also very often built as monolithic applications making it a very complicated maze of dependencies that are hard to manage.
Now the time has come to move to new technology, for instance, a cloud native.
Many decision-makers prefer the ‘do not touch it unless necessary’ approach to ‘save time and minimize the risks’.
→To change or to pretend a change – that is the question
Surprise, surprise, there will have to be a ton of reverse engineering performed, as the documentation is almost certainly out of date and many creators of the system work elsewhere as it is 5 years later, so it’s a very different company now.
The cost will be much higher than just a copy & paste of all the features. Businesses will end up with the same old legacy app just maybe running in a new environment with the latest versions of frameworks, but it won’t really be providing any significant business value to anyone, internally and externally.
According to our practice and research, up to 30%-50% of the features are not used anymore or used very rarely.
Very often the choice of feature parity is a wasted opportunity to think about the features and their business priorities again, only to recreate what matters now and in the future. Optimizing it using the newest technology and removing old bottlenecks slowing down the process of digital transformation.
It’s a perfect opportunity to redesign both functionally and technologically. Of course, we don’t mean the infamous analysis paralysis, but an agile approach, using the old system as a source of valuable observations and lessons learned.
There are new architectural patterns that will make it easier to change and maintain the application in the future, turning it into a digital product, and it would be very beneficial for the organization to take advantage of them.
→ Technology Trends 2020: Predicting IT at the Turn of a New Decade
We, at Avenga, understand you want to migrate as fast and as effectively as possible. Therefore, we recommend thinking again about what you really want and what your business really needs, taking into account the latest and greatest achievements of technology, to not just move but significantly improve your digital business at the same time.
And you don’t have to do it in one big shot, our tools such as couper.io and our methodology enable us to migrate in multiple steps, from the most important features to the nice-to-have ones.