A question I hear often as of late is some variation of "What will it take to move my Sitecore implementation to the cloud?". That answer can vary wildly from implementation to implementation, but when a customer recently asked for a list of things to be aware of during their transition, I noticed there was no concise list of considerations when making that move.
In an effort to transform "unknown unknowns" to "known unknowns", I've started compiling a list of things to be aware of when migrating your instance to Azure. Not all items on this list will be applicable to all implementations, but hopefully it starts a conversation with your team to identify things that you might have missed or not considered.
Finally, this list is in no way comprehensive. If you see something I've missed, please let me know so we can make this list better! Reach out on Twitter @derekc, on the Sitecore Community Slack as "dcorreia", or in the comments below this post. Thanks!
Consider your backup/restore/disaster recovery strategy for your application. Backups are different in Azure, so your IT team should practice how and when they are going to backup, and learn how to restore from backups. How this will be accomplished will vary greatly on what components of your architecture are PaaS, IaaS, and SaaS.
If utilizing IaaS resources, you will still need to manage and maintain the operating system on those resources. Make sure you develop a patching and maintenance strategy, and identify groups or resources on your team (or partner's team) responsible for managing these resources.
If utilizing IaaS resources, investigate VM redundancy options available to you in Azure when setting up your environment. Familiarize yourself with the concepts of fault domains and update domains, as well as what types of redundancy and SLAs Azure offers for VMs. This will help you deploy resources that meet your SLA.
Check your Sitecore modules for Azure support.
Thoroughly test 3rd party modules. Sitecore does not test or certify 3rd party modules for compatibility with releases, and some module developers might not be testing in Azure.
Profile your code extensively prior to go live. Things that may be fast on hardware may be less so in ASE. Azure tends to amplify any inefficient aspects of your application -- if it's "kind of slow" today, it could be worse in Azure.
Perform load testing on the production environment prior to go live. This will help you to identify if your resources are sized appropriately for your solution. For Sitecore 9 implementations, these guidelines from Sitecore can serve as a starting point for your sizing, but you must test to ensure these sizes are appropriate for your solution.
When load testing, try to make the test environment as indicative of production as possible. While scaled down testing will identify some possible bottlenecks, it's quite possible some aspects of the environment (xDB collection, session state, DTU's from the database) might not reveal issues until production-scale loads are put on your implementation.
Determine your strategy for securing your CM role instances. When on premise, this is less of a concern as your internal servers likely are isolated, and not externally accessible. Moving to Azure means the instance is on the public web, and you'll want to configure a firewall, jump box, or VPN to restrict access.
Review your solution to document any access to internal systems or 3rd party systems. Your solution may be integrated with authentication providers, ERPs, PIMs, and other line-of-business systems. Discuss what type of access is feasible from Azure via APIs that are externally available, or review if Azure Express Route might be an option for your application.
Ensure the Sitecore client directory and other sensitive directories are locked down on your Delivery instances. This should be done as part of deploying CD WDPs to your environment with ARM templates or the Marketplace module. You can also do this manually, and add other sensitive directories as well.
Determine what technology you'll be using to manage private and public session state data: MongoDB, SQL, or Redis. It's worth reviewing the documentation on Sitecore's site to better understand the pros and cons of the choices, and what providers are supported in your version.
If using Redis for session state, note that you cannot (as of time of writing) easily scale down a Redis instance on Azure. You should identify what size is appropriate during pre-production testing (and it is currently possible to scale up a Redis instance, just not scale it down).
Understand all of the roles that encompass a Sitecore 9 installation, and how they can be grouped together on logical instances. Certain roles work well grouped together, and can help with cost savings when deploying. Understanding these roles will also help you easier scale the environment when growth comes.
If you are migrating to Sitecore 9, familiarize yourself with the xDB Data Migration Tool. If possible, test migrating your existing xDB data set in a lower environment to identify custom mappings needed or any connectivity issues between environments before running against your production instances.
Check to ensure that there are no dependencies on the file system in the solution. This includes, but is not limited to, custom log files, media items, access to files outside of the webroot, or windows services. File system access is limited in Azure Web Applications, and you may have issues with ASE-based applications that extensively utilize the file system.
Ensure no custom ISAPI filters are in place in the solution.
Ensure you're not using URL Rewrite. If so you'll need to investigate other solutions.
Evaluate options for deploying your application to your environment. This could leverage your build management system, Visual Studio, or other technologies.
Consider bundling your solution into WDP packages. This will make scaling up instances of your web applications much easier.
If your solution currently uses Lucene, you'll need to change to a different technology, such as Solr or Azure Search. Lucene is not supported as a production indexing technology in Sitecore 9 or in Azure.
If you're migrating from on premise with xDB, plan how you will collect xDB data going forward (hosted Mongo for 8.x, or SQL and xConnect for 9.x).
Sitecore 8: xDB collection roles should be housed as closely as possible to their CD roles. CD roles write directly to the collection database in Sitecore 8.x, so proximity in the same Azure region will help with performance.
If you're having an issue with Sitecore specifically, you can always reach out to support.
This list is compiled based on conversations I've had with teams in and out of Sitecore, and I thank and appreciate everyone who helped contribute to this list. Special thanks to Kyle Heon, Larre Ländin, Ivan Sharamok, and Jason St. Cyr.
Again, if you have additional resources or items that you think should be on this list, let me know! Reach out on Twitter @derekc, on the Sitecore Community Slack as "dcorreia", or in the comments below this post.
Technology addict, avid homebrewer, Oxford comma fan, and Senior Technical Account Manager at Sitecore. Posts here are based on my thoughts and opinions and do not represent Sitecore.