With microservices and the benefits of cloud-based architecture attracting so much attention, it’s easy to forget the current reality for many businesses. Even if you’re looking forward to a cloud-based future, today’s applications still need supporting.

One of our government clients found itself in this situation – it has a suite of legacy apps sitting on costly physical hardware, which has to deal with large volumes of traffic for peaks that occur just once or twice a year. The problem is that having to provide this capacity all year round is expensive and inefficient.

Re-writing the apps from scratch for the cloud wasn’t an option (because of time and costs), but neither was keeping the servers going for the remaining life of the apps (which could be many years).

Equal Experts was asked to propose a solution that would allow our client to retire the physical servers, without re-writing the applications or interrupting the services provided by the legacy apps.

Rethinking replatforming

Putting the apps into the cloud would allow us to answer the question of traffic, of course – we could simply scale it when the predicted peak arrived.

The challenge was in making it happen in a timescale short enough to make it worthwhile. Many of these applications are old, big, and complicated – and we need to get them off the physical servers as soon as possible, while keeping everything running. The longer it takes, the lower the benefit – so our solution had to be repeatable, and work for a large number of  legacy apps.

Because of this, we chose to work with the apps in a different way – by intelligently slicing them up so that any common services or integration points (such as authentication, or simple content serving) can be shared by the remaining portions of unique code. These can then be easily ‘plugged in’.

Before you begin…

Of course, we needed to be sure this approach would work. For our proof of concept, we carefully chose an application that had very few integration points, as at this point we were just aiming to show it could work in the cloud. But at the same time, we wanted it to be genuinely useful. We picked a simple content application, since practically every other app would need to be able to serve up content too.

Think it’ll work? Then go for it

Our proof of concept worked well, which gave us the confidence to proceed. As we want to get all the legacy apps working in the cloud as soon as possible, it made sense to aim high for our second app. We deliberately chose what might have been seen as the riskiest one of the lot – it has a lot of integration points and sees a lot of use. After all, the more functionality we can get working in the cloud, the sooner the servers can switch off.

Using this approach, we demonstrated our early hypothesis worked, gained confidence, and now we’re working hard to making it happen. We’ve even been able to automate the testing process, which had previously been done manually for these apps. This had the extra benefit of discovering bugs that would previously have been left to manual testers to find (or not).

Saving people and time

As a result, we’re reducing the amount of time it takes to support the apps, as well as moving them off the old, expensive architecture. It just goes to show that with the right approach, even legacy applications can benefit from modern agile approaches.