The scheduling of a cloud migration is a complex undertaking that should be thought and planned in advance under the leadership of a lead cloud architect within your organisation who has the knowledge and experience necessary to perform the migration. When planning for the migration, there are five key things that every cloud architect should keep in mind to help make their cloud migration a success.

Key #1: Time is Your Enemy

Your application is most at risk for something going wrong from the time your migration starts until the time when the entire application has been moved to the cloud and the migration is complete. Reducing this time is essential to reducing the risk of a problem occurring during your migration.

In order to reduce the amount of time your migration is ongoing, you can front-load as much preparatory work as possible before the migration starts. This might include specific, planned refactorings that you otherwise naturally implement during the migration itself. If you can complete the refactorings in place before the migration starts, you will reduce the length of the migration itself.

If it’s not possible to complete the changes before the migration starts, you can instead complete them after the migration is complete. Deferring changes that are part of the migration until after the migration is complete may seem like an idea that could increase your overall technical debt — something you would like to avoid as much as possible. Yet, if you make specific plans — and follow through on those plans — to complete changes after the migration is complete, you can reduce the duration of the riskiest part of the migration process itself, reducing your overall application risk.

Key #2: Have a Back-Out Plan

As you create your plans to execute individual steps of your migration, be sure to include plans for how to back-out of the change in case the change goes awry. By having a back-out plan prepared in advance, you reduce your risk of making the change. If the change does cause an unexpected problem, rather than being stuck trying to solve the problem, you can implement your back-out plan and return to status quo. This will allow you to reassess and reformulate a new plan to avoid the problem on your next attempt. This won’t reduce the likelihood of a planned change failing, but it will reduce the severity of problems that can occur from a failed change, thus reducing your overall risk.

Key #3: Limit Data Migration Complexity

By far the most complex part of your migration involves the migration of your data from on-premise data stores to cloud-based data stores. This is because moving your data often involves planning for periods of reduced performance and potential application downtime due to the time-consuming requirements of moving large datasets. This delicate operation is the heart of your migration and creates the greatest opportunity for undesired customer impact.

There are many ways to migrate your data that can mitigate these risks and reduce or eliminate performance issues and application downtime. Some of these methods are straightforward and some of them can be quite involved and complex, involving complex data synchronisation and master-master updates and management.

While these complex mechanisms are relevant and important and may be required in some cases to keep application impact as small as possible during the migration, be very careful that you do not over-engineer your data migration strategy. It can sometimes be easy to create a much more complex migration process than your needs really require.

Examine what your real migration requirements are, and the real allowed impact and acceptable risk levels for your application, and design a migration strategy that matches those needs. Creating a strategy more complicated than required may well meet and exceed your migration needs, but will also increase the risk of something going wrong. Complex systems are risky systems, and this goes for data migration systems as well.

Key #4: Plan for Performance Problems

During the migration, there will be periods of time when parts of your application have been successfully migrated, while other parts are still in your old data centers. During this period of time, there will be decreased connectivity between the different portions of your application in different locations. This decreased connectivity impacts latency and capacity, which ultimately means a reduction in performance of your application in this state.

While this will be a temporary condition that only lasts as long as your migration is occurring (which should be as short as possible, according to key #1), it is important that you recognise the fact that your application will be functioning at reduced performance for a period of time. Therefore, you should make appropriate plans to address this shortcoming with your customers and business partners. Often, performance issues can be mitigated effectively if they are known about in advance, and can be exasperated if they occur without warning. Giving stakeholders, internal and external, the appropriate knowledge of the expected impact will reduce the overall negative impact of the migration.

Key #5: Refactor Early, Not Late

Keeping key #1 in mind, which says perform your changes before or after your migration as much as possible — when you have a choice, make your changes as early in the process as possible. This means, as much as possible, perform as much refactoring before you migrate and minimise the refactorings you perform after the migration is complete.

In general, delaying changes increases technical debt, and there will be a tendency to call a migration “complete” as quickly as possible after the bulk of the migration is over. The more you delay a refactoring, the greater the likelihood it will be deemed unessential and skipped, causing your long term technical debt to increase.

All changes have risks, and cloud migrations are no exception. Reducing potential risk is an essential step in your migration planning process, and these five keys can go a long way towards reducing the overall risk of your cloud migration.

By Lee Atchison, Senior Director, Strategic Architecture, New Relic

This article was first published by Frontier Enterprise