Interactive cycling platform

The rebuilt platform followed a service-oriented architecture, which is what made a gradual migration possible in the first place. Instead of replacing the old system in a single cutover, our team split functionality into discrete services, each with a clear part of the platform. New features were built as services in the cloud, and the same services could be called from the old application, so a capability only had to be written once.

During the transition, some functionality still existed only in the legacy system. To avoid disrupting users, the old and new systems continued running side by side, with users retaining access to legacy features until their cloud-based replacements were ready. This decoupled architecture allowed both platforms to share modules and move users across known transition points, rather than forcing the business into a risky one-time migration.

Initially, the project was hosted on a virtual machine using Internet Information Services (IIS). Our team orchestrated a migration to Azure infrastructure, with Azure DevOps handling comprehensive management. We also established two distinct services, the Cloud and the Studio, to handle different parts of the project. As part of the move, we established distinct services, the Cloud and the Studio, so the parts of the platform aimed at central management and the parts aimed at the in-club experience could be built, deployed, and scaled on their own instead of moving as one block.

The move to Azure also changed how the team handled configuration and data. Instead of keeping settings on the server next to the application, our team introduced a dedicated way to store settings and other sensitive data securely, separated from the code that used them. This separation made the deployment pipeline safer to automate and helped streamline onboarding for new locations.

Our team also configured CI/CD in Azure DevOps. Builds and releases became defined pipelines, so changes could move from commit to deployment through a repeatable process rather than a manual one. This directly addressed one of the biggest limitations of the old WPF application: updates no longer required software to be installed separately on every machine. After the migration, each location automatically received the latest version once it was deployed to the server, while users accessed it through the browser.

After migration, we remove the burden of managing version compatibility between desktop and server components, so any feature can be pushed to the test environment independently. We also built a dedicated module for hardware-related testing that emulated the bike’s activities, heart rate sensors, and other dependencies across multiple configurations. As a result, QA no longer had to wait on a shared server or a full release to check their work. They could deploy the specific components relevant to their tasks on their own and test them in isolation, which shortened the loop between building a change and confirming it worked.

Once the platform was running on Azure, the next question was how to keep adding capability without making the core project heavier. As the platform evolved, our team prioritized building new capabilities as microservices over expanding the core project. Each new piece of functionality became its own service with a clear boundary, rather than another addition to a growing central codebase. This kept the system’s parts independent, so one service could be changed or scaled without affecting the others.

To support that model, our team moved to Linux-based machines and adopted containerization with Docker. Packaging each service in a container gave every service a consistent and predictable environment from development through to production, while also allowing the team to run services more efficiently on the underlying infrastructure.

This was not the first step away from the original Windows setup. In the first phase of migration, the platform had already moved from a Windows VM to Azure managed services, which also run on Linux-based infrastructure behind the scenes. The Docker phase built on that progress by giving the team more control over service packaging, deployment, and runtime consistency, while keeping the platform on a lighter and more scalable foundation than the original Windows-hosted admin system.

This was the second stage of the migration. The first stage moved the platform away from a single server and onto a straightforward Azure cloud setup. The second stage went further, from that initial cloud setup to Docker and a container-based infrastructure capable of hosting a growing number of independent services.