How to migrate a web application to another technology in a seamless, incremental way

manpreet Best Answer 2 years ago

I have a Coldfusion application, developed without any framework and almost no architecture. I'd like slowly migrate some part of the application to some kind of java based web application framework.

The original application must still be the main application all the way until the end of the migration. The application has user and sessions and a lot of functionalities, not easy to decouple.

I'm looking for different ideas.

For example I could try to develop a REST API backe nd and start to use it from the ColdFusion application until I'll have Coldfusion only as front end. This process must go hand by hand with database refactoring and migrations, ie. new API must use its own database, so I guess that decoupling of database will be necessary (and probably database synchronization issues will arise)

But I would like to switch also to a different front end technology. The situation would be like: Users login in coldfusion, enter main dashboard in Coldfusion and next "some" functionalities will be handled by another framework. That means a template engine is able to understand the user, his roles, his permissions, reproduce the same graphical layout, but it should serve the content with another technology.

Final result must be that all functionalities are migrated to the new technology.

I mention Java as it is in some way related to ColdFusion, but any web application framework could be used in principle. I also think that Coldfusion is used in the original application is not relevant. The fact that no framework is used, probably gives me more flexibility.

Any architectural suggestion is welcome.

manpreet 2 years ago

I recently did this very thing. A spaghetti code app developed by a graphic designer with a CFML book, a MSSQL database so denormalized not even Bizarro could have wrestled it and won.

What we did was we left the old app in place, built a new one and tested it extensively, perfected it, made sure it was capable of evolving (and it has). Then we flipped a DNS switch and sent out an announcement that the new system is the only option going forward.

I then built an archive feature that provided read-only access to the mess that we left behind. Some day, if the app owners want to migrate that data, we can try that (it won't go well), but generally the vast improvements have convinced everyone that the old stuff is only needed in that read-only mode.

Obviously that means reporting only goes back to the first day of the new tool, but it was either that (with a 4 week dev time) or they get it all and it takes 8 months doing what you described.

It's worked very well for us, and it's probably been the best-received work I've done here.