Two strategies for migrating an existing application to a new framework

Finally got your migration budget approved? Is that Angular vs. React vs. Vue giving you headaches? Not sure whether it’s worth moving to Node.js microservices, because your team already knows JavaScript or if you should have them learn Go? Wondering what options you have, to migrate your existing product to a new framework? These are all valid questions anyone should ask when planning to rewrite their application/product.

If you’re going shopping for new tech, here are two options you can use, to migrate your existing application to a new framework. I’ve seen both of them at work, and both work pretty well if you know what you’re doing. If you want to know what you shouldn’t be doing, look no further than this article which details why big software rewrites fail.

The incremental migration

One of the natural things to do when rewriting your application is to try and migrate it incrementally. This approach is fairly common in established companies, where shutting down development for some time, to rewrite the whole application is a no-no. The thing is that sales still need to happen, complaints for the old software will still come in, bugs will appear and support still needs to be provided.
This type of migration requires a lot of planning and ping-pong. It is different form one company to the next, but without careful planning, you could put yourself out of business pretty fast. If you need to maintain existing functionality and inch in on your migration goals, this is the way to go. It can work very well if everyone accepts the fact that they’re going to have a lot of talking and meeting and syncing and discussion to do.

The drawback to this approach is that progress might slow down due to reuse of old patterns that might not work well with the new architecture. The biggest risk is when there’s to much pressure and context-switching for the team. They might decide to reuse parts of the application that aren’t designed well and this hinders the original effort, of steering away from the “old world”. Everyone should be aware that the current level of technical debt is not the same as it was two years ago, when the project initially started.

Building a competitor

Here’s a different approach: you set out to build a competitor to the existing product. Build a product that would send your existing product down in flames. This option might require more time to get to fruition, mainly because everything is written from scratch. The biggest objection some people might have is that it will take too long until a working product is available, compared to an incremental migration, where the original product is still providing the functionality users need. The biggest advantage of this option is that there’s more knowledge about the stack than two years ago, when the original product was built. Another advantage is the years of real-world learning and experience the team has accumulated under their belt, hopefully a solid team, as well as insider knowledge about your competition. It’s like you have an insider on your competitor’s team.

Just as with incremental migrations, one of the biggest concerns is that the team will be tempted to “reuse” concepts from the original product, that didn’t quite work, when push comes to shove. Extra care should be taken, with regards to the concepts that are being ported into the project from the “old world” product.

These are the two options I’ve seen at work throughout the years, in companies of different sizes and with different technical skills. I’d love to know what other options do you know, besides a hybrid approach between the two options above? Use the comments section at will!

Not sure how to choose?

I wrote an article back in 2016 about choosing a new technology. The article is actually a case study, which goes through the criteria I use when evaluating new technologies. I believe your filtering criteria are the most important. Everything else is just fluff.