By Dr. Gavin Scruby, CIO, SmartDebit
Why is cloud migration different for SMEs and enterprises?
Migration to cloud from self-hosted systems can provide important economic and scalability advantages for companies of all sizes. For large enterprises, there is only one sensible approach: long-term and carefully planned activity, with a slowly established and thoroughly-tested hybrid environment. For SMEs though, the path isn’t as clear. With limited budget and unpredictable cashflow, such an approach could bankrupt the business over time.
For SMEs, the value of various cloud migration approaches really depends on the kind of IT the organisation has in place. The economics of cloud doesn’t always outweigh the costs of setting up services there. In this instance, we’re really talking about companies running public-facing workloads for SaaS type applications rather than simple internal systems like email, office file storage and office applications. Such back-office systems are very much commoditised in the cloud and can be added piecemeal over time without business-level risks. If you’re this kind of company, it’s likely many of your back-office systems are already rented cloud-based commodity services, and you may have no SaaS offerings that need a migration approach.
Big bang migration
Assuming we have a number of SaaS public-facing services to deal with, there are three main ways of tackling a cloud migration. Two are commonly used, but the third has some advantages that extend well beyond IT’s normal areas of influence, so should be considered.
The first option is the simple big bang approach. You build a copy of your enterprise in the cloud, test it then switch everything over and switch off your local instances. Of all the approaches, this has the most risk, but potentially the least cost – if done right. The downside is that it’s great in theory, but rarely great in practice. The real-world implications of human error, fix and retest mean that the switch-over could drag on for a long time, during which you are paying for both ongoing local hosting and cloud hosting. On the other hand, if you manage to migrate too quickly, you might not wring the last useful life out of your local kit. This can be an issue because you are likely to have bought and paid for local servers, so a very fast migration to cloud means that this capital expenditure is written off without generating revenue (part of the reason for moving to cloud in the first place is often to move capital costs to operational expenditure). It’s really hard to predict when this kind of full migration will finish, which makes contract renewal for your surrounding systems difficult. Finance teams may not be happy with this.
Migrating data between the two environments is also difficult and slow, so switching back and forth is hard. Such dependencies cause huge problems if you have to roll back to your local solution when something catastrophic happens. Due to data movements, the actual roll-back may take so long, it can put the business into crisis. Even so, many small companies still try to migrate in this way, because in many ways it creates a simpler project with defined dates and clear milestones.
Service separation migration
There is a better migration method though, which copies the model large companies use, albeit by moving larger relative chunks of the IT infrastructure. Large organisations can’t possibly migrate fully in one step, so separate out services piecebypiece. SMEs can use a similar model, but migrate a much larger part of the company at each step – usually a whole section of the customer-supporting service. We call this service ‘separation migration’: using targeted cloud services to create a hybrid model, with some of your services running locally and some in the cloud.
This has become a lot easier in the last few years. In the past, public clouds would only work within their own infrastructure. Cloud companies soon saw that this was not practical so they modified their offering to extend into hybrid environments, such as companies’ local systems. There are many services now available in the cloud that can support partial migration and they are always adding support for the latest hybrid trends, such as edge computing systems. Let them do some of your work for you and take a look at their portfolio. By looking at the cloud’s hybrid extending services, you will be able to work out which of your local services could be broken away and migrated most easily. They’ve spent a lot of time working out how to do this, so use their expertise rather than trying to migrate custom parts of your infrastructure that aren’t supported. This allows a hybrid approach where, for example, you might keep critical databases locally and run application processing in the cloud. Other problematic functions can also be migrated, such as email send services, back-up storage, file storage, key management and many others. On their own, these could save money over local instances and provide valuable experience to your IT team in how to migrate fully to the cloud in the future. It’s always good if the next project is priced more accurately using real data from within the organisation. It also means any freed-up local infrastructure can be used to expand the applications still running there, so you don’t lose money on your existing investment.
Service separation migration can also add services to your IT portfolio that you don’t have the in-house skills or budget to deliver. Areas such as big data storage, big data analysis, specialist database types or video encoding systems are always difficult to set up with a small team. Nearly every standard service you can imagine is now available in large public clouds. Using some of these can augment your existing offering with predictable pay-as-you-go costs and less training needed for staff.
There are downsides too of course. The key thing to remember is that the cloud is some distance from local systems, so you must always be aware of the data hop between the two. Try to use cloud services that don’t need frequent data back-and-forth, or need quick data connections to the local infrastructure. If you don’t design for this, your systems could slow right down as data travels significant distances, or you could incur substantial data transfer costs (cloud providers usually charge for data in and out of the cloud). If you find you suddenly need a faster connection, it’s not catastrophic; cloud providers have custom solutions with direct connections to solve the issue. However these are often exorbitantly expensive, so the design upfront is crucial.
This leads us onto a third approach. This is often missed or ruled out because it needs involvement beyond IT. However, it avoids data hop issues and with some thought, it can also open up new business and markets. In my opinion, this approach can generate the most value of any we have looked at, and it provides a complete learning experience for the business. The implementation downside is that it relies on every area of the company being involved because it requires strategic change. My view though is that if you are considering moving everything to cloud, you are already making a serious strategic change so there should already be full business involvement and buy-in.
We call this paradigm the cloud extension approach. Here, as in the big bang approach, we try to build a copy, or near copy, of all revenue-generating services in the cloud. The difference between the big bang approach and dual running is that we don’t migrate local customers to the cloud, and there may never be a final migration. We actually run two business systems and just add new customers, or a different type of customer, to the cloud solution. This allows new ways of working and new market segments to be opened.
Examples where I have seen this used are when local systems can’t scale large enough to support some customers – but cloud can. Or, when local systems can’t process transactions quickly enough (usually due to limitations of physical space or capital budget). Yet with the right choice of cloud infrastructure, this no longer becomes a problem. Another situation in which this model can be useful is when local systems can’t be migrated to the latest versions of software, as cloud provides a clean start on a modern baseline. Cloud use being pay-as-you-go is also simpler to price, so more flexible and competitive pricing models can be created as you are no longer paying for unused capacity. The beauty of this overall method is that you can eventually, and slowly, migrate existing customers at a pace you choose, if you so choose.
One final example I have seen where this approach was useful was when certain groups of customers required non-cloud hosting for their own compliance reasons. The company could only expand using cloud, so split the customer base between local and cloud, splitting by compliance need and charging a premium for local. That raises an important caveat when migrating customers from local systems to cloud: be careful of contractual issues. When adding a public cloud into your processing chain, you are likely adding a new data sub-processor (the cloud provider itself) which needs permission from the customer under GDPR legislation. Also don’t forget that security controls and compliance checks may need to be different in the cloud than for local systems. This is another reason that using the cloud to open a new market segment with a new customer type is better than trying to change existing customers as your first approach.
Which method to choose
I’ve seen a lot of SMEs try to migrate to the cloud in one big bang project. This is very risky, even for large players, as we’ve seen in the news recently when banks have tried to switch banking platforms in one step. These have caused high-profile outages that will affect the business for years to come. A more considered approach, with separation of services between local and cloud systems can work really well in adding otherwise unobtainable capabilities to your services. This can of course mean you get stuck in an eternal hybrid solution, with part-local and part cloud, and ultimately your architecture is limited by the inevitable and dreaded data hop between cloud and local systems. This can be the perfect solution for many organisations though: it provides some economies of scale but you retain complete control of key areas.
If it’s possible in the organisation, I prefer the dual running option, as its advantages spread beyond IT. If I have to migrate to the cloud, I want to make sure that the advantages it gives go beyond simple cost savings or capacity increase. I want to use the opportunity to move the business into new areas and break into new market segments. If you can adopt that approach, and show that the advantages go far beyond IT to help the rest of the business and grow revenue, funding a new cloud migration becomes a much easier proposition. It can also enhance the value of the IT team outside its stereotypical niche and into business strategy as a whole, and that helps everyone.