Awareness is not the problem - most businesses know they have old, outdated systems that aren’t efficient. The issue is that there is no silver bullet - and no guarantee that if you modernize today, you won’t need to do so again in 2 or 3 years. So why not just wait? Waiting won’t solve the problems, it will just delay the inevitable. But there are options.
From a planning perspective there are the 8 “R’s” to consider in a modernization effort: Retire, Retain, Relocate, Rehost, Repurchase, Re-Platform, Refactor or Recreate. Sequentially, each one is a more costly option (up-front) than the previous one. Retire - wouldn’t it be great (and cost-effective) if we could simply just retire all those legacy systems? No such luck!
Retain is the status quo. Built off the theory “if it ain’t broke don’t fix it”, many organizations are comfortable in their current workflows and don’t want big changes. New technology will cost money and disrupt current work. So why would anyone want to embark on any kind of modernization effort when they can just stick with what they have? Better the devil you know than the devil you don’t know.
On the other end of the “R spectrum” is Recreate - and herein lies the culprit. Anyone who has survived a development project knows the last thing they want to do is go through it again, especially with yesteryear’s monolithic application architecture and the magnanimous scope involved with a redevelopment effort. It’s too much to take on, causes too much disruption and is too prone to failure. At the executive level, the justification to “Retain” is a result of a simple risk management formula. If “Recreate” is seen as the only option for modernization, then “Retain” doesn’t sound so bad.
But the good news is the problem we face today is a result of false assumptions. Retain or Recreate are not our only options. Modernization is NOT a binary decision.
In fact, the middle-ground R’s - Relocate, Rehost, Repurchase, Re-Platform, and Refactor - these are the best approaches for modernization - and they are at the heart of cloud migration.
Cloud migration is not a new buzz word - we’ve been listening to it in dribs and drabs since 2010 when some of the big players - Netflix, Dropbox & Reddit - started using the earliest of Amazon Web Services (AWS) cloud cocktails - S3 storage, EC2 servers, Elastic Block Storage (EBS) & Cloudfront. Since that time AWS has grown from $500M business to over $25B in revenue across nearly 150 different services. But what does cloud migration have to do with modernization?
To be clear, migrating your applications to the cloud is not the only thing you can do to modernize your software. But it is the best first thing you can do. Last week, while attending the AWS Summit in NYC, I heard those very words come directly from AWS CTO Werner Vogel: “Cloud migration may be the most important thing an organization can do to keep up with security, innovation, reliability, computing costs, and operational management.” The fact is, once you have your software applications on cloud services, you begin to have many more options for incremental modernization. These options are primarily at the architectural level and you simply would not be able to create these things for yourself in any sort of an affordable way.
For example, when you migrate your LAMP stack application to the simplest version of an Amazon EC2 hosting setup, you immediately have access to several modern configurations & services that will drastically improve your software and make it more modern:
Amazon RDS - Amazon’s abstracted database service is practically plug-and-play and you will never again need to worry about updating or patching your MySQL instances.
Amazon SES - Never again feel the pain of having the emails from your application get blacklisted and worry not about your application’s mail server getting hijacked by spammers - like RDS, your troubles simply go away with this service.
Amazon SQS - Build an entire processing mechanism in your software to make your back-end processes asynchronous - a key aspect of large scalability and a critical component of today’s modern architecture.
The list goes on. Hauling your systems to the cloud will take some effort - but it won’t involve the dreaded “Rewrite” - start with a straight-up port to EC2. There will be a few modifications you need to make during the port. Once you have it running in the cloud, you can begin to tackle small modifications along the way, but only as you see fit and only where you will get the most ROI.
Most importantly, don’t wait. Today, every business is a software business - Software is everywhere and we all rely on it, you simply can’t afford to let it go stale. Why?
Compliance - With GDPR and other industry compliance requirements, the window is closing on your ability to stay up-to-date and in compliance. Get your stack updated so you can push through these compliance requirements.
Competition - Your industry is moving to the cloud and at the very least staging themselves for the modern software stack. No business can afford to have their customers have a better experience with the competition.
Credibility - Your customers, your employees, your vendors, your strategic partners - All of them see your viability through your ability to adapt to the times and adopt new ways of doing business - sticking with the “Retain” method tells everyone around you that you’re change-resistant and not forward-thinking. Would you choose to work with a company that wore that on their sleeve?
But enough of the scare tactics - the good news is that there is an option - and it starts with moving to the cloud - and in doing so you will create inherent opportunities for you to modernize your systems in numerous ways and in doing so, stay compliant, competitive & relevant.