Sitecore Cloud Migration from On-Premise to Microsoft Azure Platform-as-a-Service (PaaS) — Part 1: Background Information
Introduction
I am currently tackling a big piece of multi-lingual Sitecore Experience Management Platform (XM) from On Premise Virtual Machines, and moving that to Microsoft Azure Platform-as-a-Service infrastructure upgrade for a client.
Follow my series of blog posts from the beginning of the journey till the migration is complete. The technical delivery team is running on Agile / Scrum and we aim to deliver the migration iteratively, which means some of the changes for Microsoft Azure will also be run and tested in the current On Premise environment. We are in for a rough ride, so HOLD TIGHT.
Current Infrastructure
The current infrastructure was setup probably somewhere close to 10 years ago, before we inherited it. It is a very traditional setup (read mid-2000) Sitecore Experience Management Platform v8.x instance, running on a very traditional on premise Virutal Machine setup with the following traditional specifications:
- 1 x Content Management, 2 x Content Delivery. Each of these Virtual Machine instances house a legacy Sitecore 7.x web application, and a Sitecore 8.x web application. ie 2 x IIS Web Sites per Virutal Machine instance
- 1 x Publishing Service Instance, on a separate Virtual Machine different from Content Management
- Microsoft SQL Databases 2008 R2 (core, master, preview / embargo, web)
- Lucene Search Index
- IIS 7.5, Windows 2008 R2
- Akamai CDN which offloads 99% of the Sitecore 8.x web site
This setup is so traditional and boring that I am not even going to put a diagram on it.
The Infrastructure Performance Trigger Point
Whilst the the Content Delivery instances have Akamai CDN in front to cache 99% of the web site content, there are up to 50 concurrent authors, and at times, thousands of concurrent requests to the Content Management instance from other internal applications within other parts of the business. Initially the Sitecore instances were running on v8.0 Update 7, with lots of modifications / patches done to various environment configurations to speed up the web site. Multiple upgrades from that version to v8.2 Update 7 has allowed us to:
- Use Publishing Service Instance
- Utilise Lucene Search Index Sharded Configurations
- Remove the need of using Alex Shyba’s amazing Parital Language Fallback module and instead use the Sitecore provided Language Fallback instead
- Performance improvements on Experience Editor and Sitecore in general
It was a lot of work to switch Language Fallback to Sitecore’s, and change the IoC setup to use Sitecore’s preferred way of implementing Dependency Injection. Installing and using Publishing Service Instance is another big challenge on its own (I will have another blog post about this).
After many late nights and overtime spent to get to that point, I received glowing positive feedback from the client.
The CMS is definitely faster. We used to log support ticket with you because it was running so ridiculously slow to a point that we cannot use the CMS. It is still slow but at least we do not bother logging a support ticket anymore as the slowness is somewhat bearable.
A lightbulb moment immediately went off on us. We are currently running on v8.2, so why don’t we use this great opportunity to have a refresh of the aging hardware and infrastructure, and move to the magical cloud.
The Magical Cloud — Microsoft Azure Platform-as-a-Service
I will not bored anyone with details on how awesome Microsoft Azure PaaS is. Please go ahead and read the full details from Sitecore instead.
One of the main advantages of Azure Web Apps, SQL Azure are their PaaS offering, which means there should be less overhead on managing those platforms as upgrades, updates and OS patches are pushed out by Microsoft automatically. There is also some form of High Availability built into the PaaS offering.
Each Sitecore role can also be scaled accordingly to suit the needs. More information from Sitecore’s Scaling Scenarios Guide.
Our proposed solution follows Sitecore’s Architecture Guide, and here’s the attached diagram.
Conclusion
This concludes Part 1 of my Sitecore Cloud Migration blog post series. In part 1, I have given the background of the existing infrastructure, the reason why the move to the cloud is required, and the proposed architecture.
In Part 2 of this series, we hit a massive road block which could have stopped this entire migration project and almost brought it to a halt. Follow me and see how I have resolved this problem.
