Major Concerns Associated with Cloud Migration

Whether you are just considering cloud migration, or you are in the midst of migrating your infrastructure, some technical challenges will inevitably arise. This article outlines several of these challenges and aims to help you understand some of the issues surrounding cloud migration better.

Our system is huge. How do we transfer our data to avoid high network costs, long transfer times and security concerns?

There are several solutions. One example is Azure Data Box. It allows to move large amounts of data to Azure when you're limited by time, network availability, or costs, using common copy tools such as Robocopy.

Our service processes multiple transactions per second. How do we move it to the cloud and ensure we don’t lose any transactions?

With large, complex and specialized transactional systems (banking, for example), we never just ‘switch’ from the old system to the new one. We always strive to establish a double-write system, with one copy in the cloud and another backup copy remaining on premises, to allow for a rollback if something goes wrong. The migration is always phased to avoid any risks of malfunction in the new system. During the pilot migration we could transfer 5% of all transactions, or a particular type of transactions, or only transactions belonging to a particular client. Only after a thorough testing, when correct processing of all types of transactions is confirmed, would we proceed with the following phases of migration.

Should we transfer the entire system or are there parts better left out of cloud?

A common approach is to keep hybrid infrastructure and use the cloud to enhance one’s technical capabilities, not to move to it, accept it as the only new model and never look back. One type of data often left out of cloud, is third party confidential data or software – many companies still prefer to store such data on premises for security and compliance reasons. Another type is specialized computing-intensive operations, e.?g. scientific GPU computing, rendering and so on. There is usually a highly developed on-premises infrastructure in place for such operations, and the cloud may lack sufficient computing power or simply be too expensive.

Should we use any cloud-specific SaaS- or PaaS- components to replace parts of the legacy systems?

It depends on the particular business case.

Yes: because such components make it possible to cut numerous costs on licenses, operation, security updates and patches, etc.

No: in case you use the system in a very specific way that requires either numerous customizations and enhancements, or some very specific performance / SLAs, so standard SaaS and PaaS offerings will not work for you.

Should we ‘buy’ instead of ‘build’ (i.e., replace legacy components or entire solutions with servers on the market)?

The answer is the same as for the question about SaaS- or PaaS-components. Buying is reasonable and cost-effective if your needs are not too specific. Building is recommended if you need a fully customized solution.

Read the full article on DataArt’s Blog: https://bit.ly/3vixJtd