Upgrading Old Technology
Old technology is everywhere. Recently, we had an opportunity to rewrite an application that we originally wrote in 2005. We could hardly believe it was still in production in 2017! Clearly the long run in production was a testament to the cutting edge code we designed, but the company was clinging to an outdated workflow because they were afraid of what it would take to upgrade it. We seized the opportunity to upgrade the application and move it to Angular which provided the client with a new application with an updated workflow to match their business.
We learned a lot of lessons from this project, but the important skill we learned was how to quickly upgrade an old app and move it to a new platform. The lessons we learned have become our product process for upgrading applications. We have outlined our steps because we think it’s important for our clients to understand how we approach upgrading outdated technologies.
Step 1 – Identify features
This very important step is the start of any application. It’s time to take inventory of what we are going to build. We recommend using the previous application as the guide for what features are important. We create an epic for each feature and then break them down into stories that are more manageable. This process also allows the management team to assess what features are necessary, what needs to change, and what features might need to be added. Once we believe we have the stories sufficiently vetted, we begin to estimate each story by assigning points using a standard fibonacci sequence. We continue to break the stories down until each one can be completed in a week or less. Once everything is estimated, we understand how long it will take to complete the application and we assemble the rest of the team.
Step 2 – Secure backend
The great thing about the backend on an existing application is that it is typically tried and proven as reliable. The problem with it is that it usually doesn’t follow best practices or modern conventions, so we often have to modify it. It can be as simple as replacing XML serializers with JSON serializers and as complicated as converting RPC style calls to REST. Each application is different and since the backend is engine of our high performance sports car, we need to make sure it’s going to be well prepared for the open road. The goal is to make as few changes as possible, but get it ready for the new web application. The planning of this step happens during Step 1.
Step 3 – Process Planning
Old technology comes with a lot of outdated infrastructure and/or development processes. It’s important to take some time to talk about where this application is going to be deployed, branching strategies, continuous integration, coding style guides, code linting, automated tests, continuous deployment, source code management, etc. This step usually takes the least amount of time, but decisions here can greatly impact the delivery of your product. A little bit of planning can go a long way in making sure your application is successful.
Step 4 – Lift and Shift
This step is where the coding happens. We start out with generating a Angular-CLI project and then lift and shift each feature from the old application to the new one. Using our custom schematics, we are able to quickly generate the redux patterns necessary for each feature. We are able to quickly jump in to define models, create actions, implement reducers, and code up our async operations into effects. We break down each feature during Step 1 into smaller and smaller pieces and now we get to create reusable presentation components that display data and emit events. This makes testing easier and maximizes components reusability. The top level containers handle system and user events while managing data from the store. We create automated tests for each action, reducer, effect, component, and container so we can reliably validate each one.
Step 5 – Quality Assurance
Our final step is an ongoing process that occurs at the same time we are performing Step 4. As each feature is developed it is peer reviewed before merged, it is checked for linting and style, tests are run, test code coverage is checked, and builds are verified. This stringent process is defined during Step 3 and ensures that all code works and follows best practices before it reaches a Quality Assurance (QA) engineer. Each story and epic must be approved by QA before it is considered complete. Once every story has been verified by QA, the application is complete.
Upgrading old technology doesn’t have to be difficult or extremely expensive. It does take a developer with Angular expertise to generate the best plan to approach the problem and move your product to a platform with a future. If you haven’t looked at a client-side MVC like Angular yet, it’s probably a good time to check it out. I would be happy to get onto a Google Hangout and give you a demo of what is possible. With old platforms like Flash, Silverlight, and many others being deprecated, it’s time to get them upgraded before the clock runs out and your security risks go up.