Brainstorming and Defining: The Future State

“Give me 6 hours to chop a tree, I’ll spend first 4 sharpening the axe.” – Abraham Lincoln

In my previous blog post we assessed Where we are starting from? Now its time to brainstorm and decide Where we want to head towards?

As a next step we need to research, analyze and decide a lot of important factors which defines the futuristic state of the project. Beginning from which specific Sitecore Version and Update we want to upgrade to, we will be talking about various aspects of this brainstorming phase. Obviously this brainstorming involve multiple stakeholders to discuss, contribute and take a decision as a team. For example:

Architecture, Infrastructure, security, DevOps, teams should get involved while we are discussing and taking decisions about:
- Continue with on-premise mode or its time to move to cloud. OR
- We are looking for entire infrastructure upgrade by introducing new servers or utilizing the same infrastructure. OR
- Defining the topology for upper environments (UAT/PROD) OR
- Evaluating pros and cons while choosing between SQL or Mongo for xDB. etc
Project management and business should get involved while taking decisions about:
- We want to carry over the historical analytics data to the new platform or start collecting fresh. OR
- Is there any feature which we want to archive and not want to migrate?
- How the project backlog looks like so that we cant decide about code/content freeze feasibilities. OR
- And obviously resourcing etc.

Lets talk in details.

Targeted Sitecore Version?

Undoubtedly the very initial decision to be taken is – What is the target Sitecore version and update we will be upgrading to? In most of the cases it will be latest and greatest one released but sometime it depends on few factors like:

Strangely but this happened to me with one of my clients. Sometime people prefer to choose the Latest-1 update as a targeted state for various reasons like:
- It is the most stable latest one.
- The most recent one may have some Unidentified Bugs which may be critical for your project.
- Identified and fixed bugs of Latest -1 update can be found in the release notes of Most Recent Update, so that you can refer and see if any bug is critical for your project.
Initially Sitecore 9.0 was released without MongoDB support. Hence the projects using Mongo as xDB and looking for an upgrade, left with the option to upgrade till v8.2 Update 6/7 or wait until v9 comes up with Mongo support, which is now supported by Sitecore 9.0 Update 2.

On-premise / Cloud?

One of the most important decision to make while upgrading Sitecore especially if you are on-premise mode with your current implementation. Well there are a lot of affecting factors to take a decision that you should move to cloud or you keep on continuing using on-premise mode. We came these Six considerations in migrating to the Cloud or not?

What works best within your organization’s financial model?
Which option provides the level of security you need?
What are the switching costs?
How much agility do you need?
Does cloud migration provide the technology and features you need?
Which option puts you on the best evolutionary path?

On top of this when we talk about Sitecore on Cloud, please visit these excellent posts from various sources:

Most importantly get in touch with your Sitecore Sales Representative to talk in more details about comparing the services and costing between Cloud Vs. On-Premise. He/she will provide you tailored alternatives best suitable to your business. Mainly there are four alternative you can choose between:

Windows server + SQL Server
- Sitecore on Premise
Purchase Azure though Customer (Microsoft Azure) EA
- Sitecore on Azure IaaS (Virtual Machine)
- Sitecore on Azure PaaS (App Service)
Purchase Azure thorough Sitecore EA
- Sitecore Managed Cloud – Standard & Premium
Purchase Azure though Rackspace
- Sitecore Managed Services via Rackspace

Image Credit: Horizontal Integration

Infrastructure Upgrade / Parallel Instances?

Once you are done upgrading your standalone development machine and performed a dry run on upgrade, its time to upgrade the upper environments. When we plan and talk about upgrade approaches on Upper Environments there are two possibilities:

Infrastructure Upgrades

Most of the Sitecore Upgrade involves infrastructure upgrade which needs Hardware and platform upgrades. In this approach we setup entirely new servers or VMs with recommended or higher configurations as per your targeted Sitecore Vesrion. Hence we perform the upgrade process on new boxes/VMs with temporary URLs to access those. Following are the most common steps we follow while doing an Infrastructure + Sitecore Upgrade:

Setup new boxes/VMs according to the configuration recommended by Sitecore for the targeted version
Configure temporary URLs to access the new setup
Run the upgrade process on the newly setup platform
Thorough testing
Switch the URLs between new and old instances
Once successfully upgraded and tested, plan to sunset the old instances

Parallel Instances Upgrades

In one of our previous Sitecore Upgrade for a client the current infrastructure was already satisfying the recommended configuration to the targeted version, this was an upgrade from 7.2 to 8.1 Sitecore version. Hence the operating system, memory and other pre-requisites on the Web servers were already up to mark and the client was not looking for any further infrastructure upgrade. In scenarios like this we can opt for Parallel Instance Upgrade Model. In this approach we will be using the same environment but a separate IIS instance for the website. Each environment will have two websites, one already running with the current version and another on which we will be running the upgrade. Both will have their own dedicated URLs, databases, indexes, logs etc. Once the standalone development machine was upgraded successfully, we upgraded all rest of the environments using this approach including Production.

Following are the most common steps we follow while doing an Parallel Instance Sitecore Upgrade:

Setup new IIS instance on the same box/VM where the current Sitecore website is configured. Make sure this new instance is completely isolated from the current one by having its own independent URLs, databases, indexes, logs etc
Configure temporary URLs to access the new IIS Instance
Run the upgrade process on the this new instance
Thorough testing
Switch the URLs between new and old instances
Once successfully upgraded and tested, plan to sunset the old instances

Note: Parallel Instance Upgrade Approach might not be a good fit if you are upgrading to Sitecore 9 as 9 needs various roles and certificates installed. Also it will be a performance hit by having your older version and Sitecore 9 running on a same Server/VM, especially on Production. Hence for Sitecore 9 I would recommend Infrastructure upgrade along with the Sitecore Upgrade.

UAT / Stage and Production Topology?

Time to decide how you want to scale up/out your Sitecore implementation on the targeted Sitecore Version. Both Horizontal and Vertical scaling is supported by Sitecore. Undoubtedly its purely depends on how complex the project is implemented, website traffic load, number of integrated end points, number on add-on tools/modules integrated etc.

Vertical Scaling in Sitecore

Definition: “To scale vertically (or scale up) means to add resources to a single node in a system, typically involving the addition of CPUs or memory to a single computer.” (Wikipedia)

The Sitecore Experience Platform can be vertically scaled dedicating an instance to a specific role, such as Content Delivery or Processing. You can scale out further by dedicating multiple instances to a specific task. Your topology will depend on your scaling requirements. Following are the various scenarios of Vertical Scaling in Sitecore:

Combined Instances
Dedicated Content Delivery instance
Dedicated Content Management instance
Dedicated Processing and Reporting instances
xConnect: Combined Collection and Search instance
xConnect: Dedicated Collection and Search instances
xDB: Dedicated Reference Data and Automation instances
Fully scaled

Horizontal Scaling in Sitecore

Definition: “To scale horizontally (or scale out) means to add more nodes to a system, such as adding a new computer to a distributed software application.” (Wikipedia)

The Sitecore Experience Platform can be scaled horizontally by dedicating multiple instances to a particular role. For example, it is common practice to increase the number of Content Delivery servers as traffic numbers increase. Following are the various scenario of to Horizontal Scaling in Sitecore:

Multiple Content Delivery instances
Multiple Content Management instances
Multiple Processing instances
Multiple XP service instances
- The xConnect Search Indexer only supports single instance
- The Automation Engine supports multiple instances

Following are some excellent posts form various channels talking about Scaling in Sitecore:

And as usual these Sitecore Stack Exchange questions are bonus:

Historical Analytics Data – Migrate or Ignore?

Analytics data migration is a separate process than your Code and Content Database migration. There are additional tools/processes provided by Sitecore to migrate your historical Analytics data on the new platform either SQL to SQL or SQL to Mongo. But its all up to your business needs that you want to migrate that huge collected analytics data over the years or you have an option to simply avoid the historical data and start collecting fresh data on the new platform from the day you Go-live with it. This entirely depends on your business needs. If business is using the analytics data so intensively that old data will be needed as an unavoidable input for future digital marketing use cases, than you have to migrate the data.

Whereas in certain scenarios you have the option to not migrate the historical data and start from scratch. This happened with one of my client as they were collecting the analytics data, had some custom reported generated and based on those reports configuring campaigns in a third party campaigning tool. Hence we came up with a solution that we will not be migrating the data but will keep one of the current instance up for couple of months until they need to refer the historical data for their business use cases. On the other hand the campaigns and other use-cases can be created using the latest data collected on new platform. And finally when they feel comfortable we can sunset that old instance.

xDB with SQL or Mongo?

It always difficult to choose between two excellent options and choosing SQL/Mongo for xDB is nothing different than this. There are various factors affecting your decision to choose either one. Like:

Upgrading to a version below Sitecore 9

Easy peasy. You don’t an option here to choose as most the latest versions below Sitecore 9 do not support SQL for xDB hence Mongo is the only choice you left with.

Upgrading to a Sitecore 9.0 Initial Release or Sitecore 9.0 Update 1

Easy peasy in other way around. You don’t an option here to choose these version of Sitecore 9 do not support Mongo for xDB hence SQL is the only choice you left with. 🙂

Upgrading to Sitecore 9.0 Update 2

No more easy peasy. From this version onward Sitecore 9 started supporting MongoDB for xDB. This is the scenario where lot of factors must be considered and think through thoroughly to choose a best fit for your business among these two powerful platforms for xDB. Following are some critical factors:

If Mongo is not being used in the organization as of now in its technological space than it will take a lot to introduce and setup an entirely new technology in place which involves additional costing, resource training especially DBAs and Infrastructure, Security assessment for the new technology etc.
Sitecore 9.0 Update is the very first version started supporting Mongo for xDB. Although Mongo was already being support by all version variants of Sitecore 8 but there are considerable amount of differences between Sitecore 8 and 9 in terms of architecture and processing. Hence opting Mongo with the first supported version would be a bit riskier.
If you are on Sitecore 8 (any update) and already using Mongo for xDb, you can choose to stick with Mongo itself until you are planning to upgrade to any of the 9 version which do not support Mongo, but I would recommend to wait until Sitecore 9.1 is out to be at the safer side.

Please have a look at this question on Sitecore Stack Exchange answered by Peter Prochazka.

Feasibility for Code/Content Freeze?

This brainstorming is needed especially when you are upgrading your Production instance. To configure the instance to be upgraded you setup the latest code base available, take the latest database backup and restore it. From this day onward until you have completed the upgrade process successfully, passed UAT and ready to Go-Live with the upgraded Sitecore version, there might be good amount of content changes happening on the current Sitecore Version on Production, couple of code releases are pushed to production etc. Hence you need to make sure that the latest and the greatest code + content is also available on the upgraded instance you will be going live with.

If the frequency of code and content change is not very high and if you think that frequent code/content merging is achievable than code/content freeze is not required at all. You can plan iterative code and content merge to the instance being upgrade to make sure that you have everything latest.

But if the code/content update frequency is very high than you may need to talk with business and come up with the nominal period where you have code and content freeze.

Is your Sitecore License Ready?

Last but not the least make sure that you have the compatible license ready with the Sitecore upgrading to, especially if you are planning to use any module/feature which need additional Licensing cost. Best way is talk to your Sitecore Sales Representative about the Licensing terms and conditions.

Hope this post helped you understand which are all the aspect you need to brainstorm and take correct decisions based on your project.

Please feel free to post your feedback/queries in the comment section below.

Brainstorming and Defining: The Future State

Targeted Sitecore Version?

On-premise / Cloud?