4 ways to move your custom legacy apps to the cloud

Change comes in all shapes and sizes. Some changes we welcome, and others we shy away from. The pandemic has placed a huge emphasis on the need to change business operations and many organizations have been put in “do or die” situations when it comes to going remote, virtualizing desktops, and — perhaps more significantly — deciding whether on-premises applications should stay, move to the cloud, or get replaced entirely.

Such decisions have been a long time coming. On-premises IT footprint has shrunk over the past 10 years with the emergence of the cloud, SaaS applications that are highly customizable, and composable business principles. We no longer live in an office with a server room, and our feet are no longer tangled in large spools of wire beneath our desks. We’re at home. We’re mobile. And we’re ushering in a new era of IT.

So it’s no longer a question of when you’ll move to cloud but how. Here are four different approaches to consider:

Approach 1: Lift and shift

The quickest and easiest of all four approaches, lift and shift requires no code or architecture changes and involves simply putting an application into the cloud using its current deployment architecture on new “hardware.” This popular option is available to enterprises following the emergence of infrastructure-as-a-service in both public and private clouds.

For those looking to move quickly, efficiently, and cheaply, it doesn’t get much better than this. This may not always be the most optimal migration strategy, and there are certainly some downsides to consider.

The largest drawback of this approach is managing the long-term scalability and manageability of the application. Born in an on-premises environment, a legacy application is accustomed to (and at times built for) a certain workload. Therefore, before you lift and shift it into the cloud, you should first thoroughly test performance and scalability, especially when separating the users from the application or the data by a WAN. Without proper testing, you’ll never know which straw will break the camel’s back, and you could find that an influx of customers, users, or even staff, tips an application over the edge and causes it to perform poorly. If this happens to just be an email server application, or a time entry system, the damage may not be too bad, but if you’ve unsuccessfully lifted and shifted your sales platform into the cloud, your bottom line could take a big hit.

Approach 2: Rebuild/refactor

On the other end of the spectrum, we have the option to rebuild or refactor your legacy applications. Refactoring is the process of moving the application to a public cloud and rearchitecting it to take advantage of native cloud technologies, such as platform-as-a-service. This requires significant code changes and is a long-term investment. Knowing that many custom legacy applications have ties across the business, dependencies on other apps, and workflows to adhere to, it’s vital that every relationship is updated so that there are no interruptions once it’s in the cloud. This is the most sustainable approach to migrate an application; it will be scalable for any increase in demand or usage, will be available remotely, and will continue to meet all the needs of the business. By adhering to modern, cloud-native architecture best practices you can ensure your application will be scalable and supportable in the long-term.

The main downside here is the cost associated with refactoring. This is a time-intensive process and involves essentially rebuilding the entire application in a new environment, with new technologies and new code. This may mean outsourcing the task to migration specialists if your team is not equipped with the right skills. This can be a big project, but it will bring the application into a supportable, relatively future-proof model.

Approach 3: Re-platform

Re-platforming applications is the middle-ground approach between lift-and-shift and refactoring and typically involves making “easy” changes to the application architecture — such as changing the way the app interacts with its database to take advantage of serverless database cloud services. Assuming the application isn’t overly “chatty” and performs well when separated from its database via a WAN, moving the database tier during a re-platforming project could be the best place to start.

​When re-platforming applications, you typically don’t change the client-side, but the way it interacts with the data may be different. To ensure nothing is left drifting in the cloud, it’s important to closely monitor the application once it’s been re-platformed. The key difference between this approach and refactoring/rebuilding is that it’s quicker and so is often the first step in the app modernization journey. You may not catch everything in the re-platforming process, and issues could arise on the fly. As long as you know this going in, and you have backup plans in place, this approach is very valuable and provides a strong starting point if you decide to refactor at a later time.

Approach 4: Get rid of the app and buy a new one

The final approach is to get rid of your legacy application and buy a SaaS one off the shelf that you can customize. This is a tricky approach to prescribe and is only viable in certain situations. If you’re still hosting your email server, then by all means, get rid of it and get Office 365 of Google Workspace. In a similar vein, any application that would be considered common in the workplace, such as CRM, HR management, or an accounting solution, is also very likely to be replaceable by a new SaaS product made for the cloud. The times you’d avoid this approach is when you have an application that’s been heavily customized and is not replicable with current market offerings.

If you are deciding to transition from a legacy application to a more modern SaaS application by exporting/importing data, the legacy application is almost always retained in read-only archive mode. This can provide staff with the information they need during the migration process, but they will not have the functionality of the legacy app to modify this information. This approach can be useful if you’re looking to overhaul your enterprise, reduce technical debt, and take advantage of technological upgrades, but users may require training on the new application, and you should factor that into the migration process.

Finding the migration strategy that works for you

It’s important to understand that every instance is unique and that, while one approach may work well for one application, there isn’t a universally “correct” way to go about the migration process. You may refactor one or two of your most business-critical applications, re-platform a secondary one, and lift and shift a few minor ones.

However, one consideration you should enforce in your decision-making process is how these moves, or shifts, will impact employee productivity. Making decisions like these in a C-suite vacuum can lead to frustration on the front line when staff have to implement the changes, learn a new technology, or make do with a glitchy application that isn’t quite scaling right. As long as you consider your business needs, the urgency of the move, and the business and operational impact it will have, you can’t go wrong moving to the cloud.

Vadim Vladimirskiy is Co-Founder and CEO of Nerdio.