Although it’s exciting, moving house sucks. The idea of taking all your worldly possessions, putting them into flimsy cardboard boxes, and then playing high-stakes Tetris in the back of a rented van is just a little ridiculous. The worst part is packing. When do you start packing? What do you pack first? What should you throw away? As someone who has rented in London I’ve unfortunately become quite familiar with the experience, and I’ve seen the techniques of friends and family too. Usually, success comes from good planning and compartmentalisation, trying to do everything all at once will result in shed tears and broken crockery. At The Scale Factory we also see this when rehoming systems into the cloud and have some advice on how to put together a plan that will save the family china.
Don’t let the complexity of your SaaS product hold you back
Even when things go well, moving house is not a fun experience. We do it because we need to, and it’s going to make our lives easier in the future. Few people have ever decided they don’t need that extra bedroom because it’s not worth the effort of packing up a few dozen boxes. And yet, at The Scale Factory, we see that kind of thinking when discussing cloud migrations all the time.
There are many benefits of rearchitecting your SaaS product to run in the cloud: from the more technical like increased flexibility and scalability for your application, to business benefits such as moving IT costs from upfront capital expenditure to operational expenditure. But business can be hesitant to take the plunge, why is that? Because rearchitecting and migrating complex systems is hard.
If you botch a house move, you might have a few broken plates to replace; on the other hand, a poorly executed cloud migration can become an existential threat to a SaaS business. Alongside tangible engineering and infrastructural costs associated with a failed or overdue migration, there are significant intangible employee morale and opportunity costs. How then do you unlock the benefits of the cloud while reducing the risk of migration as much as possible? A well planned phased migration is going to take you a long way.
Phased migration makes it easier
Although you’ll see that many of the planning decisions you make when moving home parallel those you need to make when planning a migration to the cloud, there is one big difference. You don’t need to plan to execute it all in a single day. When looking at a complex SaaS system, which probably consists of a tangle of interrelated components and services, don’t fall into the trap of thinking it needs to be moved all at once. One of the major benefits of public clouds and their on-demand billing models is that you can dip a toe in, try things out, and gradually scale usage up as required. You can utilize this by planning your migration in phases, re-architecting and migrating your systems one at a time or in small batches. By keeping these batch sizes small you also keep spending and risks at manageable levels.
Aside from a nicer looking cash position and balance sheet, you’ll also realise secondary operational benefits from working on smaller projects. As teams iterate through smaller self-contained migrations, they will build experience they can apply to subsequent iterations. Missteps can be accounted for in the planning of the next phase, without causing a major disruption to the business as a whole.
The key question that remains is: which component to migrate first?
Manage risks by starting small
While you may have chosen to move house to get a bigger kitchen, that doesn’t mean you pack up your kitchen utensils first, you’re still going to eat breakfast on moving day. Instead, it’s usually a good idea to pack up the rarely used bric-à-brac first and minimise disruption to your daily life. The same can be true for cloud migrations. Perhaps the key outcome of a migration is to increase the scalability of an important workload, but that doesn’t necessarily mean it should be where you start. As stated earlier, one of the benefits of a phased migration plan is that you can build experience in your team over multiple phases. By starting with a relatively small or unimportant component, a team is given a safer space to experiment and make mistakes, improving the outcomes for future, more mission-critical, system migrations.
Acknowledging that migrating systems is hard can influence your choices for your early phases in another way: how easy is it to revert if something goes wrong? Stateless services with small API surfaces are good candidates for easily reversible migrations. If you are running monolithic services, you can use the strangler fig pattern to start isolating components that meets those requirements and which can be migrated independently. Early phases of your phased migration should be focused on low risk changes to make later phases run smoother.
Not everything has to make the move. “Does this spark joy?” is a common refrain for the followers of professional organiser Marie Kondo. When assessing whether a component should be included in their phased migration plan, businesses should be asking themselves “does this provide value?”. Cloud migrations are an excellent opportunity to identify components that can be replaced or retired altogether.
Migrating to the cloud doesn’t have to be hard
Complex systems have a huge cognitive burden that give them an inertia to change that sometimes feels insurmountable. But as with most problems, the complexity can fall away when broken up into smaller, more manageable chunks. Just as it would be counterproductive to pack all your possessions into a single huge cardboard box labelled “house” when moving home, it’s a good idea to go “room by room” and migrate your service to the cloud in nicely labelled and self-contained packages. You’ll certainly end up with fewer smashed heirlooms.
Got an existing system or service that’s looking for a new home in the cloud? Our AWS-focused team can help you find a way to manage the risks around migration. Talk to us for a free chat about the challenges and how we might solve them.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.