Okay, you got that unpopular task – to get your hands dirty with pretty old, legacy apps and code that probably nobody wants to look at. And what now? You can cry, whine and blame your boss for that decision or start getting the job done without excuses and complaining. Whatever your choice is, that job needs to be done. And yes, it may not be the best thing ever in your life to work on but you can LEARN A LOT. As you must go through that, my advice is – to make it as easy as possible and just start working on that and try to learn every single step and maybe write some things down. I can share some tips and tricks you can implement to make that journey easier.

Initial steps

Even if you don’t really have to understand the business domain, try to gather as much information as possible about your legacy code and try to understand what is going on there. At least you will know why is it important to migrate to the latest tech stack and then you will hopefully do it with more willpower and more enthusiasm. It was at least in my case – I wanted to work on meaningful stuff. Besides that, try to use the current version of the app and try to visualize, or understand what and how can be built using the latest stack. It will help you with estimation and planning.

Do your research

The second thing is to research technologies used in that project and understand what they are used for even if you have never heard of them. That will give you an overview of how it works and the power of choice for implementing a modern solution for a new version of that application.

The third thing is to analyze the package.json file and take care of what packages and versions are used in that project. It can be tricky if your project is a huge monolith created from smaller apps. In that situation, use some tools like Google Sheets and write down specific versions of each of those packages.

Last but not least, make a plan for what and when you will work on and try to estimate how long would it take to migrate everything to the latest tech stack. This part can be tricky and pretty hard to estimate if you don’t work on the first step or if you don’t work on it properly. And don’t forget to request as detailed requirements as possible. If there is some documentation on that project from the developing stage, it would be nice if you can get it. If not, try to gather and write down every single detail about specific functionalities.

Get your hands dirty

Running an app locally

Okay, now that you got enough research, you have a plan and you know what you are supposed to do, let’s start.

The first thing to do is to run that app locally. Yes, it may seem easy but sometimes it may take a few days to run it locally. Why is that? Because if you have a large application with lots of dependencies and if you keep in mind that it is a legacy code, you should understand that probably some dependencies are pretty old, unusable, or even deprecated and there is no support for those libraries anymore. So that is why it may be tricky just to start your project locally. If you do not have those kinds of problems, you are lucky!

If you have any problems with running it locally and are stuck there, try to ask for help. Ideally, some developer already ran it locally some time ago and has node_modules folder with specific versions of packages needed to run it. Try to research who that might be and contact him to send that whole folder to you. Then paste that folder into your local project and your app should run.

If there is no such developer and no signs of making that app alive, hopefully, there is at least some server where you can see how the app is working and parallelly look into the code and try to understand piece by piece what is going on there.

If there is no live version of that app, probably rebuilding is the option you should choose. Sometimes it is also the easiest option.

Start working on migration

Now that you ran your app locally or just went through a live version of it, you can start understanding what is going on in that code, how everything works, what are the requirements, and how your app should behave.

If your app does not use the latest technologies you work with, obviously it needs a rebuild.

If it does, you should take a closer look at the differences between the old version used in your legacy app and the version you want to use. Make detailed research about every single dependency. Once you do it properly, it will save you a lot of time during the migration process.

How to migrate it

When you’re done with your research, start migrating piece by piece. Separate your concerns into smaller chunks so you can track your progress and make your work easier. 

For example, do not try to migrate all the stores, all the styles, and all the functionalities at the same time. Separate your problems and make priorities. If the highest priority is a change in the design that the user can see, make it your first step. If additional functionalities are the highest priority, make them your first step. And be aware that you will get a HUGE amount of errors during this whole process. But again, solve them piece by piece, error by error.

If you work on an application that has some pretty old or even deprecated libraries, I am sorry, but you’ll have to find a way to migrate it onto the latest version or find some alternative library that will not ruin some behavior inside your migrated application.

It happens, it frustrates probably anyone, and it is not the best thing ever to work on. But remember, you will learn a lot and be wiser and stronger as a programmer!

Don’t be afraid to ask for help

If you are stuck, always try to ask for help, especially if you are doing something like this for the first time.

There are some really good libraries out there but without proper documentation or even without documentation. In those kinds of situations, you need to understand what is going on in all of the code inside that library. Most of the popular libraries have an active community so they have lots of comments, discussions, and problem-solving posts. You can find them in the discussion tab on their GitHub repository. Another useful site is Stack Overflow. You can also ask ChatGPT for help. It can have a pretty good understanding of your errors. 🙂

While migrating, I suggest testing every single feature by itself. Dedicate some time to testing and do it properly. At the end of the story, you are the one who will have the most benefits from that testing process. You will ensure your code is good to go and there will be no reopening or fixing some dozy issues.

When you finish your migration process, you are ready for the next step in this whole process – testing.

Test your work locally

As I previously said, the easiest way to test your code is to test it feature by feature. So, while you are implementing some features, it is a good idea to test them immediately. By doing this, you will save time while testing your app as a whole. When you finish every single feature and your app is ready for testing, make sure you are the first one to test it. It is a really bad feeling when the tester finds some obvious bugs or reopens some ticket that you marked as done. Make sure you test the whole app and test everything from the requirements and documentation. If you find bugs, make sure to fix them before sending a request for testing to the QA engineer.

Deploy your app to the testing environment

When you’ve tested everything locally and it works fine, try to set everything up for deployment into the testing environment. It may be good to set up CI/CD pipeline, if needed, for easier further development. When you’ve deployed everything into the testing environment, you are good to go on to the next step – testing your application there.

Test your work in the testing environment

Make sure you test your migrated application on the server in the testing environment. By that, you will ensure everything is set up correctly and it is ready for deployment to production (if there will be no problems found by the QA engineer).

On the other hand, if there are some bugs or some things that need improvements, you still have enough time to fix them and make patches.

Request regression testing from the QA engineer

Now when you are sure that everything is working properly locally and on the server (testing environment), make sure you request a detailed review from a QA engineer. He or she should do regression testing that will ensure your application is ready for deployment to the production environment.

Conclusion

Dealing with legacy code can be tricky and it often causes frustration. But if we take a look at it systematically and make reasonable and organized steps, we can make it a bit easier and more fun. 

Hopefully, this short guide will help you someday and you will remember these steps. If you will have any questions, feel free to contact us.