Leaving legacy behind
The goal of this project was to migrate all legacy applications running on Windows Server 2003 to Windows Server 2012. That meant upgrading the applications and their code so that it was compatible with the new Windows Server. We were aware of the fact that even Windows Server 2012 would become outdated fairly quickly so we actually upgraded the applications in a way that would support future versions of Windows Server as well. How did we do that? To find out, keep on reading below!
Dealing with Legacy
The client had a wide variety of applications running on Windows Server 2003. That included Web Apps, Windows Services, Desktop Apps, SQL Jobs, and even Crystal Reports. Some of the applications were using very old versions of the .NET framework, like version 2.0 for instance. Apart from the .NET framework, a lot of the other libraries and plugins were also outdated. During the time these applications were developed there was no concept of Nuget, which meant that these third party libraries had to be included as DLLs/references in the project/solution. This is why upgrading all these apps was not a simple task!
Making it Modern
To be able to migrate so many legacy applications in a timely manner, we had to come up with a plan. The plan was to breakdown the effort and group it based on the types of apps, and then distribute it over a period of time. That way we were able to focus on specific apps and work on upgrading them one app at a time. There were two very significant aspects of the upgrade. These were:
- 1) Using the latest .NET framework so that the applications would be compatible with at least the next 2 generations of Windows Server operating systems. This meant that we had to update all the deprecated code and use newer methods and functions in order to build the apps for Windows Server 2012. Not only were we able to successfully test the apps on WS 2012, but we also confirmed that the apps were ready for WS 2019, if and when the client decides to move to that version.
- 2) Using Nuget for all third party libraries. This was a no-brainer. We had to discard all the old DLLs simply because it is not practical to manage third-party libraries manually; especially not in the age of platforms like Nuget! That is why we downloaded the latest libraries from Nuget wherever they were required and by doing so made sure that Nuget would manage the on-going upgrades and versions. Again, we had to replace a lot of old code but in the end it was worth it.
Another important part of this project was to enable the client for the future. The existing application infrastructure of the client was too diverse and hard to manage. That is why we laid out a plan and vision for them to convert all their apps into Web Apps. Web Apps are easy to manage, easy to deploy, and easy to access. We are currently in the process of transforming all the user-based apps into web apps so they can be easily managed going forward.
Approach & Effort
This project took about 5 months to complete. We tackled the migration process by grouping related types of apps together. Then we focused on upgrading each set one app at a time. As part of the deployment process we kept old versions in place on the old server, and deployed the new versions on the new server. This way we could easily roll back in case the new versions did not run properly. Once all the apps had been successfully migrated over we were able to free up the old Windows 2003 servers, which resulted in cost-savings for the client.
The App Sparq team first took the time to understand the current state of applications at Mr. Lube. Then effectively laid out a sustainable foundation for ongoing application maintenance, testing, and new solutions development.