Migration of Legacy Systems Should Be Continuous

Development teams see the benefits of continuous processes. Most companies now use Continuous integration (CI) and continuous delivery (CD) in support of DevOps. It is considered common or at least the goal of modern development. But modernization projects still talk about multiple year time frames with different phases where each system will be deployed. This is a waterfall approach.

Everyone understands that projects of this magnitude require time and planning. To decommission existing systems, enterprises need to make sure the new system has the correct functionality, get people to use that system, work out the kinks, etc.

But this is the whole point, you can’t confirm the functionality or work out any kinks in a box. This is why development became incremental and then continuous in the first place. Plus over a multiple years period, plans will change to keep up with consumer and economic changes The goal shouldn’t be rigid. Companies need flexibility even when modernizing and they need to learn during each step in the process.

The question is why is migration planning still using a waterfall methodology?

The answer is easy to explain but tough to fix using traditional methods. For companies to modernize in a more continuous process, the new functionality needs access to existing systems. Otherwise, enterprises can’t give users enough functionality to be useful and the users will revert to using old methods. But creating integrations takes time and the common ways to create them typically include middleware, which takes additional teams and slows down testing.

All of the additional time and effort means development grinds to a halt and defeats the whole purpose of continuous deployment, i.e. to get feedback and show incremental improvements. So instead the migration teams plow forward and build larger systems that don’t need as many integration points. But that leads to larger risks since many of the systems haven’t been tested by users and the business doesn’t see benefits for a long time.

A better way to go is to use automation to create the needed integration points as they are needed. You can run scripts that parse the legacy information and analyze what interfaces are available. Then automatically turn those into easily consumable modules stored in an accessible repository. Now they are ready for consumption by any developer to turn into APIs the rest of the team can leverage. This way everything is ready on demand. Read more about this process in this ebook.