Cloud migration... what does it mean?
Cloud migration has come up in some form or other in virtually all of the software deals I've worked on... and it almost always causes confusion for non-technical investors. It's easy to see why, when the very word - cloud - is imprecise and therefore regularly misused.
The key distinction to understand is that cloud software:
- Runs and stores data in a remote data centre (on a server), and
- Is accessed in a web browser, using a web address.
If your software is doing that, you're probably 90% of the way there, maybe all the way. If it's not - say for example the software runs as a desktop application installed on an end-user's computer... you could have a long road ahead of you, probably rewriting a large chunk of the code. There's really no getting around it either, because virtually all software is headed for the cloud, only the speed varies.
To understand how much work is required, it's helpful to think about three different types of software, each of which has different potential "cloud migration" activities:
Firstly, you have local applications that run on a laptop or desktop computer. Word, Excel and PowerPoint are familiar examples of this, normally B2C rather than B2B, software. They run locally and store data in files either on your local hard drive or network drive. Clearly this is not "cloud" software, and migrating to the cloud for this type of application probably requires you to start over from a code perspective. The web versions of Word, Excel and PowerPoint for example, probably share very little code with the desktop versions, they were ground-up rewrites.
Secondly, you have local applications that store data in a remote, shared database... and perhaps even rely on remote web services for some of their intelligence or functionality. Your email provides a familiar example, along with Zoom/Teams... and it's a fairly common architecture for many legacy B2B applications (sometimes called "client/server" apps). These apps are quite often a thin layer of user interface in front of a database. I've worked on childcare applications, practice management systems, even ERP applications that follow this design. Migrating these applications to the cloud probably doesn't require a complete rewrite, but it's important to understand that displaying a user interface in a desktop application uses totally different and unrelated code than showing a user interface in a web browser. You may also need to redesign the database to accommodate a "multi-tenant" design (which means you have more than one user's data stored in the same database).
Thirdly, you have web applications, which satisfy the definition above, of being "cloud" software: there is a server somewhere that stores the data and gives you a webpage in a browser for a user interface. Any kind of website is essentially this... Facebook, Amazon, Google etc. The user doesn't ever need to install it or worry about upgrading to the latest version (and equally, the vendor doesn't need to worry about supporting anything other than the latest version). There is a bit of nuance to understand here though, particularly in the backend. The AWS revolution has had a massive impact on the cost and ease with which web applications can be deployed and run. Remember that scene in The Social Network where a young Mark Zuckerberg crashes the Harvard network with Facemash... well, Facebook still needs to worry about that because of sheer scale, but the rest of us don't need to anymore, thanks to AWS (and more recently Azure, Google Cloud etc). Some slower-moving B2B applications however might still have dedicated or onsite servers, and therefore still a bit of "cloud migration" work to do. I've also seen web applications that have a separate database for each client, which again requires change as it scales up.
The cloud migration conversation is most important for software in the second category. More than likely it's going to be a big job, close to a complete rewrite. The size of the job depends on how much of the application's intelligence is either in the user interface or the local application's business logic, versus being provided remotely. Happily, it's likely that the development team will have a comprehensive knowledge of the user context and the kinds of things the user is trying to get done... both of which will be extremely useful in speeding up the rewrite: less time wasted on stuff that users don't want, more robust designs.
You'll likely need to support both the legacy and new users for a period of time, as you drag users from old to new, potentially for 5+ years in a B2B app. For that period of time you might need to add new features - particularly compliance features - to both versions... creating twice the work. It's also a dangerous time, because clients may decide to re-evaluate the competition before transitioning, or perhaps be impertinent enough to renegotiate the contract. The first issue, customer churn, is the biggest risk in my experience... normally web applications use a recurring revenue contract and earn a margin on the hosting infrastructure costs, so margins are generally better for web applications.
For software in the third category, if there's any cloud migration required at all, it's far simpler. There is most often no need to involve users directly in transitioning to public cloud services like AWS and leveraging their advantages. Instead it's about changing your internal development practices... and most developers will be keen to do so as it makes their lives easier and builds their CV. There will be a conversation about DevOps and automation, speeding up the cycle of releases and making them more reliable and repeatable. There is some cost involved, but related benefits too.
I hope that makes it easier to understand what I mean when I say "cloud migration". If not, drop me a line or ask a question below... always keen to help.
