If you are a small or medium sized business and are either in the midst of or considering moving your on-premises resources to the cloud, you have made a great decision for many reasons, which we won't go into detail on here. However, there are many factors you must consider when planning and executing your move. Five important considerations are discussed here. 

1. The Journey is Not One Way

Many people feel that the move to the cloud is a one-time, one-way journey. This causes some misguided thinking when planning the move, and increases the stakes to a very uncomfortable level for many organizations. The journey is not one way. There are many methods and processes to clone data, objects, devices and servers back to on-premises resources from the cloud. These processes have been developed by the primary vendors (Microsoft in the case of Azure for example) and by many other third party vendors. 

In fact, once objects have been successfully migrated to the cloud, it can sometimes be even easier to clone them back on-premises. This is because you will have already dealt with things like permissions, groups, identity management, access etc. The exercise of moving resources to the cloud will actually get you to examine each of those issues, something you may not have done for years in your on-prem environment. In addition, once you have moved something to the cloud, you have essentially added a cloud based copy of the object. At the very least you have added some redundancy and backup.

One real life example was a file sharing web application developed by Crowdbitz. It was developed in .NET and used SQL Server, and included PayPal and Bitcoin transactions. It was hosted on-premises on an older server running Windows Server 2012 R2, and SQL Server 2012. We decided that we should move the application to Azure, both to gain depth of experience in the process, and to add some redundancy to our local environment. We decided to deploy a virtual server for the application, mainly due to the use of various third party applications (for video rendering, file conversions etc.). Rather than spinning up a second virtual server with a full deployment of SQL Server, we setup an Azure SQL Database. The migration was too lengthy to detail here, but given the relative complexity of the application was relatively painless. We realized after the migration that we have essentially liberated our application from its on-prem cell. It was now possible to easily bring us other environments (development, pre-production) and move size the application as needed.

A couple of years later the application was not making the overhead required to maintain the azure resources. We had subsequently updated our on-premises servers and had moved to a different development model. We decided to move our application back to an on-prem server. This was much easier than the initial migration. Our application had become portable. This was a direct consequence of the cloud migration process, even though we ended up staying on-prem in the end. 

2. It All Starts With Identity

Your data is only as secure as your identity management policies. You are trusting that users, groups and permissions are up to date and that your files are secured. That might be true, but it could also be true that your data is only safe because of your on-prem environment and the fact that users outside of the building cannot connect through the firewall. It is essential that you look at your identity management before you start moving resources to the cloud so that you don't inadvertently expose sensitive or valuable data to the public or ex-employees who still have active accounts. 

The first consideration is whether you need to keep your identity management system, or whether this move in an opportunity for a new one (see 5 below). Moving to a cloud based identity management system will greatly facilitate your other cloud moves. If you are using Microsoft Active Directory for permissions and/or identity management, then setting Azure Active Directory makes sense. AAD is free for limited use, which gives you the ability to setup your cloud directory before other services are migrated.

Running a hybrid cloud/on-prem identity management system can be problematic. A hybrid system relies on consistent communication between the on-prem and the cloud, and relies on software services to maintain a sync of identities. While simple in theory, this can actually be quite problematic. Differences in password policies in AAD and your on-prem directory can result in a password change in one environment locking a user out in the other.

Since you are going to be looking at your identities, this is the time for you to clean up. Remove all user and group accounts that are no longer needed, and put time into considering a new user and group structure for your organization. Does your current organization structure match your outdated identity management structure? Likely it does not. If so this is your chance to rebuild things, and to follow best practices for identity management. Remove unused accounts and groups, rename accounts and groups to more accurately match their purpose, change passwords everywhere etc. 

3. Expectations and User Experience

Managing user expectations and the user experience of the migration are vitally important. You should meet with groups within the organization and try to find out what their expectations of a cloud migration are. If those expectations are unrealistic, effort should be spent to manage those expectations and possibly change them to something more realistic. For example, if an application will be moved to the cloud and it is not going to have an increase in performance as part of the move, then you don't want users to assume that it will. You might instead want to focus on things like redundancy, backup, replication, and security.

The user experience of the migration needs to be carefully managed as well. Migrate objects and processes in small batches, followed by user acceptance testing and follow up. In the early stages, try to focus on those applications or processes that are improved in a very obvious way. That will gain early buy-in from users and enable them to more easily accept any issues that come later.

4. Let Champions Lead the Charge

A cloud champion in your organization is vital for success in any cloud migration. Ideally this will be a CEO, CTO, CIO, or at the very least a director. The champion should have at least a basic understanding of the technology, and a strong sense of why they want to see things moved to the cloud. 

Price is a terrible comparison point for cloud vs on-prem. There are many aspects of cloud that are actually more expensive than on-prem, but they bring with them enhancements to reliability and performance. Often a move involves an upgrade, which can increase costs even if moving to virtual resources. Instead users should be convinced on the basis of access, usability or some other point of comparison. 

5. This is Your Chance to Rebuild

This is your chance to rebuild. The value of this cannot be overestimated. Entropy is a powerful force in the universe, and over time your users, groups, file shares, web applications and assorted services will begin to become overly complicated and interlinked. The amount of useless information and unused objects usually greatly outnumbers those that are actually in use. 

Take the time to meet with different groups within your organization and determine what they actually use and would like to see moved and/or improved. When the time comes, migrate those things that people have identified as important, and deprecate those things that should no longer be used. Our reliance on legacy systems prevents us from moving forward and innovating. Use the move to cloud to transform and improve digital services. If something is not working well on-prem, don't assume the move to cloud will help in any way. 

Conclusion

There are of course many other factors to consider, and other research to be done. Don't get locked down into over analyzing every aspect. Recognize that one day your on-prem will need to migrate, if not to cloud then to new on-prem systems. The work ultimately will need to be done. Make sure you do it on your terms and on your timeline rather than happening through disaster mitigation. The more work you do up front on best practices and the reduction of unused resources, the smoother and more enjoyable your migration will be.  

Further Reading

Gartner, 7 Options to Modernize Legacy Systems

https://www.gartner.com/smarterwithgartner/7-options-to-modernize-legacy-systems/

Gartner's 5 Rs of Cloud Migration Strategy

https://medium.com/@satechglobal/the-5-rs-of-cloud-migration-strategy-3b6a5676dda2