It’s a big decision for software companies to make the leap from an on-premises application environment to one that runs in the cloud. We set out the business drivers for rebuilding your own products as SaaS solutions in the first part of this 2-part series.
In part one we looked at planning what your rebuild might look like. This time, we’ll look at the “how” of making the move, to help you understand and prepare for the challenges. It’s the sort of work we help our customers with every day, so should you have any questions, do drop us a line. We love nerding out over these topics.
From planning to production
The basic process for rebuilding an application in the cloud will look like this:
- Architecture, design & planning: defining design goals, understanding success criteria, researching and identifying the right tech stack and production selections.
- Test planning: mapping actual usage scenarios.
- Build/test/release cycle: using DevOps principles to produce a continuous delivery cycle.
- Minimum viable product (MVP): providing a working solution aimed first at new customers.
- Customer piloting: migrating more users as the solution approaches feature parity.
- Rollout to all: delivering the full cloud solution that matches or betters the on-premises version.
Mapped visually, it looks like this. In the rest of the article, we’ll put a bit more detail around what this means.
The most important thing to get straight is this: it’s simply not possible to take an on-premises system and magic it into SaaS, where all functionality is perfectly and immediately preserved.
For starters, you can’t be sure that all features that worked on-premises can be brought across to the cloud, meaning that you need to establish what can reasonably be moved and what might need to be rebuilt.
Every rebuild from on-premises to the cloud is different, and while there may be some reusable components, it’s also possible that you’re trying to move a monolithic or very old structure, in which case most or even all of the components will need to be rebuilt.
On top of this, it’s hard to know whether your moved solution would work at scale. Perhaps you started with old database tech that was built for 100 users. But what about moving to the cloud and expecting this to work for 100,000 users? The ability to scale like this shouldn’t be taken for granted.
Such considerations mean that an architecture and design phase has to come before anything else. Unsurprisingly, a project where a large part of the solution needs to be rebuilt for the cloud will take longer and cost more than one where most or almost all components can be moved across easily.
With a basic architecture and design sketched out, you can dig into the details of exactly what needs to be done so that one or more proofs of concept (PoCs) can be built, to (cheaply) demonstrate the feasibility of your new architecture
Crucially, you need a clear idea of what your success criteria should be for the project and how you’ll go about testing that.
When developing most software and platforms, it’s common to build and release a minimum viable product (MVP) before committing the time and resources to releasing a fully fledged solution. This is a challenge in the scenario where a battle-hardened solution already exists, namely a current on-premises application. In this case, an MVP for the cloud would lack many of the features that customers are used to in the old system.
However, rather than saddling those customers with what would clearly feel like a downgraded experience, a better approach would be to place only new customers on the cloud system, at least until you are close to or at full feature parity with the on-premises version.
Still, this too poses challenges. You go from everyone being on one system to having a couple of systems to support. This puts you in limbo: your admin and support burden increases while you’re faced with the task of bridging the feature gap as quickly as possible.
Our work with customers moving on-premises products to the cloud focuses on accelerating this stage as much as possible, to move past the limbo state and to a point where it’s possible to start migrating customers to the new application.
We keep the 80/20 Pareto principle in mind here – that 80% of the value will come from 20% of the features. We aim to help produce something fast, repeatable and low risk that ensures that the essential parts of the new solution are migrated or rebuilt as swiftly as possible.
The challenge of moving customers to your new system
Even when you approach feature parity and have a critical mass of customers to prove that the new solution works, migrating all of your old customers is likely to be a challenge. After all, some of those people may have been happily using the old system for years. Why should they make a change?
You could try to incentivise such customers to rethink their position, or you may need to be patient as the clock ticks down to their next major investment cycle. But with that wait being potentially years, the best approach is to sell the benefits of the new environment as clearly as possible, such as promoting any cloud-specific advantages on offer and highlighting that others have taken steps to futureproof their operations by making the move in good time. This social proof angle could be effective in a particularly competitive market, as no one wants to look like the last person to take notice of inevitable change.
Keeping up with the Joneses is one thing, but it’s also important to acknowledge that your customers may view a migration as an unnecessary risk and hence be unconvinced of the need to move, despite assurances of your robust testing of the new system.
Testing is a fundamental aspect that we focus on when handling such projects. It’s essential to plan for actual usage scenarios and test these as well as possible. The last thing you want is to finally convince your least keen customers to migrate and then find that your shiny new applications don’t work as intended. We talk more about the value of good testing here.
As a side note, we’ve found that Thursday night switchovers work well, as this gives people a full day to get used to the new systems before the weekend break. That’s much better than trying to handle migrations on the weekend – avoid this!