4 ways to move your old custom apps to the cloud
Elevate your enterprise data technology and strategy to Transform 2021.
Change comes in all shapes and sizes. We welcome some changes and others we avoid. The pandemic has placed considerable emphasis on the need to change business operations and many organizations have been placed in ‘do or die’ situations when it comes to going remote, virtualizing desktops and , perhaps more importantly, to decide whether the on-premises applications should stay, move to the cloud, or be replaced entirely.
Such decisions have been a long time coming. The on-premises IT footprint has shrunk over the past 10 years with the emergence of the cloud, highly customizable SaaS applications, 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 thread under our desks. We are at home. We are mobile. And we are ushering in a new era of computing.
So it’s no longer a question of when to move to the cloud, but how. Here are four different approaches to consider:
Approach 1: Lift and move
The fastest and easiest of the four approaches, lift and shift, requires no code or architecture changes and simply involves placing an application in the cloud using its current deployment architecture on new “hardware”. This popular option is available to businesses following the emergence of infrastructure as a service in public and private clouds.
For those looking to get around quickly, efficiently, and affordably, it doesn’t get much better than this. This might not always be the most optimal migration strategy, and there are definitely downsides to be aware of.
The main disadvantage of this approach is the management of the long-term scalability and manageability of the application. Born in an on-premises environment, a legacy application is accustomed to (and sometimes designed for) a certain workload. Therefore, before you lift it and move it to the cloud, you should first thoroughly test the performance and scalability, especially when you separate the users from the application or data by a WAN. Without proper testing, you’ll never know which straw will break the camel’s back, and you might find that an influx of customers, users, or even staff tilts an app over the edge and makes it perform poorly. If it is just a mail server application or a time recording system, the damage may not be too severe, but if you have unsuccessfully lifted and moved your platform from selling in the cloud, your bottom line could take a hit.
Approach 2: Rebuild / Refactor
At 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 its re-architecture to take advantage of native cloud technologies, such as Platform as a Service. This requires significant code changes and represents a long term investment. Knowing that many custom legacy applications have links across the enterprise, dependencies on other applications, and workflows to adhere to, it is critical that every relationship is updated so that there is no interrupt once it is in the cloud. This is the most sustainable approach to migrating an application; it will be scalable for any increase in demand or use, will be available remotely, and will continue to meet all business needs. By adhering to modern, cloud-native architecture best practices, you can ensure that your application will be scalable and sustainable over the long term.
The main downside here is the cost associated with refactoring. This is a time-consuming process that basically involves rebuilding the entire application in a new environment, with new technology and new code. This can 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 bearable and relatively scalable model.
Approach 3: Re-platform
Reconfiguring applications is an intermediate approach between staging and refactoring and typically involves making “easy” changes to the architecture of the application, such as changing the way the application interacts with its database. data to leverage serverless database cloud services. . Assuming the application is not too ‘chatty’ and works well when separated from its database over a WAN, moving the database level during a re-platform project might be the way to go. best starting point.
When you put apps back in place, you typically don’t change the client side, but the way it interacts with data may be different. To make sure nothing is drifting in the cloud, it’s important to keep a close eye on the app once it’s been redesigned. The main difference between this approach and refactoring / rebuilding is that it is faster and therefore is often the first step in the application modernization process. You may not have fully understood the re-platform process and issues could arise on the fly. As long as you know this and have backup plans in place, this approach is very valuable and is a solid starting point if you decide to refactor later.
Approach 4: Get rid of the app and buy a new one
The final approach is to get rid of your old app and buy a ready-made SaaS that you can customize. This is a delicate approach to prescribe and is only viable in certain situations. If you’re still hosting your mail server, delete it and get Office 365 from Google Workspace. On a related note, any application considered commonplace in the workplace, such as CRM, human resource management, or an accounting solution, is also very likely to be replaced by a new SaaS product designed for the cloud. . The cases where you will avoid this approach is when you have an app that has been heavily personalized and is not replicable with current market offerings.
If you decide to move from a legacy app to a more modern SaaS app by exporting / importing data, the legacy app is almost always kept in read-only archive mode. This can provide staff with the information they need during the migration process, but they won’t have the functionality of the old app to change that information. This approach can be useful if you want to overhaul your business, reduce technical debt, and take advantage of technology upgrades, but users may need training on the new application, and you should consider this in the process of upgrading. migration.
Find the right migration strategy for you
It is important to understand that every instance is unique and that while one approach may work well for an application, there is no universally “correct” way to go about the migration process. You can refactor one or two of your most business-critical applications, reshape a secondary application, and lift and move a few minor applications.
However, one consideration that you should apply in your decision-making process is how these movements, or changes, 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 changes, learn new technology, or settle for a glitching app that doesn’t quite scale. quite correctly. As long as you consider your business needs, the urgency of the move, and its business and operational impact, you can’t go wrong moving to the cloud.
Vadim Vladimirskiy is co-founder and CEO of Nerdio.
VentureBeat’s mission is to be a digital city place for technical decision-makers to gain knowledge about transformative technology and conduct transactions. Our site provides essential information on data technologies and strategies to guide you in running your organizations. We invite you to become a member of our community, to access:
- up-to-date information on the topics that interest you
- our newsletters
- Closed thought leader content and discounted access to our popular events, such as Transform 2021: Learn more
- networking features, and more
Become a member